[ale] XFS on Linux - Is it ready for prime time?

Greg Freemyer greg.freemyer at gmail.com
Thu Apr 22 18:40:22 EDT 2010


Greg,

In Jim's proposal each mirror has 2 disks with valid data and a hot
spare with no data.

In what I proposed, all 3 drives in a mirror would have valid data on them.

In case of failure, the hotspare I mentioned could then be pulled in
and synced, but you have a full 2-disk mirror even before that
happens.

Also, if you have a read intensive multi-threaded app (or collection
of apps), it can be doing reads from all three parts of the mirror
simultaneously.

ie.
seek drive 0 to LBA x and read (wait milliseconds for done) &
seek drive 1 to LBA y and read (wait milliseconds for done) &
seek drive 2 to LBA z and read (wait milliseconds for done) &

provide data to apps asynchronously as each seek/read completes

So in theory with a random i/o read load, a 3-disk mirror should be 3x
as fast as a single disk.  (Reality may disagree.  I haven't
benchmarked it.)

Also in theory the writes have to go to all 3 drives, but that should
happen more or less in parallel, so you still have the same write
performance as a single drive.

Greg


On Thu, Apr 22, 2010 at 5:55 PM, Greg Clifton <gccfof5 at gmail.com> wrote:
> Yeah, I went to GA Public school, but I home schooled (actually the wife,
> AND I married up) the chillern and that's why #1 graduated SCL from GA Tech
> and #3 is graduating SCL from SCAD. But my problem wasn't so much the
> reading as the semantics. Got the words, but mistook the meaning. When you
> said a spare for each mirrored pair I took it to mean a spare for each half
> of the mirror (as in pair of striped drives), not spare for each complete
> mirror.
>
> Now, if I have it right on what you were suggesting, I'm not sure I
> understand the diff between that and what GF suggested. You were talking
> about 6 drives total, with 3 sets of 2 striped drives, one striped pair is
> mirrored to another striped pair and then the 3rd striped pair is the hot
> spare, correct? So how is his config different?
>
> On Thu, Apr 22, 2010 at 3:17 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
>>
>> reading -1 . math -1 . must have gone to public school in Georgia...
>>
>> :-)
>>
>> On Thu, Apr 22, 2010 at 3:10 PM, Lightner, Jeff <jlightner at water.com>
>> wrote:
>>>
>>> Maybe not great with reading either – he said per active PAIR not SPARE.
>>> :p
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Greg
>>> Clifton
>>> Sent: Thursday, April 22, 2010 2:43 PM
>>> To: Atlanta Linux Enthusiasts - Yes! We run Linux!
>>> Subject: Re: [ale] XFS on Linux - Is it ready for prime time?
>>>
>>>
>>>
>>> Hey, I'm not great with math, but if you have one hot spare for each
>>> active spare, wouldn't you need mirrored quadruplets?
>>>
>>> On Thu, Apr 22, 2010 at 2:26 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
>>>
>>> RAID 5 was an invention for a time when hard drives were total crap tons
>>> of money. The pain of losing a drive in a RAID 5 array is just no longer
>>> balanced by the cost of the drives. If a 1TB drive is only $100, it's
>>> bluntly dirt cheap now to have a hot spare in a 4 active drive RAID 10
>>> system. The recovery is much easier and faster when checksums don't have to
>>> be calculated for every stinking block on the drive(s).
>>>
>>> My ideal rig: Striped array for speed composed of mirrored triplets - 2
>>> active, one hot spare per active pair.
>>>
>>>
>>>
>>> On Thu, Apr 22, 2010 at 1:05 PM, Greg Clifton <gccfof5 at gmail.com> wrote:
>>>
>>> Shift in focus to the hardware side of the equation. This thread
>>> concentrates on software generated corruption issues, but I have some
>>> hardware related questions. First, with RAIDed hard drives, are any file
>>> systems more or less likely to cause (or minimize) the likelihood of
>>> corruption of the array and if so, why? Second Greg F (and others) have
>>> commented on NOT using RAID 5 (and RAID 6) esp. with large hard drives.
>>> Looks like 1 or 2 TB hard drives will soon be "standard issue" for
>>> everything but notebook computers. So does that mean that RAID should be
>>> considered 'dead,' except for 0, 1, 10? Third, would SSDs solve the failure
>>> from bad sector issues with HDDs and thus be safe for RAID 5/6
>>> implementations?
>>>
>>>
>>>
>>> On Thu, Apr 22, 2010 at 9:41 AM, Ed Cashin <ecashin at noserose.net> wrote:
>>>
>>> On Wed, Apr 21, 2010 at 9:34 PM, Doug McNash <dmcnash at charter.net> wrote:
>>> ...
>>>
>>> > Does anyone out there use xfs? How about a suggestion for a stable
>>> > replacement.
>>>
>>> If you use the xfs in the mainline kernel, it's a crap shoot because
>>> of the amount of churn in the code, but
>>> if you use a long-term kernel like 2.6.16.y, 2.6.27.y, or the kernels
>>> maintained by distros, then it ought to be stable (as long as the
>>> distro has enough of a user base for other people to find the xfs
>>> bugs first).
>>>
>>> --
>>>  Ed Cashin <ecashin at noserose.net>
>>>  http://noserose.net/e/
>>>  http://www.coraid.com/
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>> --
>>> --
>>>
>>> James P. Kinney III
>>> Actively in pursuit of Life, Liberty and Happiness
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>>
>>> Proud partner. Susan G. Komen for the Cure.
>>>
>>> Please consider our environment before printing this e-mail or
>>> attachments.
>>> ----------------------------------
>>> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
>>> confidential information and is for the sole use of the intended
>>> recipient(s). If you are not the intended recipient, any disclosure,
>>> copying, distribution, or use of the contents of this information is
>>> prohibited and may be unlawful. If you have received this electronic
>>> transmission in error, please reply immediately to the sender that you have
>>> received the message in error, and delete it. Thank you.
>>> ----------------------------------
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>
>>
>>
>> --
>> --
>> James P. Kinney III
>> Actively in pursuit of Life, Liberty and Happiness
>>
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>



-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
CNN/TruTV Aired Forensic Imaging Demo -
   http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com



More information about the Ale mailing list