Re: [opensuse] File system safety during crash - ext3 or ext4?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Hi!
Why ReiserFS over ext3 or ext4? Ext3 and ext4 support data journaling, ReiserFS doesn't. Seems to me much worse.
One of the design goals of reiserfs initially was to recover gracefully from a crash. Mmm... (Not related to above) read this, it will give you an idea of the problem, that not even data journalling solves, AFAIK: “Delayed allocation and the zero-length file problem” http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-lengt... “Don’t fear the fsync!” http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ Sp. #17. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoQapcACgkQtTMYHG2NR9VLoQCfbs7dSuzDkBqMziolByXG6X+T O40An1nMVCzGfNmdbJMi6U1xKEwtYkmq =KRB/ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Mmm... (Not related to above) read this, it will give you an idea of the problem, that not even data journalling solves, AFAIK:
Delayed allocation and the zero-length file problem http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-lengt...
Dont fear the fsync! http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
Neither of which helps someone running an application unless they are willing to modify the code to assure there are fsync calls after every write/close. And neither are particularly enlightening as to the problem at hand, namely, selecting the FS that is least vulnerable by design. Further, with regard tot he second article linked above, hand waiving away performance hits by referencing some obscure firefox bug doesn't say a thing about real world performance problems which would occur if EVERY app were re-written to use fsync calls always and everywhere. I suspect that, if indeed, every application did fsync always and everywhere, it would become necessary to build in an OS level no-op for fsync calls just to return performance to prior levels. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2009-05-17 at 13:05 -0700, John Andersen wrote:
Carlos E. R. wrote:
Mmm... (Not related to above) read this, it will give you an idea of the problem, that not even data journalling solves, AFAIK:
Delayed allocation and the zero-length file problem http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-lengt...
Dont fear the fsync! http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
Neither of which helps someone running an application unless they are willing to modify the code to assure there are fsync calls after every write/close.
(I doubt you have read all the comments yet... you haven't had the time!)
And neither are particularly enlightening as to the problem at hand, namely, selecting the FS that is least vulnerable by design.
Yes, it does: the point is that you have to use an UPS, because software is not good enough, and is not in our hands as users. No filesystem choice can be safe enough. And fsck-ing a 2 TB ext3 partition is daunting!
Further, with regard tot he second article linked above, hand waiving away performance hits by referencing some obscure firefox bug doesn't say a thing about real world performance problems which would occur if EVERY app were re-written to use fsync calls always and everywhere.
No, the problem is not a FF bug, but that it brought some attention to the problem in the filesystem design. Notice that, IMO, the most interesting insights are not in the article, but in the comments. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoQc/0ACgkQtTMYHG2NR9UgdQCgliukiwxxPrxGiKfWHKfZ9LSZ a0sAnjCTFrrkiGentAunvx8w+tf0/7xj =jxTQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (2)
-
Carlos E. R. -
John Andersen