Skip to contentSkip to conversation

Possibility for a parallel relaxed RAID?

DISCUSSION Berkey B Walker 3 participants 4 messages Mar 18, 2010 – Mar 19, 2010 MD RAID

lore
Share & tools
lore
#0 lore raw

There maybe many folks out there who want to use RAID on their personal, non-production systems. Assuming access and thru-put values are not critical a problem might be "You can't use Desktop drives for RAID". Which, I think, most of us know is not really true, but - - If the timing issues were to be relaxed, allowing the drive to fix itself, before being kicked by the md process, might not the average Joe be better served? There is a big difference between going a mile and buying a commodity drive, and being "up" in an hour vs. finding a working system, going online, paying price+, and getting/paying fast shipping. Which might resolve the issue in days instead of hours.

Any possibility of a parallel, less critical to drive response, release of md? Or a patch to allow same?

Thanks
Berk Walker berkatpanixperiodcom

#1 lore raw
Quoted 11 lines · On Thu, 18 Mar 2010 15:01:44 -0400 Berkey B Walker <[email protected]> wrote:

There maybe many folks out there who want to use RAID on their personal, non-production systems. Assuming access and thru-put values are not critical a problem might be "You can't use Desktop drives for RAID". Which, I think, most of us know is not really true, but - - If the timing issues were to be relaxed, allowing the drive to fix itself, before being kicked by the md process, might not the average Joe be better served? There is a big difference between going a mile and buying a commodity drive, and being "up" in an hour vs. finding a working system, going online, paying price+, and getting/paying fast shipping. Which might resolve the issue in days instead of hours.

Quoted 2 lines

Any possibility of a parallel, less critical to drive response, release of md? Or a patch to allow same?

This is not a function of 'md'. md has no timeouts for drives responding. It just submits a request and waits for a success/fail reply.

It may be a function of the lower level SATA/SCSI/FC/whatever driver. You would do better to ask the developers of those drivers, maybe start with the maintainer of libata.

NeilBrown

#2 lore raw

Neil,

How does md make the decision to drop a drive from the array? Is it a fail message back from the ATA layer? Quickly getting over my head here, but I would like to think there are different types of failures and a failure to complete error correction on the drive should not be a fatal error to md.

This request is the same as the post I have made earlier this week regarding "RAID class" drives which I would love to get your response to.

Tks

Quoted 24 lines · Neil Brown
Quoted 11 lines · On Thu, 18 Mar 2010 15:01:44 -0400 Berkey B Walker <[email protected]> wrote:

There maybe many folks out there who want to use RAID on their personal, non-production systems.  Assuming access and thru-put values are not critical a problem might be "You can't use Desktop drives for RAID". Which, I think, most of us know is not really true, but - - If the timing issues were to be relaxed, allowing the drive to fix itself, before being kicked by the md process, might not the average Joe be better served?  There is a big difference between going a mile and buying a commodity drive, and being "up" in an hour vs. finding a working system, going online, paying price+, and getting/paying fast shipping. Which might resolve the issue in days instead of hours.

Quoted 2 lines

Any possibility of a parallel, less critical to drive response, release of md?  Or a patch to allow same?

This is not a function of 'md'.  md has no timeouts for drives responding. It just submits a request and waits for a success/fail reply.

It may be a function of the lower level SATA/SCSI/FC/whatever driver.  You would do better to ask the developers of those drivers, maybe start with the maintainer of libata.

Quoted 6 lines

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

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

#3 lore raw
Quoted 7 lines · On Thu, 18 Mar 2010 17:00:04 -0600 Randy Terbush <[email protected]> wrote:

Neil,

How does md make the decision to drop a drive from the array? Is it a fail message back from the ATA layer? Quickly getting over my head here, but I would like to think there are different types of failures and a failure to complete error correction on the drive should not be a fatal error to md.

md gets an error from the block layer, which gets it from the ata layer. There is a facility to transfer back a status describing the type of error however
- I don't believe it is used consistently, nor is there a list of usable errors
- md currently makes a minimal assumption about an error, so the only use in md for this would be to be less gentle, not more gentle.

If a drive has "a failure to complete error correction", then I suspect they presents as a read error. md will try to get the data from elsewhere and re-write it. If that fails it becomes a write error, and a device that cannot be written to is useless, so md fails it.

There are plans to add support for a bad-block-list to md so that when we get a write failure or a read failure on a degraded array we can mark just that block as faulty. However these plans are currently languishing due to lack of time.

Quoted 4 lines

This request is the same as the post I have made earlier this week regarding "RAID class" drives which I would love to get your response to.

I think the only part of the which is relevant to me is:

Quoted 4 lines

However, I do not understand why the RAID system
cannot detect the type of drive it is dealing with and either disable the behavior on the drive or allow more time for the drive to respond before kicking it out of the array.

It doesn't disable anything because no-one has written code to do so. I know virtually nothing about ata controller and protocols and such so I am not really the person to do it.
This would either be something that mdadm did when it added a drive to an array, or something that the kernel did when md asked it some how. I suggest you talk to someone who knows about sata - or submit a patch yourself.

The "allow more time for the drive to respond" is not an issue for md. It
has no timeouts. It might be an issue for the sata controller.

NeilBrown

Quoted 34 lines

Tks

Quoted 30 lines · Neil Brown
Quoted 11 lines · On Thu, 18 Mar 2010 15:01:44 -0400 Berkey B Walker <[email protected]> wrote:

There maybe many folks out there who want to use RAID on their personal, non-production systems.  Assuming access and thru-put values are not critical a problem might be "You can't use Desktop drives for RAID". Which, I think, most of us know is not really true, but - - If the timing issues were to be relaxed, allowing the drive to fix itself, before being kicked by the md process, might not the average Joe be better served?  There is a big difference between going a mile and buying a commodity drive, and being "up" in an hour vs. finding a working system, going online, paying price+, and getting/paying fast shipping. Which might resolve the issue in days instead of hours.

Quoted 2 lines

Any possibility of a parallel, less critical to drive response, release of md?  Or a patch to allow same?

This is not a function of 'md'.  md has no timeouts for drives responding. It just submits a request and waits for a success/fail reply.

It may be a function of the lower level SATA/SCSI/FC/whatever driver.  You would do better to ask the developers of those drivers, maybe start with the maintainer of libata.

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

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