[NTLUG:Discuss] picking a filesystem in 2006...
Robert Pearson
e2eiod at gmail.com
Fri Sep 8 21:40:23 CDT 2006
On 9/8/06, Richard Geoffrion <ntlug at rain4us.net> wrote:
> 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've used them all.
Currently, I have one SuSE box running ReiserFS and the other
running XFS.
But I'm just playing with these. No real Production work.
I prefer XFS for no real reason.
As soon as ZFS is available I plan to use it.
> 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 )
>
{different music plays in the background}
HTH. Here is what my Google for "dirvish-expire reiserfs" found:
Question from Richard Geoffrion:
<<http://www.dirvish.org/pipermail/dirvish/2006-April/000720.html>>
"[Dirvish] server hard locks running dirvish-expire (where to start??)"
Very good answer here but not specific enough---
2x - Different info requested
"[Dirvish] server hard locks running dirvish-expire (where to start??)"
<<http://www.dirvish.org/pipermail/dirvish/2006-April/000722.html>>
3x
"server hard locks running dirvish-expire (where to start??)"
<<http://www.nabble.com/server-hard-locks-running-dirvish-expire-(where-to-start--)-t1440970.html>>
Very good answer here---
Excellent installation and setup info
<<http://www.angelfire.com/planet/esj710/dirvish.html>>
Recommends using ReiserFS
<<http://wiki.dirvish.org/index.cgi?WhatFilesystem>>
Filesystem specific
How should I build the filesystems for dirvish?
<<http://www.keithl.com/dirvish/FAQ.html#mkfs>>
Excellent advice here---
Dirvish FAQ
<<http://www.keithl.com/dirvish/FAQ.html>>
Bug reports - Debian + LVM2 + Kernel 2.6.11 + Reiserfs 3.6
"periodic Kernel panic with reiserfs 3.6 partition (twice a month)"
<<http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=322034>>
General Debian Bug report page
<<http://www.archivum.info/debian-bugs-dist@lists.debian.org/2005-04/threads.html>>
Debian + ReiserFS specific
Problem:
<<http://www.archivum.info/debian-bugs-dist@lists.debian.org/2005-04/msg06329.html>>
Solution:
<<http://www.archivum.info/debian-bugs-dist@lists.debian.org/2005-04/msg06525.html>>
Debian + ReiserFS Extended Attributes:
Question
<<http://www.archivum.info/debian-bugs-dist@lists.debian.org/2005-04/msg05463.html>>
Reply
<<http://www.archivum.info/debian-bugs-dist@lists.debian.org/2005-04/msg05709.html>>
Dirvish + ReiserFS3 and 4 specific
Q:
"Can anyone give me any useful input as to whether ReiserFS is better
for a Dirvish backup filesystem than, say, ext2/3 with lots of inodes
and small blocks?"
A:
"My advice is to stay as far away from either version (3 or 4) of
ReiserFS as possible."
<<http://www.dirvish.org/pipermail/dirvish/2006-January/000587.html>>
"Recommending ReiserFS"
<<http://www.redhat.com/archives/fedora-list/2004-April/msg04733.html>>
Q: "Should i consider ReiserFS for my new installation?"
<<http://www.redhat.com/archives/fedora-list/2004-September/msg03703.html>>
"What Filesystem?"
<<http://wiki.dirvish.org/index.cgi?WhatFilesystem>>
Using Debian + ReiserFS _ LVM2 + Dirvish
<<http://edseek.com/archives/2005/02/08/recovering-lvm2-with-debian-installer-rc2/>>
One "Real" Solution to using ReiserFS and Dirvish with "No Expiration"
"Using reiserfs and Unix hard links on the target drive, I can get hundreds
of full nightly images into a 2X sized drive, so I can store 100X more images
per dollar using rsync. While I can expire older images, I do not bother.
When a triplet of backup disks (I do a 3 way rotation) finally fill up, I just
retire them to offsite storage."
<<https://www.redhat.com/archives/fedora-list/2004-October/msg02363.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. :)
>
These remain as elusive as the space herpe
> ><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.
>
>From a very good HowTo---
<<http://www.debian-administration.org/articles/410>>
Filesystems
When it comes to using LVM effectively it is worth considering the
filesystem that you wish to use upon your logical volumes.
If you choose a filesystem which doesn't support resizing then
increasing the size of your LVM volumes would be pointless. Here is a
brief list of the resizable filesystems:
increase increase
while while
filesystem mounted unmounted decrease
ext2fs yes yes yes
ext3fs yes yes yes
ReiserFS yes yes yes
JFS no no no
XFS yes no no
Note that some filesystems can be increased in size, but cannot be reduced.
If I've missed one you're familiar with please do let me know.
> >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.
When fsck has to be run it can take a long time and, depending on the
problem severity, take a really long time. Some times forever. Which
means it can't fix the problem.
Journaling file systems reduce the need for fsck to major failures.
Some people save their journal logs at regular intervals to have
something to recover from so fsck is never done, hopefully?
More information about the Discuss
mailing list