[NTLUG:Discuss] picking a filesystem in 2006...

[Richard Geoffrion]

In a different thread Chris wrote:
>Since I've run 2TB filesystems for awhile using reiserfs, 
>I can say it works well (2TB because historically I was 
> using LVM1).

>From that I gather LVM1 had a 2TB limit.

>I'd make sure that your ext2 utilities are up to date.  
> <SNIP>

>If you just can't stand reiserfs (v3), I'd probably look at
xfs and jfs.  

I have this to say about ext3 and reiserfs as it relates to using dirvish.  ext3 outperforms reiserfs by..oh..it has to be 4000% if not more!   There is some fundamental underlying process that makes reiserfs slow when running dirvish-expire to remove the 'vaults'.  Hmm..let me see if I can re-google the answer.... hang on a second.

{music plays in the background}

Ok...I'm back..sorry it took so long.  I wasn't able to find the whys-and-wherefores but I did find a benchmark test that shows some of the results.   I dunno.. when I try to remove a large directory it takes forever on reiserfs.  And let's talk talk about mounting times!  wow!  ext3 is dang near instant where ReiserFS takes so loooooooongggg.  (benchmarkes - http://linuxgazette.net/102/piszcz.html )


>I still believe there is a major fundamental bug inside of
>ext2 (and therefore 3 as well).  Times I've lost an ext3 
>filesystem, the results were NOT pretty at all.

What fundamental bugs?  Google searches only bring up OS/Distro version bugs and debunk these unwritten fundamental bugs that no one deems worthy to quote.  :)

><snip>
>The reiserfs boxes are infinitely more flexible, since the 
>LVMs and filesystems can be resized without unmounting.  
>A nifty thing in the enterprise.

Hmm...Isn't ext3 resizeable?  I see where others talk about it.

>LVM2 has its share of warts.... getting better... certainly
>nice to get beyond some of the limits of LVM1, 
><snip the implecations> :)

(important question to follow:)
OK..so should LVM2 even CARE about a partition on a >2TB /dev ?  Is running 'parted' and using GPT signatures/EFI even necessary?  (see the wikipedia article which is very informative:  http://en.wikipedia.org/wiki/GUID_Partition_Table )

cfdisk sees 4.2TB...so I'm guessing that it is not an issue with an OS Num_of_LBA-bit addressing issue.  The OS is seeing the device properly.  I'm just wondering what the real issue is.  I've been at this for so long now that I fear I'm swimming in useless/wrong/too much information.

>Reiser4 looks downright awesome.... I may deploy this a
>bit early.  

Scary...it just seems real scary to trust data to something so new when there are so many other options available.  Now...if it was the only solution or for use in non-critical data...I could see it.

>Some of the numbers will make you faint...
Somewhere in my research I read that it was just now getting to the point where it was fast enough (on par with Reiser3) to be usable...of course those posts may have been dated..

>I realize it likely has some bugs... but man oh man...
>Will make dealing with really large filesystems much
>better (the rest all stink at it... even reiserfs v3 suffers
>from some of the same problems with regards to large
>tree removals, etc..... though ext3 is measurably worse). 
>I know for sure that ext3 and reiserfs will take several days to
>fsck a 4TB filesystem.... should an fsck become necessary.
>Ideally fsck becomes a thing of the past with Reiser4 (as
>it matures).


reiserfsck is relatively fast.   The problem comes in when one has to do 
a --rebuild tree!  It takes a day on a 230 GB volume!  It'll take WEEKS 
to do a 4TB volume!  That is unacceptable!    Hey..that's what I need -- 
a benchmark on the filesystem that fsks the fasted.

-- 
Richard