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-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
