Re: Best file system
On Fri, Feb 03, 2006 at 11:31:00AM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 04 Feb 2006, David MacKinnon wrote:
> > XFS has been pretty stable. I've seen one instance of FS corruption
> > on an XFS filesystem, that was recoverable using xfs_repair.
>
> Same here. But it was on the root filesystem, so it took a live-cd to
> repair because of the utter braindamage fsck.xfs is.
alternatively, plan ahead and have a small rescue partition with a
minimal debian installation and a variety of rescue tools on it.
useful for local machines and extremely useful for remote servers -
you don't have to get the co-lo monkeys to put a CD in the drive for
you...anything that eliminates the need to ask someone else to do
something for you is a very good thing.
> > XFS also significantly outperformed resier in our benchmarks (over
> > nfs), and has apparently performs better when dealing with very
> > large files (*cough* ZAPP zodb *cough* ;))
>
> OTOH, you must not, *ever* have a watchdog/power/kernel oops event. If
> you do, you lose data transparently with XFS, with no way to know what
> was commited to disk, and what was not, and for safety you will need
> to avaliate *all* files open from 10 minutes or so before the crash.
i guess that depends on usage. i've had a number of power failures on
my workstation boxes, even on my main workstation at home (which also
doubles as mail server, web server, file server, etc etc etc), without
getting corruption. i've lost a few files, but the file system was
OK. disk usage on this machine is usually light, but it varies a lot
depending on what i've doing. i've got a UPS for it now, and can't
remember the last time i had a kernel oops on it.
(maybe i'm just lucky)
for big servers, use a UPS (of course), and a raid controller with a
large non-volatile write cache. having the journal log on a separate
disk speeds up writes by avoiding seeks....perhaps even use a SSD or
non-volatile ramdisk card for the journal.
you can't entirely eliminate the risk of corruption during a crash (it's
a risk with any fs, depending on the exact timing and nature of the
crash) but you can throw hardware at the problem to reduce the risk a
lot and to minimise the damage if/when it occurs. the faster the journal
is committed to disk (or SSD or NV ramdisk), the less damage can be
done.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: