lkml.org 
[lkml]   [2009]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectProposal for safe/unsafe atomic rename()
From
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


\
 
 \ /
  Last update: 2009-04-09 19:13    [W:0.041 / U:1.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site