Proposal for safe/unsafe atomic rename()

[Karl Pickett]

This is only regarding open(TMP_FILE),close(),rename() - not about
directly overwriting an existing file which to me is clearly not safe
and a different issue.

I think the safe atomic rename semantics by default are important.
Most files on my disk I regard as critical after a crash.  Only a few,
in tmp, can be sacrificed safety.   Now if these semantics are too
onerous for certain apps, I have a proposal to disable it.

fcntl(fd, F_SET_ATOMIC_RENAME) (int)
Only allowed to set to 0.  Once set to 0, can not be restored to 1,
which doesn't make much sense and seems easier to implement. (I could
easily be wrong).

fcntl(fd, F_GET_ATOMIC_RENAME) (int)
Ext3/4 could return 1 here for all newly opened files.  If you set to
0 (above), then this call would return 0 as well.

I have a daemon that, when prompted by a UI, writes a report out to
/tmp/report.tmp and renames it to /tmp/report.  Then the UI opens
/tmp/report and displays it to the user.  Clearly after a crash I
don't care if /tmp/report is 0 length because it's always regenerated
by the gui poking the daemon first.  It would also be very easy for
me, if I thought it would help performance, to put a one line
fcntl(SET_ATOMIC_RENAME, 0) to get that extra bit of speed during any
checkpointing.

I think the fcntl is easiest when dealing with multiple layers of
software, and not always being able to intercept the low level open()
call.
Also, if the performance difference is so onerous 1 fcntl isn't going
to be a problem.

There may be a better word than "Atomic".  Maybe "Safe",  "Robust",
"NoEatMyData", ...

-- 
Karl Pickett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/