On Tue, 10 Apr 2012, Russell Coker wrote:
On Tue, 10 Apr 2012, Jason White <jason@jasonjgw.net> wrote:
It is my (perhaps faulty) understanding that most editors omit the fsync() and that the file will only be on your memory stick when you unmount it in the typical case.
open("test", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 write(4, "test\n\n", 6) = 6 fsync(4) = 0 stat("test", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 close(4)
I've just run strace on vim and it calls fsync.
If most editors omit the fsync() as you claim then please run strace and find us an example of one - and file a bug report while you are at it. ;)
Please don't (I had to set vim to turn off fsync. I don't have to override emacs, fortunately). Some of us like our drives to remain spun down, regardless of any autosave behaviour of your editor (I could maybe tolerate fsync for hard save and not using fsync for autosave, but I still don't like my editor to delay for 5 seconds while it waits for a drive to spin up (or delay for 2 minutes while it waits for all the disk contention caused by bloatware such as mozilla) just because my fingers typed C-x C-s before asking my brain for permission). Don't forget that sometimes (or often, in my case), we're editing over fuse filesystems to laggy ssh connections on the other side of the country. I *really* want filesystem operations to be asyncronous in such cases. As long as the file is either the new or the old version, and not zeroed out because of braindead filesystem behaviour, it makes no difference if it was committed to disk now or 5 seconds in the future. You've still lost the new version of the file (but keep the old version) even if fsync() is called, if the power fails before the fsync() is called and returns. Not using fsync() just makes that window 5 seconds longer in normal operation. If you're saving once every 10 minutes, who cares about 5 seconds? You'll still end up with the old version of the file if you're using a sane filesystem (or nulls if you're using crap like XFS). -- Tim Connors