Re: Sarge with ext3, reiserfs (3/4?) or xfs?
On Thu, 10 Feb 2005, Alvin Oga wrote:
> my point was a matter of sit and wait or use faster fs that does
> not format the 2TB of disks while you're waiting ... i dont sit
Let me see if I understood you correctly. Your major factor of choice in a
filesystem is the time it takes to mkfs it? Which you only need to do
*once* in most cases ?
Do you even do burn-in tests on RAID arrays before you put them into
production? That can take a couple of days on a 1TB array, depending on how
serious you are about the testing. mkfs time is a joke in comparision.
> i'm just tired of ext2/ext3 ... too slow to reboot and let
> it do its fsck .. which i always require to let it do its
> (sanity) self check
Duh. Disable the fsck for ext3, if you want. Set it to 720 days or
something. Have it fsck itself when coming back from scheduled shutdowns
(which is *always* a good idea, and the fact that it is hard to do with XFS
is one pet peeve of mine).
> there's been some rumblings in the ml about xfs being bad
> but i havent run across those problems yet
XFS cannot, *by design*, deal with keeping data (as opposed to medatada)
safe from catastrophic failures.
I use XFS a lot, but just on very stable servers that have a damn good power
grid (regulated, with proper UPS systems) that never goes down without
warning. Or on stuff that I do not mind losing (transient data, etc). The
XFS filesystem metadata itself is well journaled, and unless you hit a
kernel bug or a memory failure (you use ECC RAM, don't you?) it won't get
corrupted. But file data, well, zeroes everywhere.
BTW if the XFS metadata does get corrupted (bad memory is the most likely
reason for that to happen), good luck. You will notice it when the
corruption gets so bad it deadlocks. If it is the root fs, you will need an
external boot media to xfs_repair it. Been there, done that, learned from
it.
If it has to survive going down in flames, it is ext3 the better choice of
the two. And root partitions are *always* ext3 on my book. In fact, I know
of *no* filesystem that has such a good repair toolset as ext3.
> > kernel with an special vfat layer to get it working) or ReiserFS (know
I'd use reiserfs only on stuff like solid-state disks when there are tons of
small files and space is at a major premium :-) I simply don't trust it
enough.
> > > i don't need to read ML.... i am a doer and make things work or
> > > break um depending on who's paying
> >
> > well, you should read ...
>
> i read when there's a pending job for the homework
You apparently failed to do your homework on XFS, which you appear to be
actively using (maybe I am wrong on that, and you are only *advocating* its
use).
> and more importantly... ext3 does do its equivalent of fsck
So does XFS at mount and umount times. In fact, xfs_repair *depends* on the
kernel to do the log playback during a read-write mount, before it tries to
repair the filesystem...
> i allow it to do its sanity self checks
Good for you. So do I, every 180 days or so.
> i'm saying i personally buy thousands of disks ...and i do NOT
> have any problems in 5-10 years .. witht eh dumb exception
Methinks that is very, very unlikely. I speak from experience. Even if you
leave in paradise, where it is always 18C, wall power to the workstations is
clean and stable, and nobody hits the desks in anger shaking the entire
workstation... you'd still get some disks that will fail due to mechanical
damage that was there before installation and got worse over time, or due to
manufacturing defects (and I do mean one failure in an otherwise good lot of
disks, not what happened to the IBM Deskstars).
> - scsi disks dies, cause it runs hotter and spins
> faster on its itty bitty ball bearings
Here it is IDE that dies first. I sure hope the higher-end SATA disks will
behave better, at least in quiet, stable server rooms.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: