lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A20315AE59B5C34585629E258D76A97C335960@34093-C3-EVS3.exchange.rackspace.com>
Date:	Fri, 2 May 2008 17:24:22 -0500
From:	"David Lethe" <david@...tools.com>
To:	"Kasper Sandberg" <lkml@...anurb.dk>,
	"David Greaves" <david@...eaves.com>
Cc:	"David Rees" <drees76@...il.com>, <alex14641@...oo.com>,
	"Justin Piszcz" <jpiszcz@...idpixels.com>,
	<linux-raid@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: Sharing disks amoung multiple software RAIDs



-----Original Message-----
From: Kasper Sandberg [mailto:lkml@...anurb.dk] 
Sent: Friday, May 02, 2008 4:44 PM
To: David Greaves
Cc: David Rees; David Lethe; alex14641@...oo.com; Justin Piszcz; linux-raid@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: Re: Sharing disks amoung multiple software RAIDs

On Fri, 2008-05-02 at 09:25 +0100, David Greaves wrote:
> Kasper Sandberg wrote:
> > Im not treating it as a backup, what i want, is to make sure that if 1
> > disk dies, the data is still intact and ill hopefully be able to run
> > with 1 disk till the newly ordered one arrives
> Probably one of the main design objectives behind RAID/md

Exactly, but once people start saying: "Look how many problems people
post to the thread on
a weekly basis where people lose their data when md rebuilds go bad with
non-shared disks" i begin to worry..

> 
> > So my question remains.. Is md raid1 not suited for this need? would it
> > be safer to run in non-raid1 mode and daily(maybe hourly) rsync
> > everything over to the second disk?
> 
> md is 100% guaranteed perfect or your money back...
> rsync is 100% guaranteed perfect or your money back...
> your backups are 100% guaranteed perfect or your money back...
> your hard drives are 100% guaranteed perfect or your money back...
> your CPU and RAM are 100% guaranteed perfect or your money back...
> your CPU and PSU fans are 100% guaranteed perfect or your money back...
> 
> Clearly if you want to panic over reliability you have lots of choices :)

I do not wish to panic, i merely wished to know if linux MD is believed
to work in most cases, or believed to do all sorts of weird stuff when
resyncing :)

> 
> David
> PS, FWIW md has saved my data* countless times over the past 'n' years in
> exactly the scenario you describe.

It has also been useful to people i know, i just wished to be sure :)
and as Keld Jørn Simonsen and Helge Hafting's comments seems to confirm,
linux md IS nice and stable :)

and as said, what im looking for isnt an in-box backup solution, merely
safety in case one disk burns :)

> 
> *(or more accurately has saved me from having to restore my data)
=======================
Since I am the person that wrote that "Look how many problems people
post to the thread on a weekly basis where people lose their data when md rebuilds go bad with
non-shared disks", I think need to clarify.
 
I was being too literal. md is a good solution (I use it myself).  However, the OP wanted to "Make sure that if one disk dies, the data is still in tact".  

Only way to do that is have a good offsite backup.

Nothing can prevent opportunity for data loss.  I don't care what RAID level (with single redundancy) you use or whether you have software or hardware-based RAID .. rebuilds can not reconstruct data if you are in degraded mode and have an unrecoverable read error on surviving disks.  It is not md's job or design point to insure data consistency check/repairs are run 24x7.  As such, by definition, there is no way to insure that a md rebuild will always be successful.

David
---------





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ