LWN.net Logo

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

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

Posted Mar 16, 2009 8:57 UTC (Mon) by kornelix (guest, #57169)
Parent article: Ts'o: Delayed allocation and the zero-length file problem

I do not understand why there is a debate about this. If a file is written and closed by the application, I see no reason to delay committing it to disk. No work will be saved, only delayed. Nothing can be better optimized by the delay (well maybe a bit of seek time on a busy disk but this only applies to commit delays < 1 second or so). The only impact of the delay is greater risk that the update will get lost. Of course the buffers should be marked "clean" and retained in cache for a while in case a read of the same file is requested shortly later.


(Log in to post comments)

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

Posted Mar 16, 2009 9:28 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

think about temporary files created during a compile. you may create them, fill them, and close them with one program. then a second program comes along a few seconds later to read and delete the program. it never actually needs to hit the disk

not all temporary files are only used by a single program that keeps them open the entire time.

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

Posted Mar 16, 2009 10:24 UTC (Mon) by oseemann (subscriber, #6687) [Link]

So it turns out there are really very different use cases for files. As the name implies, temporary files need never hit the disk and could thus even happily reside on a ramdisk (many systems clear /tmp upon reboot anyways).

For /home or /var many users might want a more conservative approach, e.g. fsync on close or something similar, accepting performance penalties where necessary.

I believe this is a larger issue and I'm glad the current behavior of ext4 receives such wide attention and makes people think about the actual requirements for persistent storage.

I'm certain in the long run the community will come up with a proper approach for a solution.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds