On Tuesday 27 July 2010 15:09:08 Stan Hoeppner wrote: > Volkan YAZICI put forth on 7/27/2010 2:04 PM: > > unplugged machine. At boot, I dropped to fsck command line. At command > > Were you forced to the command line or did you manually select to go to the > command line? It sounds like you chose to, not forced to. > > > prompt, I manually fiddled around with fsck of xfs to recover the > > unmounted / filesystem, but had no luck. > > Did you read the xfs documentation before embarking on this power loss > experiment? Or did you it "should just work" regardless of your actions, > or lack of action? It sounds like you ran xfs_repair on a filesystem in > an inconsistent state and forced changes, which is a no-no. > > (I also tried recommendations > > > and informative messages supplied by manpages and command > > outputs/warnings.) Also if you would Google, it shouldn't be hard to > > spot similar experiences from other people. > > I'm guessing most of them didn't look before taking the XFS leap. > > > At NASA, they might have genius technicians; but, IMHO a majority of the > > linux users would want a filesystem to recover without a prompt from the > > user. > > So the system wouldn't boot and you were dropped to a prompt. You manually > fiddled around with fsck of xfs and made no progress. It would be nice to > have seen all of that at the time. > > What were your results when you did this same power yank test with ext2/3, > ReiserFS, and the other filesystems you tested in this way? > > >> I'm basically a one man army trying to defeat misinformation WRT XFS > >> and attempt to educate ppl with the correct information. > > > > I am glad -users ml have you; and I'd be really, really appreaciated if > > somebody having experience and knowledge on fs issues can shed some > > light to our ignorance. I also support the replacement of default fs > > with something that is much more recent. From this point of view, XFS is > > a superior alternative. You are totally right with your claims about its > > advantages over other alternatives. But as you can see, people still > > complain about XFS's sensitivity to power failures. Assuming a majority > > of your users aren't behind a UPS, you can sell/ship your product with > > such a default filesystem choice. But as you said, there are no > > published concrete benchmarks about this issue. It is all what people > > claim in the mailing lists. If you would share some of your findings > > about "Power Failures and XFS" to convince us, I'm sure most of us will > > be happy to advocate XFS's this achievement. > > I've tried to dig up accurate accounts of the power loss corruption issue > post 2007 (when it was supposed to have been fixed) a few times but > couldn't find anything concrete enough to be worth referencing. I freely > admit I've done no power loss testing of XFS myself. This probably has to > do with the fact that I'm a firm believer in orderly shutdowns and > redundant power, and that I don't really have any test systems available. > I'll ask around on the XFS list and see what folks have to say. > > I'm somewhat interested in seeing where BTRFS is in 2-3 years. It may be > stable enough for production by then, and should be as fast or faster than > XFS on some workloads. Maybe it'll even handle sudden power loss > gracefully. :) I've been using btrfs for my "/" file system for a few months now on my laptop. Toward the beginning I did suffer some dpkg database corruption due to a dpkg bug[1] which is now fixed in testing. It has handled sudden power failure, kernel hangs, suspend/resume to disk/memory, all gracefully. I am a bit concerned that there is no fsck.btrfs that will run at boot time, yet. However, that is less of an issue than it would be with other file systems since I can do online fsck and defragmentation. (Reminder to self: Write cron jobs.) I still would not advocate it in a critical production environment. My tests haven't been conclusive. The various user-space tools "feel" immateure and poorly documented. If it continues to improve, and does not hit any significant roadblocks, it may be ready for production around the Squeeze+1 release. My production systems still use ext3 file systems, but that is because they are "simply" VPS slices, so their initial installation is done automatically by my provider. Were I do be doing the initial installation myself, I would likely choose XFS. [1] dpkg made some assumptions about file system behavior when traversing a directory and renaming files in that directory. Those assumptions were not guaranteed by the POSIX / SUS specifications or the LSB. Btrfs violates those assumptions. So, while the bug was in dpkg, only using dpkg on top of Btrfs showed the bug. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.