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

Thu Apr 22 15:21:48 EDT 2010

Most of the array vendors out there allow for SSDs these days.   They
generally propose something like SSDs for the most performance sensitive
data, fibre drives for somewhat performance sensitive data and ATA
drives for the rest all in the same array.

Also there's companies selling PCI boards that are SSDs so you can just
add one to an existing server that doesn't support SSDs otherwise.
Check out a company called RamSan for those and some fairly good
whitepapers.

One problem with SSDs is they use flash which degrades over time.
RamSan says they have an algorithm that directs which bits are written
where so balances this to extend the life of the SSD.   I saw similar
discussion (maybe even the same one) at a presentation at AUUG last year
but have since lost the literature for that.

RamSan says they also make RAM based systems that don't have that
problem.

________________________________

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Greg
Clifton
Sent: Thursday, April 22, 2010 3:00 PM
To: Atlanta Linux Enthusiasts - Yes! We run Linux!
Subject: Re: [ale] XFS on Linux - Is it ready for prime time?

Any feedback on the SSD question? They are inherently more reliable (by
at least an order of magnitude), no? Read and Write Performance is going
up as well as capacities, and prices are coming down. A multi TB SSD
array is probably not something that most of us could afford to park at
home just yet, but maybe in another 2-5 yrs?

GC

On Thu, Apr 22, 2010 at 2:44 PM, Greg Freemyer <greg.freemyer at gmail.com>
wrote:

Jim,

Linux mdraid supports 3 drive mirrors.  You should have similar write
performance to a 2 drive mirror and improved read-performance.

So if your using mdraid, you might want to consider raid 10 with 3
drive mirrors, and maybe one hot spare for the whole array.

Greg

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
>
>

--

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-ret
rieved/

The Norcross Group
The Intersection of Evidence & Technology

http://www.norcrossgroup.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

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.
----------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100422/99055cdb/attachment.html 