I don't think this quite does it. It sounds like that would give me the spin down capability, but not (to me), the most interesting facility - the ability to have a system with RAID5-equivalent redundancy (i.e. I get N-1 drives worth of storage and can recover perfectly from the loss of 1 drive) but also lets me survive a multiple drive failure with only partial data loss. -----Original Message----- From: Bill Davidsen [mailto:davidsen@xxxxxxx] Sent: Saturday, May 24, 2008 7:22 AM To: Chris Green Cc: Tony Germano; linux-raid@xxxxxxxxxxxxxxx Subject: Re: Proposal: non-striping RAID4 Chris Green wrote: > I would really like to have this functionality. Honestly, its pretty > much perfect for the "home server" application (which I have several > of), where: > > - writes are far less common than reads, > - The system goes hours without any reads and days without any > writes. > - single drive read speed is plenty for the applications that are > sitting on the other side > - a lot of the data is too voluminous to backup (media that can just > be re-ripped or downloaded). > - you want some redundancy beyond a single drive copy, but don't want > to spend a lot of drives on it. The model of "if you lose 1 disk, you > lose nothing, if you lose 2 disks you lose a portion" is better than the > raid5 model of losing everything with a double-disk failure. > - a common access pattern is to do a long sequential read at a slow > rate that takes hours to go through a few gigs (playing media). > I think you can do this right now with a touch of cleverness... Assume you create a raid-1 array, load your data, and call that initialized. From cron, daily or weekly, you set one drive of the array "write-mostly" and set the spin-down time (hdparm -S) to an hour or so. Now reads will go to one drive, the other will spin down, *and*, should you do one of those infrequent writes, the idle drive will spin back up and write the data (I want a bitmap of course). At the end of the time period you clear the write-mostly and spin-down time on the idle drive, put them on the other drive, and ideally you wind up with redundancy, splitting the disk wear evenly, and using existing capabilities. Actually you can't quite use existing capabilities, write-mostly can only be used at inconvenient times, like build, create, or add, so it's not obviously possible to change without at least shutting the array down. Perhaps Neil will give us his thoughts on that. However, if you don't mind a *really* ugly script, you might be able to mark the active drive failed, which would force all i/o to the previously sleeping drive, then remove the previously active drive, and add it back in using write-mostly. You would do a full sync (I think) but the change would be made. Better to make write-mostly a flag which can be enabled and disabled at will. That would be useful when a remote drive is normally operated over a fast link and has to drop to a slow backup link. I'm sure other uses would be found. -- Bill Davidsen <davidsen@xxxxxxx> "Woe unto the statesman who makes war without a reason that will still be valid when the war is over..." Otto von Bismark -- 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
