Good, recent FS comparison?

Good, recent FS comparison?

[Ewan Grantham]

I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
prepared to follow my normal pattern of installing ext3 as the
filesystem. However, I saw the interview with Hans Reiser about
ReiserFS4, and am now wondering if reiser has really improved enough
to use it, or if ext3 is still the way to go?

Any thoughts?

Re: Good, recent FS comparison?

[Tyler]

You'd be best off trying some tests of your own, using files of the size 
and quantity you expect to use on a regular basis.  I would consider 
ext3, xfs, and reiser3/4... and run some tests with them.  We've had 
really good luck using XFS on large raids, I personally had a bad 
experience with reiserfs 3, it lost data on a USB based drive, as if it 
were never even there, even after trying the recovery tools.

Regards,
Tyler.

Ewan Grantham wrote:

>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
>prepared to follow my normal pattern of installing ext3 as the
>filesystem. However, I saw the interview with Hans Reiser about
>ReiserFS4, and am now wondering if reiser has really improved enough
>to use it, or if ext3 is still the way to go?
>
>Any thoughts?
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.0/103 - Release Date: 9/15/2005

Re: Good, recent FS comparison?

[Jon Lewis]

On Thu, 15 Sep 2005, Tyler wrote:

> You'd be best off trying some tests of your own, using files of the size and 
> quantity you expect to use on a regular basis.  I would consider ext3, xfs, 
> and reiser3/4... and run some tests with them.  We've had really good luck 
> using XFS on large raids, I personally had a bad experience with reiserfs 3,

What kernels/XFS versions have you had good luck with?  I have one large 
raid with XFS, and it keeps doing:

Corruption of in-memory data detected.  Shutting down filesystem

umount/mount fixes it...for a few days.  I gave SGI's latest 2.4 kernel 
CVS tree a try, and found it broke NFS export of XFS, so I couldn't run it 
long enough to see if it fixed the first problem.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                | 
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

Re: Good, recent FS comparison?

[Tyler]

Jon Lewis wrote:
> What kernels/XFS versions have you had good luck with?  I have one large 
> raid with XFS, and it keeps doing:
> 
> Corruption of in-memory data detected.  Shutting down filesystem
> 
> umount/mount fixes it...for a few days.  I gave SGI's latest 2.4 kernel 
> CVS tree a try, and found it broke NFS export of XFS, so I couldn't run 
> it long enough to see if it fixed the first problem.
> 
> ----------------------------------------------------------------------
>  Jon Lewis                   |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                | _________ 
> http://www.lewis.org/~jlewis/pgp for PGP public key_________

A debian 3.1 Sarge sytem running kernel 2.6.11.7 (vanilla), and xfsprogs 
v2.6.28-1.

I did a search on google for those errors.. the ones I spotted, that 
seemed interesting, mentioned problems with kernel 2.6.11.6, 2.6.13 
(using SGI-XFS CVS), but that 2.6.12 (SGI-XFS CVS-2005-06-14_05:00_UTC) 
was working without a problem.

Regards,
Tyler.


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.0/103 - Release Date: 9/15/2005

Re: Good, recent FS comparison?

[Al Boldi]

Tyler wrote:
> Ewan Grantham wrote:
> >I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
> >prepared to follow my normal pattern of installing ext3 as the
> >filesystem. However, I saw the interview with Hans Reiser about
> >ReiserFS4, and am now wondering if reiser has really improved enough
> >to use it, or if ext3 is still the way to go?
>
> You'd be best off trying some tests of your own, using files of the size
> and quantity you expect to use on a regular basis.  I would consider
> ext3, xfs, and reiser3/4... and run some tests with them.  We've had
> really good luck using XFS on large raids, I personally had a bad
> experience with reiserfs 3, it lost data on a USB based drive, as if it
> were never even there, even after trying the recovery tools.

Don't touch anything that doesn't do ordered-mode journaling, especially if 
you use raid, unless your data-consistency requirements don't require this.

XFS is best, but does not support ordered-mode.
reiser4 is still new.
ext3 is rock-solid!

--
Al

Re: Good, recent FS comparison?

[Tyler]

Al Boldi wrote:

>Tyler wrote:
>  
>
>>Ewan Grantham wrote:
>>    
>>
>>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
>>>prepared to follow my normal pattern of installing ext3 as the
>>>filesystem. However, I saw the interview with Hans Reiser about
>>>ReiserFS4, and am now wondering if reiser has really improved enough
>>>to use it, or if ext3 is still the way to go?
>>>      
>>>
>>You'd be best off trying some tests of your own, using files of the size
>>and quantity you expect to use on a regular basis.  I would consider
>>ext3, xfs, and reiser3/4... and run some tests with them.  We've had
>>really good luck using XFS on large raids, I personally had a bad
>>experience with reiserfs 3, it lost data on a USB based drive, as if it
>>were never even there, even after trying the recovery tools.
>>    
>>
>
>Don't touch anything that doesn't do ordered-mode journaling, especially if 
>you use raid, unless your data-consistency requirements don't require this.
>
>XFS is best, but does not support ordered-mode.
>reiser4 is still new.
>ext3 is rock-solid!
>
>--
>Al
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>
Al... you've given us some "do's" .. can you give us some "why's" to go 
along with them? :)  I would appreciate a run-down with some more 
specific info as to what/why.

Thanks,
Tyler.


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 9/16/2005

Re: Good, recent FS comparison?

[Raz Ben-Jehuda(caro)]

what is ordered mode that xfs doesn't support ?

On 9/18/05, Tyler <pml@dtbb.net> wrote:
> 
> Al Boldi wrote:
> 
> >Tyler wrote:
> >
> >
> >>Ewan Grantham wrote:
> >>
> >>
> >>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
> >>>prepared to follow my normal pattern of installing ext3 as the
> >>>filesystem. However, I saw the interview with Hans Reiser about
> >>>ReiserFS4, and am now wondering if reiser has really improved enough
> >>>to use it, or if ext3 is still the way to go?
> >>>
> >>>
> >>You'd be best off trying some tests of your own, using files of the size
> >>and quantity you expect to use on a regular basis.  I would consider
> >>ext3, xfs, and reiser3/4... and run some tests with them.  We've had
> >>really good luck using XFS on large raids, I personally had a bad
> >>experience with reiserfs 3, it lost data on a USB based drive, as if it
> >>were never even there, even after trying the recovery tools.
> >>
> >>
> >
> >Don't touch anything that doesn't do ordered-mode journaling, especially if
> >you use raid, unless your data-consistency requirements don't require this.
> >
> >XFS is best, but does not support ordered-mode.
> >reiser4 is still new.
> >ext3 is rock-solid!
> >
> >--
> >Al
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> Al... you've given us some "do's" .. can you give us some "why's" to go
> along with them? :)  I would appreciate a run-down with some more
> specific info as to what/why.
> 
> Thanks,
> Tyler.
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 9/16/2005
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Raz

Re: Good, recent FS comparison?

[Al Boldi]

Tyler wrote:
> Al Boldi wrote:
> >Don't touch anything that doesn't do ordered-mode journaling, especially
> > if you use raid, unless your data-consistency requirements don't require
> > this.
>
> Al... you've given us some "do's" .. can you give us some "why's" to go
> along with them? :)  I would appreciate a run-down with some more
> specific info as to what/why.

see 'XFS corruption on power-blackout' thread

> >XFS is best, but does not support ordered-mode.
Highest performance ratio available due to low CPU usage.

> >reiser4 is still new.
New, but promising.

> >ext3 is rock-solid!
Low performance ratio due to high CPU usage.

--
Al

assembly aborted, superblock is missing. (need help!)

[JaniD++]

Hello list!

I have try to switch from 2.6.13 to 14-rc1, but this kernel breaks my
device!

The problem:
# mdadm -A -R -f  /dev/md31 /dev/md1 /dev/md2 /dev/md3 /dev/md4
mdadm: no RAID superblock on /dev/md1
mdadm: /dev/md1 has no superblock - assembly aborted


md31 is a 8TB raid0 device.

the 2. dev:
# mdadm -E /dev/md2
/dev/md2:
          Magic : a92b4efc
        Version : 00.90.02
           UUID : 9a99d340:ab8f6bfc:bc8d42ed:79ce440e
  Creation Time : Sun Jul 17 19:50:11 2005
     Raid Level : raid0
    Device Size : 1953583232 (1863.08 GiB 2000.47 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 31

    Update Time : Sun Jul 17 19:50:11 2005
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 1fd71b51 - correct
         Events : 0.2

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State
this     1       9        2        1      active sync   /dev/md2

   0     0       9        1        0      active sync   /dev/md1
   1     1       9        2        1      active sync   /dev/md2
   2     2       9        3        2      active sync   /dev/md3
   3     3       9        4        3      active sync   /dev/md4

the 3. dev:

# mdadm -E /dev/md3
/dev/md3:
          Magic : a92b4efc
        Version : 00.90.02
           UUID : 9a99d340:ab8f6bfc:bc8d42ed:79ce440e
  Creation Time : Sun Jul 17 19:50:11 2005
     Raid Level : raid0
    Device Size : 1953583232 (1863.08 GiB 2000.47 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 31

    Update Time : Sun Jul 17 19:50:11 2005
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 1fd71b54 - correct
         Events : 0.2

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State
this     2       9        3        2      active sync   /dev/md3

   0     0       9        1        0      active sync   /dev/md1
   1     1       9        2        1      active sync   /dev/md2
   2     2       9        3        2      active sync   /dev/md3
   3     3       9        4        3      active sync   /dev/md4



the 4.dev:

# mdadm -E /dev/md4
/dev/md4:
          Magic : a92b4efc
        Version : 00.90.02
           UUID : 9a99d340:ab8f6bfc:bc8d42ed:79ce440e
  Creation Time : Sun Jul 17 19:50:11 2005
     Raid Level : raid0
    Device Size : 1953583232 (1863.08 GiB 2000.47 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 31

    Update Time : Sun Jul 17 19:50:11 2005
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 1fd71b57 - correct
         Events : 0.2

     Chunk Size : 32K

      Number   Major   Minor   RaidDevice State
this     3       9        4        3      active sync   /dev/md4

   0     0       9        1        0      active sync   /dev/md1
   1     1       9        2        1      active sync   /dev/md2
   2     2       9        3        2      active sync   /dev/md3
   3     3       9        4        3      active sync   /dev/md4


but the md1 (the first dev) is this:
# mdadm -E /dev/md1
mdadm: No super block found on /dev/md1 (Expected magic a92b4efc, got
56dfa32e)


How can I fix this?
Can somebody help?

Thanks
Janos

Re: Good, recent FS comparison?

[Matt Stegman]

This has been discussed on the mailing list before.  Quick rundown:

"Ordered mode" means that a file's metadata isn't written until after the
file's data.  On XFS, which doesn't use ordered mode, under certain
circumstances you may see files which are the correct size, with correct
times, etc, but with only null bytes for the data.

In my experience it's not that big a deal; I can almost always easily
recreate data which could be lost by being written out just before a crash
or power loss.  I put important systems on an UPS and use stable kernels,
and I've never personally seen the null data problem.

Currently, I believe only ext3 and reiserfs support ordered mode.  I'm not
sure if reiser4's journaling is ordered or not.

-- 
Matt Stegman

On Sun, 18 Sep 2005, Tyler wrote:
>
> Al Boldi wrote:
>
> >Don't touch anything that doesn't do ordered-mode journaling, especially if
> >you use raid, unless your data-consistency requirements don't require this.
> >
> >XFS is best, but does not support ordered-mode.
> >reiser4 is still new.
> >ext3 is rock-solid!
> >
>
> Al... you've given us some "do's" .. can you give us some "why's" to go
> along with them? :)  I would appreciate a run-down with some more
> specific info as to what/why.

Re: Good, recent FS comparison?

[Jonathan Schmidt]

I've got the same opportunity as well -- setting up a new RAID, and having 
to choose a filesystem.  I've used reiser3 and liked it, but I'm weary of 
reiser4 just because it's so new.  My one and only concern is data 
integrity.  CPU use, efficiency, etc are of no concern.  It sounds like the 
reason to use XFS is because of speed, so that doesn't interest me.

Are there any filesystems with error-correcting built in?  Reiser4 could 
probably do it with a plugin, but Hans Reiser would probably also tell me 
that error correction has no place in the filesystem code :)  Maybe I'm just 
paranoid.

"Ewan Grantham" <ewan.grantham@gmail.com> wrote in message 
news:6d5bedd8050915131148b8108a@mail.gmail.com...
> I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
> prepared to follow my normal pattern of installing ext3 as the
> filesystem. However, I saw the interview with Hans Reiser about
> ReiserFS4, and am now wondering if reiser has really improved enough
> to use it, or if ext3 is still the way to go?
>
> Any thoughts?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: assembly aborted, superblock is missing. (need help!)

[Mike Tran]

Hi Janos,

The problem with disappearing MD superblock must be investigated. :(

It is safe to re-create the raid0 array:
mdadm -C /dev/md31 -l 0 -c 32 -n 4 /dev/md1 /dev/md2 /dev/md3 /dev/md4

--
Regards,
Mike Tran

JaniD++ wrote:

>Hello list!
>
>I have try to switch from 2.6.13 to 14-rc1, but this kernel breaks my
>device!
>
>The problem:
># mdadm -A -R -f  /dev/md31 /dev/md1 /dev/md2 /dev/md3 /dev/md4
>mdadm: no RAID superblock on /dev/md1
>mdadm: /dev/md1 has no superblock - assembly aborted
>
>
>md31 is a 8TB raid0 device.
>
>the 2. dev:
># mdadm -E /dev/md2
>/dev/md2:
>          Magic : a92b4efc
>        Version : 00.90.02
>           UUID : 9a99d340:ab8f6bfc:bc8d42ed:79ce440e
>  Creation Time : Sun Jul 17 19:50:11 2005
>     Raid Level : raid0
>    Device Size : 1953583232 (1863.08 GiB 2000.47 GB)
>   Raid Devices : 4
>  Total Devices : 4
>Preferred Minor : 31
>
>    Update Time : Sun Jul 17 19:50:11 2005
>          State : active
> Active Devices : 4
>Working Devices : 4
> Failed Devices : 0
>  Spare Devices : 0
>       Checksum : 1fd71b51 - correct
>         Events : 0.2
>
>     Chunk Size : 32K
>
>      Number   Major   Minor   RaidDevice State
>this     1       9        2        1      active sync   /dev/md2
>
>   0     0       9        1        0      active sync   /dev/md1
>   1     1       9        2        1      active sync   /dev/md2
>   2     2       9        3        2      active sync   /dev/md3
>   3     3       9        4        3      active sync   /dev/md4
>
>the 3. dev:
>
># mdadm -E /dev/md3
>/dev/md3:
>          Magic : a92b4efc
>        Version : 00.90.02
>           UUID : 9a99d340:ab8f6bfc:bc8d42ed:79ce440e
>  Creation Time : Sun Jul 17 19:50:11 2005
>     Raid Level : raid0
>    Device Size : 1953583232 (1863.08 GiB 2000.47 GB)
>   Raid Devices : 4
>  Total Devices : 4
>Preferred Minor : 31
>
>    Update Time : Sun Jul 17 19:50:11 2005
>          State : active
> Active Devices : 4
>Working Devices : 4
> Failed Devices : 0
>  Spare Devices : 0
>       Checksum : 1fd71b54 - correct
>         Events : 0.2
>
>     Chunk Size : 32K
>
>      Number   Major   Minor   RaidDevice State
>this     2       9        3        2      active sync   /dev/md3
>
>   0     0       9        1        0      active sync   /dev/md1
>   1     1       9        2        1      active sync   /dev/md2
>   2     2       9        3        2      active sync   /dev/md3
>   3     3       9        4        3      active sync   /dev/md4
>
>
>
>the 4.dev:
>
># mdadm -E /dev/md4
>/dev/md4:
>          Magic : a92b4efc
>        Version : 00.90.02
>           UUID : 9a99d340:ab8f6bfc:bc8d42ed:79ce440e
>  Creation Time : Sun Jul 17 19:50:11 2005
>     Raid Level : raid0
>    Device Size : 1953583232 (1863.08 GiB 2000.47 GB)
>   Raid Devices : 4
>  Total Devices : 4
>Preferred Minor : 31
>
>    Update Time : Sun Jul 17 19:50:11 2005
>          State : active
> Active Devices : 4
>Working Devices : 4
> Failed Devices : 0
>  Spare Devices : 0
>       Checksum : 1fd71b57 - correct
>         Events : 0.2
>
>     Chunk Size : 32K
>
>      Number   Major   Minor   RaidDevice State
>this     3       9        4        3      active sync   /dev/md4
>
>   0     0       9        1        0      active sync   /dev/md1
>   1     1       9        2        1      active sync   /dev/md2
>   2     2       9        3        2      active sync   /dev/md3
>   3     3       9        4        3      active sync   /dev/md4
>
>
>but the md1 (the first dev) is this:
># mdadm -E /dev/md1
>mdadm: No super block found on /dev/md1 (Expected magic a92b4efc, got
>56dfa32e)
>
>
>How can I fix this?
>Can somebody help?
>
>Thanks
>Janos
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

Re: Good, recent FS comparison?

[George N. White III]

On Sun, 18 Sep 2005, Matt Stegman wrote:

> This has been discussed on the mailing list before.  Quick rundown:
>
> "Ordered mode" means that a file's metadata isn't written until after the
> file's data.  On XFS, which doesn't use ordered mode, under certain
> circumstances you may see files which are the correct size, with correct
> times, etc, but with only null bytes for the data.

Another way to look at this: in some case, e.g., transaction processing,
the priority is to make sure no data are lost.  The opposite situation is
where you have large volumes of data coming in, e.g., remote sensing,
rendering farms, big numerical simulations.  If something breaks you are
losing data until the system is back.  With XFS you have a consistent 
filesystem immediately, but you may want to look carefully at the files
being written when the problem occurred.

> In my experience it's not that big a deal; I can almost always easily
> recreate data which could be lost by being written out just before a crash
> or power loss.  I put important systems on an UPS and use stable kernels,
> and I've never personally seen the null data problem.

Clients and other data sources like satellite dishes often break at
inconvenient times.

Write a large structured file like hdf from an NFS client and pull the
network plug or turn off the client when the client job finishes but 
before the data has all been written.  You should endup with a consistent
filesystem but a sparse file.

> Currently, I believe only ext3 and reiserfs support ordered mode.  I'm not
> sure if reiser4's journaling is ordered or not.

I don't thnk you can make a blanket statement -- different horses for 
different courses.

-- 
George N. White III  <aa056@chebucto.ns.ca>

Re: Good, recent FS comparison?

[Jamie Lokier]

Al Boldi wrote:
> ext3 is rock-solid!

If only.  Recently I had a system come up after a power cycle with a
directory where reading any file in that directory gives an I/O error.
The disk is fine, and it's using ext3 in ordered mode, with IDE
write-caching disabled to be sure.

So while ext3 is good, I'm not convinced it's rock solid.

-- Jamie

Re: Good, recent FS comparison?

[Al Boldi]

Jamie Lokier wrote:
> Al Boldi wrote:
> > ext3 is rock-solid!
>
> If only.  Recently I had a system come up after a power cycle with a
> directory where reading any file in that directory gives an I/O error.
> The disk is fine, and it's using ext3 in ordered mode, with IDE
> write-caching disabled to be sure.

2.4 or 2.6?

In 2.4 try a reboot and force an fsck before mounting.

--
Al

Re: Good, recent FS comparison?

[Jamie Lokier]

Al Boldi wrote:
> Jamie Lokier wrote:
> > Al Boldi wrote:
> > > ext3 is rock-solid!
> >
> > If only.  Recently I had a system come up after a power cycle with a
> > directory where reading any file in that directory gives an I/O error.
> > The disk is fine, and it's using ext3 in ordered mode, with IDE
> > write-caching disabled to be sure.
> 
> 2.4 or 2.6?
> 
> In 2.4 try a reboot and force an fsck before mounting.

2.4.26, uclinux - it's an embedded device.

Doing an fsck before mounting would be an unacceptable boot-time delay.

Why do you suggest that, specifically for 2.4?  Is there a known
problem with 2.4 and ext3?

Thanks,
-- Jamie

Re: Good, recent FS comparison?

[Al Boldi]

Jamie Lokier wrote:
> Al Boldi wrote:
> > Jamie Lokier wrote:
> > > Al Boldi wrote:
> > > > ext3 is rock-solid!
> > >
> > > If only.  Recently I had a system come up after a power cycle with a
> > > directory where reading any file in that directory gives an I/O error.
> > > The disk is fine, and it's using ext3 in ordered mode, with IDE
> > > write-caching disabled to be sure.
>
> 2.4.26, uclinux - it's an embedded device.
>
> Doing an fsck before mounting would be an unacceptable boot-time delay.
>
> Why do you suggest that, specifically for 2.4?  Is there a known
> problem with 2.4 and ext3?

I saw this at least once on 2.4.18. A forced fsck on reboot fixed it.
2.4.31 looks ok.

--
Al

Re: Good, recent FS comparison?

[James Northrup]

late reply... but ...

this is a benchmark I performed for grins sometime about February using two 
PATA udma5 volumes as software raid0.

http://kiwi.io-informatics.com/~jnorthrup/filesystem%20benchresults.xls


the uname -a isn't anywhere to be found but it was circa 2.6.8

the script is rpesumably still useful, for an experienced data groomer.

http://kiwi.io-informatics.com/~jnorthrup/fsbench

----- Original Message ----- 
From: "Tyler" <pml@dtbb.net>
To: "Al Boldi" <a1426z@gawab.com>
Cc: <linux-fsdevel@vger.kernel.org>; "Linux RAID Mailing List" 
<linux-raid@vger.kernel.org>; <linux-xfs@oss.sgi.com>
Sent: Sunday, September 18, 2005 1:15 AM
Subject: Re: Good, recent FS comparison?


>
> Al Boldi wrote:
>
>>Tyler wrote:
>>
>>>Ewan Grantham wrote:
>>>
>>>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
>>>>prepared to follow my normal pattern of installing ext3 as the
>>>>filesystem. However, I saw the interview with Hans Reiser about
>>>>ReiserFS4, and am now wondering if reiser has really improved enough
>>>>to use it, or if ext3 is still the way to go?
>>>>
>>>You'd be best off trying some tests of your own, using files of the size
>>>and quantity you expect to use on a regular basis.  I would consider
>>>ext3, xfs, and reiser3/4... and run some tests with them.  We've had
>>>really good luck using XFS on large raids, I personally had a bad
>>>experience with reiserfs 3, it lost data on a USB based drive, as if it
>>>were never even there, even after trying the recovery tools.
>>>
>>
>>Don't touch anything that doesn't do ordered-mode journaling, especially 
>>if you use raid, unless your data-consistency requirements don't require 
>>this.
>>
>>XFS is best, but does not support ordered-mode.
>>reiser4 is still new.
>>ext3 is rock-solid!
>>
>>--
>>Al
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> Al... you've given us some "do's" .. can you give us some "why's" to go 
> along with them? :)  I would appreciate a run-down with some more specific 
> info as to what/why.
>
> Thanks,
> Tyler.
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.1/104 - Release Date: 9/16/2005
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Good, recent FS comparison?

[Randy.Dunlap]

On Tue, 27 Dec 2005 15:33:18 -0800 James Northrup wrote:

> late reply... but ...
> 
> this is a benchmark I performed for grins sometime about February using two 
> PATA udma5 volumes as software raid0.
> 
> http://kiwi.io-informatics.com/~jnorthrup/filesystem%20benchresults.xls
> 
> 
> the uname -a isn't anywhere to be found but it was circa 2.6.8
> 
> the script is rpesumably still useful, for an experienced data groomer.
> 
> http://kiwi.io-informatics.com/~jnorthrup/fsbench

Do you have a URL that works?


> ----- Original Message ----- 
> From: "Tyler" <pml@dtbb.net>
> To: "Al Boldi" <a1426z@gawab.com>
> Cc: <linux-fsdevel@vger.kernel.org>; "Linux RAID Mailing List" 
> <linux-raid@vger.kernel.org>; <linux-xfs@oss.sgi.com>
> Sent: Sunday, September 18, 2005 1:15 AM
> Subject: Re: Good, recent FS comparison?
> 
> 
> >
> > Al Boldi wrote:
> >
> >>Tyler wrote:
> >>
> >>>Ewan Grantham wrote:
> >>>
> >>>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
> >>>>prepared to follow my normal pattern of installing ext3 as the
> >>>>filesystem. However, I saw the interview with Hans Reiser about
> >>>>ReiserFS4, and am now wondering if reiser has really improved enough
> >>>>to use it, or if ext3 is still the way to go?
> >>>>
> >>>You'd be best off trying some tests of your own, using files of the size
> >>>and quantity you expect to use on a regular basis.  I would consider
> >>>ext3, xfs, and reiser3/4... and run some tests with them.  We've had
> >>>really good luck using XFS on large raids, I personally had a bad
> >>>experience with reiserfs 3, it lost data on a USB based drive, as if it
> >>>were never even there, even after trying the recovery tools.
> >>>
> >>
> >>Don't touch anything that doesn't do ordered-mode journaling, especially 
> >>if you use raid, unless your data-consistency requirements don't require 
> >>this.
> >>
> >>XFS is best, but does not support ordered-mode.
> >>reiser4 is still new.
> >>ext3 is rock-solid!
> >>
> >>--
> >>Al
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> > Al... you've given us some "do's" .. can you give us some "why's" to go 
> > along with them? :)  I would appreciate a run-down with some more specific 
> > info as to what/why.
> >
> > Thanks,
> > Tyler.


---
~Randy

Re: Good, recent FS comparison?

[James Northrup]

http://ioi.homelinux.net/~jnorthrup/filesystem%20benchresults.xls
http://ioi.homelinux.net/~jnorthrup/fsbench

Sorry, apache was being too helpful here...

----- Original Message ----- 
From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: "James Northrup" <jim@grrrrr.gotdns.com>
Cc: <pml@dtbb.net>; <a1426z@gawab.com>; <linux-fsdevel@vger.kernel.org>; 
<linux-raid@vger.kernel.org>; <linux-xfs@oss.sgi.com>
Sent: Tuesday, December 27, 2005 5:45 PM
Subject: Re: Good, recent FS comparison?


> On Tue, 27 Dec 2005 15:33:18 -0800 James Northrup wrote:
>
>> late reply... but ...
>>
>> this is a benchmark I performed for grins sometime about February using 
>> two
>> PATA udma5 volumes as software raid0.
>>
>> http://kiwi.io-informatics.com/~jnorthrup/filesystem%20benchresults.xls
>>
>>
>> the uname -a isn't anywhere to be found but it was circa 2.6.8
>>
>> the script is rpesumably still useful, for an experienced data groomer.
>>
>> http://kiwi.io-informatics.com/~jnorthrup/fsbench
>
> Do you have a URL that works?
>
>
>> ----- Original Message ----- 
>> From: "Tyler" <pml@dtbb.net>
>> To: "Al Boldi" <a1426z@gawab.com>
>> Cc: <linux-fsdevel@vger.kernel.org>; "Linux RAID Mailing List"
>> <linux-raid@vger.kernel.org>; <linux-xfs@oss.sgi.com>
>> Sent: Sunday, September 18, 2005 1:15 AM
>> Subject: Re: Good, recent FS comparison?
>>
>>
>> >
>> > Al Boldi wrote:
>> >
>> >>Tyler wrote:
>> >>
>> >>>Ewan Grantham wrote:
>> >>>
>> >>>>I've just setup a nice, 6-disk, USB-2 300 Gig/disk array, and was
>> >>>>prepared to follow my normal pattern of installing ext3 as the
>> >>>>filesystem. However, I saw the interview with Hans Reiser about
>> >>>>ReiserFS4, and am now wondering if reiser has really improved enough
>> >>>>to use it, or if ext3 is still the way to go?
>> >>>>
>> >>>You'd be best off trying some tests of your own, using files of the 
>> >>>size
>> >>>and quantity you expect to use on a regular basis.  I would consider
>> >>>ext3, xfs, and reiser3/4... and run some tests with them.  We've had
>> >>>really good luck using XFS on large raids, I personally had a bad
>> >>>experience with reiserfs 3, it lost data on a USB based drive, as if 
>> >>>it
>> >>>were never even there, even after trying the recovery tools.
>> >>>
>> >>
>> >>Don't touch anything that doesn't do ordered-mode journaling, 
>> >>especially
>> >>if you use raid, unless your data-consistency requirements don't 
>> >>require
>> >>this.
>> >>
>> >>XFS is best, but does not support ordered-mode.
>> >>reiser4 is still new.
>> >>ext3 is rock-solid!
>> >>
>> >>--
>> >>Al
>> >>
>> >>-
>> >>To unsubscribe from this list: send the line "unsubscribe linux-raid" 
>> >>in
>> >>the body of a message to majordomo@vger.kernel.org
>> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >>
>> > Al... you've given us some "do's" .. can you give us some "why's" to go
>> > along with them? :)  I would appreciate a run-down with some more 
>> > specific
>> > info as to what/why.
>> >
>> > Thanks,
>> > Tyler.
>
>
> ---
> ~Randy
>