Is it possible to change the wait time before a drive is concidered failed?

Is it possible to change the wait time before a drive is concidered failed?

[wilsonjonathan]

I realise that what I am attempting is not very standard in terms of
raid, however this is my logic and reasoning...

I am setting up a home server that while on 24/7 will only be in use
when either myself (linux) or my son (windows) are using it, so usage
will vary and power concerns (Electricity in the UK is extortionately
priced!) and longevity are important.

My set up in theory is the following using GPT partitioning.

>sda 6 partitions
>>free space     1MiB
>>sda1 bios_boot 1MiB
>>sda2 /boot     200MiB  raid1  md2
>>sda3 /         8GiB    raid1  md3
>>sda4 *swap     9GiB    (will be "raided" using pri=1)
>>sda5 /download 40GiB   raid10 md4
>>sda6 /thecube  ~950Gib raid6  md5
>>free space     ~20MiB
>
>sdb same as sda
>
>sdc 1 partition
>>free space     enough space to place sdc6 the same start as sda6
>>sdc6 /thecube  same as sda6
>>free space
>
>sd[df] same as sdc

The reason for partitioning this way is that all w.i.p. or downloads,
torrents, etc. will first go into /download and once complete will be
moved into /thecube for long term read only storage

As /thecube is going to be used less often than sd[ab] it would be
advantages to have sd[df] power down and when the system is not in use
at all have sd[ab] also power down.

This should increase the lifespan of the drives... and yes I do know
that drives are more likely to fail when powering up, but I also have
real life evidence when I used to work on AS/400s that they fail on
power up if they have hardly ever been turned off more often than if
they have regular power off/on cycles :-)

I may even look at suspend to ram and magic packets if the system is not
accessed in say 1 hour, although this is less likely to be implemented!

Ok so that’s the reasoning behind the question.



I do have a couple of related questions...

I have already done some testing by setting up sd[ab] for md[2-4] but
with no file systems on top, and then pulling sdb and then putting it
back in.

q1, why does -add throw up the message : not performing --add, re-add
failed, zero superblock...

q2, I setup md4 as a raid10 far 2, and I may not be understanding raid10
here; when I zero the superblock to add it as I did with the other raids
which worked ok, for some reason it causes sda4 to drop out and kills
the whole md4 raid.

q3, Is it preferable to have a write intent bitmap, and if so should I
put it in the meta-data as opposed to a file.

Thanks in advance.

Jon.

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

Re: Is it possible to change the wait time before a drive is concidered failed?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 3972 bytes --]

On Sun, 20 Nov 2011 18:41:44 +0000 wilsonjonathan <piercing_male@hotmail.com>
wrote:

> I realise that what I am attempting is not very standard in terms of
> raid, however this is my logic and reasoning...
> 
> I am setting up a home server that while on 24/7 will only be in use
> when either myself (linux) or my son (windows) are using it, so usage
> will vary and power concerns (Electricity in the UK is extortionately
> priced!) and longevity are important.
> 
> My set up in theory is the following using GPT partitioning.
> 
> >sda 6 partitions
> >>free space     1MiB
> >>sda1 bios_boot 1MiB
> >>sda2 /boot     200MiB  raid1  md2
> >>sda3 /         8GiB    raid1  md3
> >>sda4 *swap     9GiB    (will be "raided" using pri=1)
> >>sda5 /download 40GiB   raid10 md4
> >>sda6 /thecube  ~950Gib raid6  md5
> >>free space     ~20MiB
> >
> >sdb same as sda
> >
> >sdc 1 partition
> >>free space     enough space to place sdc6 the same start as sda6
> >>sdc6 /thecube  same as sda6
> >>free space
> >
> >sd[df] same as sdc
> 
> The reason for partitioning this way is that all w.i.p. or downloads,
> torrents, etc. will first go into /download and once complete will be
> moved into /thecube for long term read only storage
> 
> As /thecube is going to be used less often than sd[ab] it would be
> advantages to have sd[df] power down and when the system is not in use
> at all have sd[ab] also power down.
> 
> This should increase the lifespan of the drives... and yes I do know
> that drives are more likely to fail when powering up, but I also have
> real life evidence when I used to work on AS/400s that they fail on
> power up if they have hardly ever been turned off more often than if
> they have regular power off/on cycles :-)
> 
> I may even look at suspend to ram and magic packets if the system is not
> accessed in say 1 hour, although this is less likely to be implemented!
> 
> Ok so that’s the reasoning behind the question.
> 
> 
> 
> I do have a couple of related questions...
> 
> I have already done some testing by setting up sd[ab] for md[2-4] but
> with no file systems on top, and then pulling sdb and then putting it
> back in.
> 
> q1, why does -add throw up the message : not performing --add, re-add
> failed, zero superblock...

Because some people seem to use "--add" when they mean "--re-add" and that
can cause data loss.  So to be safe, if want want to discard all the data on
a device and add it as a true spare, you now need to --zero-superblock
first.  Hopefully that isn't too much of a burden.

> 
> q2, I setup md4 as a raid10 far 2, and I may not be understanding raid10
> here; when I zero the superblock to add it as I did with the other raids
> which worked ok, for some reason it causes sda4 to drop out and kills
> the whole md4 raid.

You must be running linux-3.1.  It has a bug with exactly this behaviour.
It should be fixed in the latest -stable release.  Upstream commit 
   7fcc7c8acf0fba44d19a713207af7e58267c1179
fixes it.


> 
> q3, Is it preferable to have a write intent bitmap, and if so should I
> put it in the meta-data as opposed to a file.

A write intent bitmap can make writes a little slower but makes resync after
a crash much master.  You get to choose which you want.
It is much more convenient in the internal metadata.  Having the bitmap in an
external file and reduce the performance cost a bit (if the file is on a
separate device).
I would only recommend a separate file if you have an asymmetric mirror with
one leg (the slow leg) marked write-mostly.  You don't really want the bitmap
on that device, so put it somewhere else.

NeilBrown




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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Is it possible to change the wait time before a drive is concidered failed?

[wilsonjonathan]

Having looked more indepth I think the answer to my first question may
be resolved by increasing the wait time in the individual sd* devices as
if I read it correctly soft raid doesn't have or use a time out value
(unless it does both have and use the value under the md* device) but
instead just waits until an individual device times out. 

If thats the case then I may just increase the time out of the sd*'s to
60 seconds from 30 seconds which should be more than enough time to
allow a drive to wind up and start to give back data.


Thanks for the helpful replies... 

> > 
> > I do have a couple of related questions...
> > 
> > I have already done some testing by setting up sd[ab] for md[2-4] but
> > with no file systems on top, and then pulling sdb and then putting it
> > back in.
> > 
> > q1, why does -add throw up the message : not performing --add, re-add
> > failed, zero superblock...
> 
> Because some people seem to use "--add" when they mean "--re-add" and that
> can cause data loss.  So to be safe, if want want to discard all the data on
> a device and add it as a true spare, you now need to --zero-superblock
> first.  Hopefully that isn't too much of a burden.

Thats what I thought was strange, as no data had changed (no file
system) after getting the above message when I tried --re-add I expected
it to add it back in and re-sync, but again it told me I couldn't so I
had to zero the supper block.

> 
> > 
> > q2, I setup md4 as a raid10 far 2, and I may not be understanding raid10
> > here; when I zero the superblock to add it as I did with the other raids
> > which worked ok, for some reason it causes sda4 to drop out and kills
> > the whole md4 raid.
> 
> You must be running linux-3.1.  It has a bug with exactly this behaviour.
> It should be fixed in the latest -stable release.  Upstream commit 
>    7fcc7c8acf0fba44d19a713207af7e58267c1179
> fixes it.

Thanks for that... I'm currently running an older kernel now as I'm
installing debian squeeze to further test the raids with a running
system (as opposed to off a live cd) 

> 
> 
> > 
> > q3, Is it preferable to have a write intent bitmap, and if so should I
> > put it in the meta-data as opposed to a file.
> 
> A write intent bitmap can make writes a little slower but makes resync after
> a crash much master.  You get to choose which you want.
> It is much more convenient in the internal metadata.  Having the bitmap in an
> external file and reduce the performance cost a bit (if the file is on a
> separate device).
> I would only recommend a separate file if you have an asymmetric mirror with
> one leg (the slow leg) marked write-mostly.  You don't really want the bitmap
> on that device, so put it somewhere else.

I will use the intent as you describe as the speed hit isn't a problem
for my use-case.

> 
> NeilBrown
> 

Jon

Re: Is it possible to change the wait time before a drive is concidered failed?

[Thomas Fjellstrom]

On November 22, 2011, wilsonjonathan wrote:
> Having looked more indepth I think the answer to my first question may
> be resolved by increasing the wait time in the individual sd* devices as
> if I read it correctly soft raid doesn't have or use a time out value
> (unless it does both have and use the value under the md* device) but
> instead just waits until an individual device times out.
> 
> If thats the case then I may just increase the time out of the sd*'s to
> 60 seconds from 30 seconds which should be more than enough time to
> allow a drive to wind up and start to give back data.
> 
> 
> Thanks for the helpful replies...
> 
> > > I do have a couple of related questions...
> > > 
> > > I have already done some testing by setting up sd[ab] for md[2-4] but
> > > with no file systems on top, and then pulling sdb and then putting it
> > > back in.
> > > 
> > > q1, why does -add throw up the message : not performing --add, re-add
> > > failed, zero superblock...
> > 
> > Because some people seem to use "--add" when they mean "--re-add" and
> > that can cause data loss.  So to be safe, if want want to discard all
> > the data on a device and add it as a true spare, you now need to
> > --zero-superblock first.  Hopefully that isn't too much of a burden.
> 
> Thats what I thought was strange, as no data had changed (no file
> system) after getting the above message when I tried --re-add I expected
> it to add it back in and re-sync, but again it told me I couldn't so I
> had to zero the supper block.
> 
> > > q2, I setup md4 as a raid10 far 2, and I may not be understanding
> > > raid10 here; when I zero the superblock to add it as I did with the
> > > other raids which worked ok, for some reason it causes sda4 to drop
> > > out and kills the whole md4 raid.
> > 
> > You must be running linux-3.1.  It has a bug with exactly this behaviour.
> > It should be fixed in the latest -stable release.  Upstream commit
> > 
> >    7fcc7c8acf0fba44d19a713207af7e58267c1179
> > 
> > fixes it.
> 
> Thanks for that... I'm currently running an older kernel now as I'm
> installing debian squeeze to further test the raids with a running
> system (as opposed to off a live cd)
> 
> > > q3, Is it preferable to have a write intent bitmap, and if so should I
> > > put it in the meta-data as opposed to a file.
> > 
> > A write intent bitmap can make writes a little slower but makes resync
> > after a crash much master.  You get to choose which you want.
> > It is much more convenient in the internal metadata.  Having the bitmap
> > in an external file and reduce the performance cost a bit (if the file
> > is on a separate device).
> > I would only recommend a separate file if you have an asymmetric mirror
> > with one leg (the slow leg) marked write-mostly.  You don't really want
> > the bitmap on that device, so put it somewhere else.
> 
> I will use the intent as you describe as the speed hit isn't a problem
> for my use-case.

Good call :) I started using the write-intent bitmap, and I can say I'll 
likely never go back to not using one. When there is a problem, you will 
appreciate the decision. Instead of it taking days or weeks to rebuild/resync, 
it takes a few minutes. And rebuilding is usually the point when a failure is 
going to happen, which is the absolute worst time, as losing a disk when 
degraded is pretty bad on many setups (raid0, raid1, raid5, some raid10's I 
think...).

And I really don't notice the speed hit. I still get a few hundred MB/s at the 
very least off my 7 disk raid5.

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


-- 
Thomas Fjellstrom
thomas@fjellstrom.ca