* Re: Good, recent FS comparison?
2005-09-18 9:15 ` Tyler
@ 2005-09-18 11:29 ` Raz Ben-Jehuda(caro)
2005-09-18 12:32 ` Al Boldi
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Raz Ben-Jehuda(caro) @ 2005-09-18 11:29 UTC (permalink / raw)
To: Tyler; +Cc: Al Boldi, linux-fsdevel, Linux RAID Mailing List, linux-xfs
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
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Good, recent FS comparison?
2005-09-18 9:15 ` Tyler
2005-09-18 11:29 ` Raz Ben-Jehuda(caro)
@ 2005-09-18 12:32 ` Al Boldi
2005-09-18 13:27 ` assembly aborted, superblock is missing. (need help!) JaniD++
2005-09-18 16:34 ` Good, recent FS comparison? Matt Stegman
2005-12-27 23:33 ` James Northrup
3 siblings, 1 reply; 20+ messages in thread
From: Al Boldi @ 2005-09-18 12:32 UTC (permalink / raw)
To: Tyler; +Cc: linux-fsdevel, Linux RAID Mailing List, linux-xfs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* assembly aborted, superblock is missing. (need help!)
2005-09-18 12:32 ` Al Boldi
@ 2005-09-18 13:27 ` JaniD++
2005-09-19 22:27 ` Mike Tran
0 siblings, 1 reply; 20+ messages in thread
From: JaniD++ @ 2005-09-18 13:27 UTC (permalink / raw)
To: linux-raid
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
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: assembly aborted, superblock is missing. (need help!)
2005-09-18 13:27 ` assembly aborted, superblock is missing. (need help!) JaniD++
@ 2005-09-19 22:27 ` Mike Tran
0 siblings, 0 replies; 20+ messages in thread
From: Mike Tran @ 2005-09-19 22:27 UTC (permalink / raw)
To: JaniD++; +Cc: linux-raid
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
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Good, recent FS comparison?
2005-09-18 9:15 ` Tyler
2005-09-18 11:29 ` Raz Ben-Jehuda(caro)
2005-09-18 12:32 ` Al Boldi
@ 2005-09-18 16:34 ` Matt Stegman
2005-09-20 21:00 ` George N. White III
2005-12-27 23:33 ` James Northrup
3 siblings, 1 reply; 20+ messages in thread
From: Matt Stegman @ 2005-09-18 16:34 UTC (permalink / raw)
To: Tyler; +Cc: Al Boldi, linux-fsdevel, Linux RAID Mailing List, linux-xfs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Good, recent FS comparison?
2005-09-18 16:34 ` Good, recent FS comparison? Matt Stegman
@ 2005-09-20 21:00 ` George N. White III
0 siblings, 0 replies; 20+ messages in thread
From: George N. White III @ 2005-09-20 21:00 UTC (permalink / raw)
To: Matt Stegman; +Cc: Al Boldi, linux-fsdevel, Linux RAID Mailing List, linux-xfs
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>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Good, recent FS comparison?
2005-09-18 9:15 ` Tyler
` (2 preceding siblings ...)
2005-09-18 16:34 ` Good, recent FS comparison? Matt Stegman
@ 2005-12-27 23:33 ` James Northrup
2005-12-28 1:45 ` Randy.Dunlap
3 siblings, 1 reply; 20+ messages in thread
From: James Northrup @ 2005-12-27 23:33 UTC (permalink / raw)
To: Tyler, Al Boldi; +Cc: linux-fsdevel, Linux RAID Mailing List, linux-xfs
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Good, recent FS comparison?
2005-12-27 23:33 ` James Northrup
@ 2005-12-28 1:45 ` Randy.Dunlap
2005-12-28 2:02 ` James Northrup
0 siblings, 1 reply; 20+ messages in thread
From: Randy.Dunlap @ 2005-12-28 1:45 UTC (permalink / raw)
To: James Northrup; +Cc: pml, a1426z, linux-fsdevel, linux-raid, linux-xfs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Good, recent FS comparison?
2005-12-28 1:45 ` Randy.Dunlap
@ 2005-12-28 2:02 ` James Northrup
0 siblings, 0 replies; 20+ messages in thread
From: James Northrup @ 2005-12-28 2:02 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: pml, a1426z, linux-fsdevel, linux-raid, linux-xfs
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
>
^ permalink raw reply [flat|nested] 20+ messages in thread