Ts'o: Delayed allocation and the zero-length file problem [LWN.net]

Ts'o: Delayed allocation and the zero-length file problem

Posted Mar 13, 2009 17:04 UTC (Fri) by jwb (guest, #15467)
In reply to: Ts'o: Delayed allocation and the zero-length file problem by forthy
Parent article: Ts'o: Delayed allocation and the zero-length file problem

What we actually need is a user-space API that actually makes sense and wasn't invented in the Sputnik era.

(Log in to post comments)

Ts'o: Delayed allocation and the zero-length file problem

Posted Mar 13, 2009 20:25 UTC (Fri) by alexl (subscriber, #19068) [Link]

In terms of posix API additions, what would be nice is for atomic safe rewrite of files would be:

fd1=open(dirname(file))
fd2=openat(fd1, NULL, O_CREAT) // Creates an unlinked file
write(fd2)
flinkat(fd1, fd2, basename(file)) // Should guarantee fd2 is written to disk before linking.
close(fd2)
close(fd1)

This seems race free:
doesn't break if the directory is moved during write
doesn't let other apps see or modify the temp file while writing
doesn't leave a broken tempfile around on app crash
doesn't end up with an empty file on system crash

Ts'o: Delayed allocation and the zero-length file problem

Posted Mar 14, 2009 1:41 UTC (Sat) by dcoutts (guest, #5387) [Link]

Yes, that would be great. It's a natural extension of the POSIX notion that files are separate from their directory entries.

Ts'o: Delayed allocation and the zero-length file problem

Posted Mar 15, 2009 23:25 UTC (Sun) by halfline (guest, #31920) [Link]

Another idea would be to introduce a new open flag, O_REWRITE, or some such that gives the same straightforwardness as O_TRUNC to the application developer but under the hood works on a detached file and atomically renames on close. Since all the I/O operations are grouped (via the fd), the kernel should be able to ensure proper ordering relatively easily (i think?) and apps wouldn't have to introduce a costly "sync it now" operation.

Ts'o: Delayed allocation and the zero-length file problem

Posted Mar 21, 2009 0:34 UTC (Sat) by spitzak (guest, #4593) [Link]

This flag certainly is needed, but I would go further and say that Linux should change the behavior of O_CREAT|O_WRONLY|O_TRUNC to do exactly what you specify. This is because probably every program using these flags (or using creat()) are written to implicitly expect this behavior anyway.