User: Password:
|
|
Subscribe / Log in / New account

Solving the ext3 latency problem

Solving the ext3 latency problem

Posted Apr 17, 2009 14:03 UTC (Fri) by anton (subscriber, #25547)
In reply to: Solving the ext3 latency problem by butlerm
Parent article: Solving the ext3 latency problem

A strict interpretation of data=ordered means committing dirty data to disk before any meta data updates.
I'm not sure I agree, but anyway, if it behaves that way, that's fine with me. I like my data not only on disk, but also internally consistent.
"data=writeback" is the no holds barred assume your system is never going to crash [...] sort of preference.
But if I assume my system is never going to crash, why would I be using fsync()? And why should a file system that works based on that assumption do anything when the application calls fsync()?
Fortunately, there is a lot of room for reasonable, safer relaxations between data=ordered and data=writeback.
I would actually prefer to see something stricter than data=ordered. Something that gives me the guarantee that the state after a crash corresponds to some logical state of the file system before the crash.

Until I get that, I'll just go for data=ordered and hope that the Linux developers don't break it like they did with data=journal.


(Log in to post comments)

Solving the ext3 latency problem

Posted Nov 10, 2009 12:00 UTC (Tue) by schabi (guest, #14079) [Link]

I would actually prefer to see something stricter than data=ordered. Something that gives me the guarantee that the state after a crash corresponds to some logical state of the file system before the crash.
You always have the option to mount with "data=journal" - this is the safest and slowest mode with ext3. And don't forget that RAID5 / RAID6 will break all barrier / journal semantics for all filesystems.


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