From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brown Subject: Re: md road-map: 2011 Date: Thu, 17 Feb 2011 01:30:49 +0100 Message-ID: References: <20110216212751.51a294aa@notabene.brown> <20110217083531.3090a348@notabene.brown> <20110217100139.7520893d@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110217100139.7520893d@notabene.brown> Sender: linux-raid-owner@vger.kernel.org To: linux-raid@vger.kernel.org List-Id: linux-raid.ids On 17/02/11 00:01, NeilBrown wrote: > On Wed, 16 Feb 2011 23:34:43 +0100 David Brown > 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?