Re: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-29 Thread Pavel Machek
Hi! > > Well, you could set stripe size to 512B; that way, RAID-5 would be > > *very* slow, but it should have same characteristics as normal disc > > w.r.t. crash. Unrelated data would not be lost, and you'd either get > > old data or new data... > > When you lose a disk during recovery you can

Re: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-29 Thread Andi Kleen
> Well, you could set stripe size to 512B; that way, RAID-5 would be > *very* slow, but it should have same characteristics as normal disc > w.r.t. crash. Unrelated data would not be lost, and you'd either get > old data or new data... When you lose a disk during recovery you can still lose unrela

Re: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-29 Thread Pavel Machek
Hi! > > The nasty part there is that it can affect completely unrelated > > data too (on a traditional disk you normally only lose the data > > that is currently being written) because of of the relationship > > between stripes on different disks. Well, you could set stripe size to 512B; that way

Re: critical bugs in md raid5

2005-01-27 Thread pcg
On Thu, Jan 27, 2005 at 10:51:02AM +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > The nasty part there is that it can affect completely unrelated > data too (on a traditional disk you normally only lose the data > that is currently being written) because of of the relationship > between stripes on

Re: critical bugs in md raid5 and ATA disk failure/recovery modes

2005-01-27 Thread Marc Lehmann
On Thu, Jan 27, 2005 at 10:51:02AM +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > > I disagree. When not working in degraded mode, it's absolutely reasonable > > to e.g. use only the non-parity data. A crash with raid5 is in no way > > Yep. But when you go into degraded mode during the crash recov

Re: critical bugs in md raid5

2005-01-27 Thread Andi Kleen
> I disagree. When not working in degraded mode, it's absolutely reasonable > to e.g. use only the non-parity data. A crash with raid5 is in no way Yep. But when you go into degraded mode during the crash recovery (before the RAID is fully synced again) you lose. > different to a crash without r

Re: critical bugs in md raid5

2005-01-26 Thread pcg
On Thu, Jan 27, 2005 at 06:11:34AM +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > Marc Lehmann <[EMAIL PROTECTED]> writes: > > > > The summary seems to be that the linux raid driver only protects your data > > as long as all disks are fine and the machine never crashes. > > "as long as the machine

Re: critical bugs in md raid5

2005-01-26 Thread Marc Lehmann
On Thu, Jan 27, 2005 at 06:11:34AM +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > Marc Lehmann <[EMAIL PROTECTED]> writes: > > The summary seems to be that the linux raid driver only protects your data > > as long as all disks are fine and the machine never crashes. > > "as long as the machine nev

Re: critical bugs in md raid5

2005-01-26 Thread Andi Kleen
Marc Lehmann <[EMAIL PROTECTED]> writes: > > The summary seems to be that the linux raid driver only protects your data > as long as all disks are fine and the machine never crashes. "as long as the machine never crashes". That's correct. If you think about how RAID 5 works there is no way around

critical bugs in md raid5

2005-01-26 Thread Marc Lehmann
Hi, I want to report a number of problems in the current raid5 code, some of which are pretty annoying, some of which require a superblock reformat. Here's my setup: - dual AMD opteron with 64-bit kernel, 2.6.10/2.6.8.1 - 5 raid disks, 4 standard ide on hda..hdd, one sata-device (that setup gi