5 ms·

I read a bit more and figured out why the article was written. In 2009, ext4 (and ONLY ext4) adopted this behavior: https://git.kernel.org/pub/scm/linux/kernel

I read a bit more and figured out why the article was written. In 2009, ext4 (and ONLY ext4) adopted this behavior: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?id=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8 https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.g... I don't think any other unix filesystems do this. It's not posix, and it's not behavior that any apps should be depending on if they care about their data. I would suggest updating the LWN article to clarify that this is a piece specifically about ext4 -- not POSIX, or even Linux in general.

nh2 3y ago
What you say is correct, and ext4's current default behaviour can be quite confusing: * ext4 turns rename() into an invisible fsync(), if the target file existed. * ext4 turns close() into an invisible fsync(), if the opened file existed. This leads to surprising results: If you unzip something the first time, it's nice and fast. If you unzip the same file again, force-overwriting existing files, suddenly it's 10x slower. You now spend hours finding out why, and start cargo-culting vodoo that doing `rm` before makes it inexplicably fast again. Invisible fsync()s that the application programmer cannot turn off are quite bad. My speculation is that Ted Ts'o agrees with that in principle, but that he got tired of having to explain people that if they don't fsync(), there are no guarantees; so he added this hack that makes 95% of the cases go away with surprising special-case behaviour.
- nh2 3y ago
  For people who want to read more about this in _up-to-date_ documentation: * `auto_da_alloc` section of https://www.kernel.org/doc/html/latest/admin-guide/ext4.html https://www.kernel.org/doc/html/latest/admin-guide/ext4.html * https://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_potential_data_loss https://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_po...
hedora 3y ago
That’s not quite true. There used to be a performance bug in ext3 that caused it to order the writes before the journal flush that created the files. Then, gnome(?) and only gnome(?) relied on it, leading to massive filesystem corruption, so the kernel team gave up and made the old braindead behavior the default. (The current default behavior is braindead because it makes rename extremely slow for correct programs that don’t care about durability across crashes, and therefore don’t call fsync).
- throwaway09223 3y ago
  Yeah, all filesystems are allowed to synchronize to disk as often as they want, in whatever way they want in /addition/ to what's specified. Filesystems can even make their own guarantees, above and beyond generalized specifications like fsync(). I could write a filesystem that synchronized files after every 42 megabytes, or once every 69 seconds. Apps might even come to depend on this behavior. All filesystems will have predictable, implementation dependent idiosyncrasies. But these aren't specified behaviors. They're not part of an interface and they shouldn't be depended on. The article implying that they ought to be is, I think, shortsighted. Other filesystems don't do this and your code will break if you assume it. I agree it's braindead.
lxgr 3y ago
From the article: > However, the ordering effect of rename() turns out to be a file system specific implementation side effect. It only works when changes to the file data in the file system are ordered with respect to changes in the file system metadata. In ext3/4 [...] Seems pretty clear to me that this is talking about an ext3/4 implementation detail that people have started to rely on...? I also pretty clearly remember that from back in 2009. > This article is just plain wrong. Articles like this helped me understand the distinction between theoretical POSIX semantics and what Linux was actually doing at the time. It seems like you are reading more into this article than at least I got out of it – maybe it's because I still remember that 2009 controversy, but I wouldn't have drawn any of the (incorrect, and I agree on that!) conclusions you're listing above.

nh2 3y ago

What you say is correct, and ext4's current default behaviour can be quite confusing: * ext4 turns rename() into an invisible fsync(), if the target file existed. * ext4 turns close() into an invisible fsync(), if the opened file existed. This leads to surprising results: If you unzip something the first time, it's nice and fast. If you unzip the same file again, force-overwriting existing files, suddenly it's 10x slower. You now spend hours finding out why, and start cargo-culting vodoo that doing `rm` before makes it inexplicably fast again. Invisible fsync()s that the application programmer cannot turn off are quite bad. My speculation is that Ted Ts'o agrees with that in principle, but that he got tired of having to explain people that if they don't fsync(), there are no guarantees; so he added this hack that makes 95% of the cases go away with surprising special-case behaviour.

nh2 3y ago
For people who want to read more about this in _up-to-date_ documentation: * `auto_da_alloc` section of https://www.kernel.org/doc/html/latest/admin-guide/ext4.html https://www.kernel.org/doc/html/latest/admin-guide/ext4.html * https://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_potential_data_loss https://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_po...

hedora 3y ago

That’s not quite true. There used to be a performance bug in ext3 that caused it to order the writes before the journal flush that created the files. Then, gnome(?) and only gnome(?) relied on it, leading to massive filesystem corruption, so the kernel team gave up and made the old braindead behavior the default. (The current default behavior is braindead because it makes rename extremely slow for correct programs that don’t care about durability across crashes, and therefore don’t call fsync).

throwaway09223 3y ago
Yeah, all filesystems are allowed to synchronize to disk as often as they want, in whatever way they want in /addition/ to what's specified. Filesystems can even make their own guarantees, above and beyond generalized specifications like fsync(). I could write a filesystem that synchronized files after every 42 megabytes, or once every 69 seconds. Apps might even come to depend on this behavior. All filesystems will have predictable, implementation dependent idiosyncrasies. But these aren't specified behaviors. They're not part of an interface and they shouldn't be depended on. The article implying that they ought to be is, I think, shortsighted. Other filesystems don't do this and your code will break if you assume it. I agree it's braindead.

lxgr 3y ago

From the article: > However, the ordering effect of rename() turns out to be a file system specific implementation side effect. It only works when changes to the file data in the file system are ordered with respect to changes in the file system metadata. In ext3/4 [...] Seems pretty clear to me that this is talking about an ext3/4 implementation detail that people have started to rely on...? I also pretty clearly remember that from back in 2009. > This article is just plain wrong. Articles like this helped me understand the distinction between theoretical POSIX semantics and what Linux was actually doing at the time. It seems like you are reading more into this article than at least I got out of it – maybe it's because I still remember that 2009 controversy, but I wouldn't have drawn any of the (incorrect, and I agree on that!) conclusions you're listing above.