Re: Resize on dirty array?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



No, it wasn't *less* reliable than a single drive; you benefited as soon as a
James Peverill wrote:
> 
> In this case the raid WAS the backup... however it seems it turned out
> to be less reliable than the single disks it was supporting.  In the
> future I think I'll make sure my disks have varying ages so they don't
> fail all at once.
> 
be at the moment. With RAID you then stressed the remaining drives to the point
of a second failure (not that you had much choice - you *could* have spent money

> James
> 
>>> RAID is no excuse for backups.
on enough media to mirror your data whilst you played with your only remaining

I can't see where you mention the kernel version you're running? md can perform
validation sync's on a periodic basis in later kernels - Debian's mdadm enables
this in cron.

copy - that's a cost/risk tradeoff you chose not to make. I've made the same
choice in the past - I've been lucky - you were not - sorry.)

> PS: <ctrl><pgup>
> -
David

> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
drive failed. At that point you would have been just as toasted as you may well


PS
Reorganise lines from distributed reply as you like :)

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux