Re: Proposal: non-striping RAID4

[Bill Davidsen <davidsen@tmr.com>]

Chris Green wrote:
> 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.
> 
Agree, you can't get that with current kernel, although I think the 
parts are there to actually make it work. All it would take is some 
clever calling of raid-4 operations to get it going. It's not trivial, 
but if you knew the code it might fall out by laying the raid-4 out and 
just changing the mapping such that all of the sequential sectors fall 
on the same device. Interesting summer project for someone.

> -----Original Message-----
> From: Bill Davidsen [mailto:davidsen@tmr.com] 
> Sent: Saturday, May 24, 2008 7:22 AM
> To: Chris Green
> Cc: Tony Germano; linux-raid@vger.kernel.org
> 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@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot