|
|
Subscribe / Log in / New account

ext4 and data consistency

ext4 and data consistency

Posted May 13, 2010 21:23 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: ext4 and data consistency by drag
Parent article: The Next3 filesystem

The difference is that due to a fluke to Ext3's design the window that the 'zero length files' would be created on improper shutdown is much shorter then the same window for Ext4 (or XFS or whatever)

My understanding is that ext3 would always have allocated the blocks for the new file and written it before the rename would occur. The 0-length file issue was due to ext4 performing delayed allocation and performing the rename before the data ever got written.

So ya.. apparently that 'fsync' was always needed by application developers if they wanted to ensure that data was written to disk in a timely fashion.

This is a misunderstanding. The desired behaviour was that operations occur in order. It's not terribly important to a user if they lose the configuration changes they made before a crash - it's pretty significant if the rename was performed before the data hit disk, resulting in the complete loss of their configuration.

It's true that POSIX doesn't require that filesystems behave this way. There's many things that POSIX doesn't require but which we expect anyway because the alternative is misery.


to post comments

ext4 and data consistency

Posted May 14, 2010 12:32 UTC (Fri) by ricwheeler (subscriber, #4980) [Link]

You need to be careful not to confuse the rename issue specifically with the need to use fsync() properly to make sure that data is on disk.

Applications still have to understand when to use fsync() properly to move data from the page cache out to persistent storage (on disk, ssd, etc).


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