[ubuntu-us-ut] ext3 or XFS

[Bob]

I like ResierFS because when you run a hard drive check, it will be
faster. Apparently ResierFS is 10 - 15X faster when working with files
that are like 1k. But around the same speed with ext3. 

This is also something to consider. The dude that was developing
resierFS might be a murderer so might go to jail for a long time. If
thats the case, there might be a lag in good development for resierFS.
Ext3 and ResierFS would be my choices, and I would pick ResierFS because
a super genius developed it ;) and its faster with smaller files
(apparently, please google for better smarter references) . 
On Mon, 2008-03-17 at 16:07 -0600, Mike Basinger wrote:
> The digital collections are about 1 TB (terabyte) containing hundred
> of thousands image files (jpg, tiff, or pdf).
> 
> Mike
> 
> On Mon, Mar 17, 2008 at 3:33 PM, Trevor Sharpe <tsharpe at xmission.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >  Hash: SHA1
> >
> >
> >
> >  Mike Basinger wrote:
> >  > We are planning to switch a digital collection we run on CnntentDM for
> >  > Windows 2003 using NTFS to Ubuntu Server 8.04 (when it is final). The
> >  > collection is hundreds of thousands of graphic files. Would it make
> >  > sense to using XFS or ResierFS over ext3? I always used ext3 in the
> >  > pass and been happy, but nothing with so many files.
> >  >
> >  > =========================================
> >  > [from vendor, assumed we were going to use RedHat Enterprise and not Ubuntu]
> >  > I saw your recent request to do a Linux evaluation of CONTENTdm and
> >  > wanted to get in touch with you to discuss a potential issue. Linux
> >  > (specifically Red Hat Enterprise Linux) has a fundamental file system
> >  > limitation that can compromise the functionality of CONTENTdm
> >  > collections. I know that you all have a LOT of data and some very
> >  > large collections, so this limitation will almost certainly be
> >  > encountered during your Linux evaluation if you are planning to use
> >  > Red Hat Enterprise. The problem is easy to work around if an alternate
> >  > file system is used, but Red Hat explicitly does not support any file
> >  > systems other than these non-scalable ext2/ext3 volumes. Nearly all
> >  > other Linux distributions support file systems that do not have this
> >  > problem (e.g. XFS, ReiserFS).
> >  >
> >  > Are you planning to deploy CONTENTdm on Red Hat Enterprise Linux? If
> >  > you'd like to discuss this in more detail, let me know a good time to
> >  > reach you and the best number to use.
> >  > =========================================
> >
> >  Mike,
> >
> >  I am reminded of a conversation that Stuart Jansen had on the PLUG list
> >  a couple days ago. The real question to me is, are you looking for
> >  efficient use of space or performance? I have heard that over larger
> >  drives (320+ GB) that ReiserFS is still a more effective use of the
> >  space. Although I understand that you tune XFS for performance.
> >
> >  Its a interesting question, to say the least.
> >
> >  - --- Stuart Jansen's email ---
> >
> >  Today I had a chance to compare ext3 and XFS overhead. Basically, I
> >  created a new XFS filesystem and copied a bunch of data onto it. Then I
> >  created an ext3 filesystem and copied everything from the XFS filesystem
> >  onto it. Most files were under 15M in size. I didn't compare performance
> >  because all I cared about was space efficiency. Count me as another XFS
> >  fan.
> >
> >  /dev/simplicity/scratch mounted on /mnt is ext3
> >  /dev/simplicity/mirror mounted on /data/mirror is xfs
> >
> >  $ df -h /mnt/
> >  Filesystem            Size  Used Avail Use% Mounted on
> >  /dev/mapper/simplicity-scratch
> >                       6.4G  5.8G  348M  95% /mnt
> >  $ df -h /data/mirror/
> >  Filesystem            Size  Used Avail Use% Mounted on
> >  /dev/mapper/simplicity-mirror
> >                       6.5G  5.6G  913M  87% /data/mirror
> >
> >   --- Logical volume ---
> >   LV Name                /dev/simplicity/scratch
> >   VG Name                simplicity
> >   LV UUID                cH3Iu4-oE1k-NoPV-cfBd-t7fU-oKIX-vcq083
> >   LV Write Access        read/write
> >   LV Status              available
> >   # open                 1
> >   LV Size                6.50 GB
> >   Current LE             208
> >   Segments               2
> >   Allocation             inherit
> >   Read ahead sectors     0
> >   Block device           253:6
> >
> >   --- Logical volume ---
> >   LV Name                /dev/simplicity/mirror
> >   VG Name                simplicity
> >   LV UUID                ULZz2r-PUct-mysE-0uHn-bs1Q-4Uvt-2C3Ffj
> >   LV Write Access        read/write
> >   LV Status              available
> >   # open                 1
> >   LV Size                6.50 GB
> >   Current LE             208
> >   Segments               1
> >   Allocation             inherit
> >   Read ahead sectors     0
> >   Block device           253:7
> >
> >  - --- End Stuart's email ---
> >
> >  - --
> >  Trevor Sharpe
> >  E-Mail:         tsharpe at xmission.com
> >  Jabber:         tsharpe at gmail.com
> >  - ----------
> >  Every normal man must be tempted, at times, to spit on his hands, hoist
> >  the black flag, and begin slitting throats.       ---H. L. Mencken
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.6 (GNU/Linux)
> >  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> >  iD8DBQFH3uPERDaxm/9432IRAo+AAJ9K1z9VUb46eH/8Pq106NuFRsCF+gCfRnoa
> >  5y6uZ556fWyeO6n/0ztn0N8=
> >  =CpGB
> >  -----END PGP SIGNATURE-----
> >
> >  --
> >  ubuntu-us-ut mailing list
> >  ubuntu-us-ut at lists.ubuntu.com
> >  https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-ut
> >
> 
> 
> 
> -- 
> Mike Basinger
> mike.basinger at gmail.com
> http://www.mikesplanet.net
>