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

[Richard Strittmatter]

I'll weigh in here, from the standpoint maintaining lots of servers

Reiserfs stinks... The write blocking on unlink makes it a horrible choice
for anyting that changes files.. It may be a fast read, but try to use it
for mail servers, and you'll pull your hair out..

Ext3 has been the best choice for me.. It may not be the best, but it works.

Richard

-----Original Message-----
From: Discuss-bounces at ntlug.org [mailto:Discuss-bounces at ntlug.org] On Behalf
Of Richard Geoffrion
Sent: Friday, September 08, 2006 10:44 AM
To: NTLUG Discussion List
Subject: [NTLUG:Discuss] picking a filesystem in 2006...

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


_______________________________________________
http://www.ntlug.org/mailman/listinfo/discuss