* zooko <[EMAIL PROTECTED]> [2008-06-23 20:35]: > I'm not sure what the use case we're talking about is, > but for many use cases reiser3 is a good choice.
The problem with the Reiser family FSs is that they are inherently brittle. Now that they have been sufficiently debugged, they no longer lose data often, but if you have even a small unrepairable corruption, it is still more likely that you’ll lose half your disk instead of just a few files, as is the extX family’s failure mode. So even now I would not entrust either Reiser-family FS with data that I care about. Hence my suggestion of putting the less huge- tree-performance sensitive git store on another partition and keeping only the working copy on reiserX. The other thing about the Reiser-family FSs is that they eat enormous amounts of CPU, to the point that they can *fully peg* a CPU during I/O. > Andrew Morton vaguely recalled something like 30% performance > loss when turning on write barriers for ext3. Yes, ext3 is slow. It is much faster than the Btree-based FSs in a select few circumstances, but in general, it is slow or very slow. > Chris Mason (who worked on reiser3 at the time and is I think > chief architect of btrfs now) cooked up a test script which > could cause filesystem corruption in ext3 with about 50% > probability in case of power loss. Right, but how much data gets lost in such a case? In my experience and that of every sysadmin I’ve asked, unrecoverable corruption is essentially always quite localised with extX. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
