Stefan Monnier wrote:
filesystem... so considering its size, I'd turn it off.
Hopefully the "fsck takes _forever_" problem will die when
btrfs becomes the standard filesystem.
Just a reminder: Linux has xfs since 2002. A full-blown fsck
on xfs is a rare thing.
Similarly, I don't know of any case where fsck on an ext3
partition turned out to be useful. As a matter of fact, my
home router's ext3
I wouldn't go that far. It all depends what messed the file
system up in the first place.
That's the thing: nothing did. So why run fsck at all?
I read your statement to mean running fsck on a broken file system
didn't do anything useful. If it's not broken, don't fix it. :)
Ext3 bugs, minor scribbling and suchlike generally get tidied up
reasonably well by e2fsck. It's quite true that with major
corruption to the file system there's often not an awful lot left
afterwards but that's true of many other file systems as well.
Oh, you're thinking of using fsck for recovery purposes. That's a
different situation. I was just talking about the idea of "not
needing to do fsck any more", which is pretty much already the case
for XFS and ext3, AFAIK.
Ah, you mean the regular mount count / interval checks? Yes, theses
should be unnecessary with a journaled file system (this is why
anaconda has disabled those checks for file systems that it creates
for years).
The paranoid might still like to run these checks occasionally to
detect any latent corruption but I'd be much more inclined to do that
on my systems if we had an fsck that ran in a reasonable amount of
time for large volumes.
Actually I call it "router" because it was sold as such and it
replaced a machine which I originally used as such as well. Really
it's just a small home server which stores&plays my music, stores
my movies and other such things, ... It doesn't actually do any
routing at all.
Ah, cool; I have a similar box (although it does do some routing) that
also has a fairly sizeable file system. Currently it's configured to
never fsck on boot for the reasons discussed here.
Regards,
Bryn.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
