From: Stan Hoeppner on
Paul E Condon put forth on 7/27/2010 8:53 PM:

> Your original post in this thread addressed a quite disfunctional
> attitude of OP, and IMHO, was correct but somewhat harshly worded.
> In truth, he simply cannot have everything he wants all at the
> same time. You should have left it at that, IMHO.

Words of wisdom, you speak. Retired from this thread, I have. Let go of
harsh wording, I shall. :)

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C506128.3020609(a)hardwarefreak.com
From: Boyd Stephen Smith Jr. on
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(a)iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/