>>>>> "John" == John Robinson <john.robinson@xxxxxxxxxxxxxxxx> writes: John> I've thought about this again, and I'm wrong; there may be John> complications in handling the cookies up and down the stack where John> more than one layer thinks it knows how to have another go, but I John> can see what you describe as being useful and relatively John> device-agnostic. Yeah, care will need to be taken if you have multiple layers in the stack providing redundancy. That's usually not the case, though. John> I wonder if there might also be scope for cookies going down John> through the stack to carry an indication of how hard to try; some John> filesystems or other consumers of block devices may be willing to John> ask again or want to be told about problems quickly (e.g. btrfs John> over RAID over TLER-equipped discs), while some may need best John> efforts all out first time because they can't cope will failure John> returns (e.g. FAT over cheap IDE discs). We already have this functionality. It's orthogonal to the integrity bits. You can tell the low-level drivers either fail a request immediately or to retry. That's only a software thing, though. It doesn't work terribly well with consumer harddrives that assume there's only one copy of the data and consequently enter annoying-click-mode and retry for a long time. Nearline and enterprise drives assume there's a redundant copy and will not try as hard under the assumption that you know how to remedy the problem. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
