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

That's the problem...

That's the problem...

Posted Jan 30, 2012 22:54 UTC (Mon) by khim (subscriber, #9252)
In reply to: Shared pain by dlang
Parent article: XFS: the filesystem of the future?

In theory, theory and practice are the same. In practice, they are not.

Ext3 is one of the worst possible filesystems to use if you really care about your data not getting lost (and therefor implement the fsync dance to make sure you don't loose data), because it's fsync performance is so horrid.

Right, but that's the problem: most developers don't care about these things (most just don't think about the problem at all, others just hope it all will work... somehow). Most users do. Thus we have a strange fact: in theory ext3 is the worst possible FS from "lost data" POV, in practice it's one of the best.


(Log in to post comments)

That's the problem...

Posted Jan 30, 2012 23:16 UTC (Mon) by dlang (subscriber, #313) [Link]

trust me, users trying to run high performance software that implements data safety (databases, mail servers, etc) care about this problem as well.

For other developers, the fact that fsync performance is so horrible on the default filesystem for many distros has trained a generation of programmers to NOT use fsync (because it kills performance in ways that users complain about)

That's the problem...

Posted Feb 2, 2012 3:45 UTC (Thu) by tconnors (guest, #60528) [Link]

> For other developers, the fact that fsync performance is so horrible on the default filesystem for many distros has trained a generation of programmers to NOT use fsync (because it kills performance in ways that users complain about)

Then there's the fact that fsync will spin up your disks if you were trying to keep them spun down (to the point where on laptops, I try to use 30 minute journal commit times, and manually invoke sync when I absolutely want something committed). I don't want or need an absolute gaurantee that the new file has hit the disk consistent with metadata. I want an absolute guarantee that /either/ the new file or the old file is there consistent with the relevant metadata. ext3 did this. It's damn obvious what rename() means - there should be no need for every developer to go through all code in existance and change semantics of code that used to work well *in practice*. XFS loses files everytime power fails *in practice*. If I need to compare to backup *everytime* power fails, then I might as well be writing all my data to volatile RAM and do away with spinning rust all together, because that's all that XFS is good for.


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