linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ty! Boyack" <ty@nrel.colostate.edu>
To: linux-raid@vger.kernel.org
Subject: Is it possilble to be "delay tolerant" or have "slow dropout" of unavailable components?
Date: Tue, 08 Apr 2008 10:56:27 -0600	[thread overview]
Message-ID: <47FBA3BB.2030007@nrel.colostate.edu> (raw)

I'm curious if there is a way to have a raid set (raid5 in my case, but 
this could apply to any raid level) that could tolerate a component 
device being unavailable for a period of time.

My reason for this is that I am building raid5 sets of iscsi disks, 
attempting to provide some redundancy in case one of our iscsi 
arrays/controllers goes down.  We have had our iscsi arrays reboot a 
couple of times, and the result is that the raid5 set will see the iscsi 
array go down and take it out of the raid5 set.  In a couple of minutes, 
the iscsi disk returns, but it it too late.  I would love to have the 
raid5 set buffer the writes for about 5 minutes while the iscsi device 
reboots, and then pump all the writes to it.  This does not have to be 
time-based.  If we could buffer the writes up to the point where we 
filled the overflow buffer that would solve the problem too, so long as 
we could make a really big buffer.

I realize that this could incur significant memory costs, but that is 
far cheaper for us than us having the raid5 array come apart. 

The other modification for this would be that read operations would need 
to either pull from the buffer or reconstruct the data from the parity, 
but would need to NOT initiate a device failure.

Have I missed something that already takes care of this?

Is there already a feature that takes care of this on a much smaller 
scale (microseconds?) that might be able to be increased to several 
minutes? 

Does anyone else think this would be a good idea?

-Ty!






-- 
-===========================-
  Ty! Boyack
  NREL Unix Network Manager
  ty@nrel.colostate.edu
  (970) 491-1186
-===========================-


             reply	other threads:[~2008-04-08 16:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-08 16:56 Ty! Boyack [this message]
2008-04-08 17:48 ` Is it possilble to be "delay tolerant" or have "slow dropout" of unavailable components? Markus Hochholdinger
2008-04-08 18:24   ` Ty! Boyack
2008-04-08 18:54     ` Peter Rabbitson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47FBA3BB.2030007@nrel.colostate.edu \
    --to=ty@nrel.colostate.edu \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).