LWN.net Logo

fsync and spin-ups

fsync and spin-ups

Posted Mar 14, 2009 2:10 UTC (Sat) by njs (guest, #40338)
Parent article: Ts'o: Delayed allocation and the zero-length file problem

It really is a great thing that ext4 is relaxing the old ordering requirements of ext3('s default mode): this makes it possible for fsync to become much much cheaper. (fsync on ext3 is so expensive that *people avoid using it*, and that's no good for data reliability at all!)

I also take Ted's point that if apps want atomic-rename to be portably atomic, then they have to call fsync anyway and accept that they will pay an additional cost for getting durability in addition to atomicity.

BUT, in those cases where durability is not required, and I'm using a filesystem like ext3 or (soon) ext4 that supports atomic-but-not-durable-rename, I *really* want some way to access that.

My problem is that I spend all my time on my laptop, and most of the time my hard drive is spun down. I've had to disable emacs's fsync-on-save, because otherwise my editor freezes for a good 0.5-1 seconds every time I hit save, while it blocks waiting for the disk to spin up. Even if the filesystem side of fsync is made cheap like in ext4, fsync will never be cheap if it blocks waiting on hardware like this. And if everyone adds fsync calls everywhere (because they've read Ted's rant, or just because fsync became cheaper), then most apps won't have a handy knob like emacs does to disable it, and that will suck for laptop user experience and power saving.

So I think we need an interface that lets user-space be more expressive about what ordering requirements it actually has -- rename_after_write(2), or something.


(Log in to post comments)

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