Re: md road-map: 2011

["Keld Jørn Simonsen" <keld@keldix.com>]

On Thu, Feb 17, 2011 at 11:45:35AM +0100, David Brown wrote:
> On 17/02/2011 02:04, Keld Jørn Simonsen wrote:
> >On Thu, Feb 17, 2011 at 01:30:49AM +0100, David Brown wrote:
> >>On 17/02/11 00:01, NeilBrown wrote:
> >>>On Wed, 16 Feb 2011 23:34:43 +0100 David Brown<david.brown@hesbynett.no>
> >>>wrote:
> >>>
> >>>>I thought there was some mechanism for block devices to report bad
> >>>>blocks back to the file system, and that file systems tracked bad block
> >>>>lists.  Modern drives automatically relocate bad blocks (at least, they
> >>>>do if they can), but there was a time when they did not and it was up to
> >>>>the file system to track these.  Whether that still applies to modern
> >>>>file systems, I do not know - they only file system I have studied in
> >>>>low-level detail is FAT16.
> >>>
> >>>When the block device reports an error the filesystem can certainly 
> >>>record
> >>>that information in a bad-block list, and possibly does.
> >>>
> >>>However I thought you were suggesting a situation where the block device
> >>>could succeed with the request, but knew that area of the device was of 
> >>>low
> >>>quality.
> >>
> >>I guess that is what I was trying to suggest, though not very clearly.
> >>
> >>>e.g. IO to a block on a stripe which had one 'bad block'.  The IO should
> >>>succeed, but the data isn't as safe as elsewhere.  It would be nice if we
> >>>could tell the filesystem that fact, and if it could make use of it. But 
> >>>we
> >>>currently cannot.   We can say "success" or "failure", but we cannot say
> >>>"success, but you might not be so lucky next time".
> >>>
> >>
> >>Do filesystems re-try reads when there is a failure?  Could you return
> >>fail on one read, then success on a re-read, which could be interpreted
> >>as "dying, but not yet dead" by the file system?
> >
> >This should not be a file system feature. The file system is built upon
> >the raid, and in mirrorred raid types like raid1 and raid10, and also
> >other raid types, you cannot be sure which specific drive and sector the
> >data was read from - it could be one out of many (typically two) places.
> >So the bad blocks of a raid is a feature of the raid and its individual
> >drives, not the file system. If it was a property of the file system,
> >then the fs should be aware of the underlying raid topology, and know if
> >this was a parity block or data block of raid5 or raid6, or which
> >mirror instance of a raid1/10 type which  was involved.
> >
> 
> Thanks for the explanation.
> 
> I guess my worry is that if md layer has tracked a bad block on a disk, 
> then that stripe will be in a degraded mode.  It's great that it will 
> still work, and it's great that the bad block list means that it is 
> /only/ that stripe that is degraded - not the whole raid.

I am proposing that the stripe not be degraded, using a recovery area for bad
blocks on the disk, that goes together with the metadata area.

> But I'm hoping there can be some sort of relocation somewhere 
> (ultimately it doesn't matter if it is handled by the file system, or by 
> md for the whole stripe, or by md for just that disk block, or by the 
> disk itself), so that you can get raid protection again for that stripe.

I think we agree in hoping:-)

best regards
keld
--
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