On Thu, Nov 30, 2017 at 12:22:53PM -0800, Liu Bo wrote: > > > I agree with Ed and Peter, similar opinion was posted here [1]. > > > https://www.spinics.net/lists/linux-btrfs/msg70240.html > > > > All the points in this thread speak against retries on the filesystem > > level and I agree. Without an interface to query the block layer if the > > retries make sense, it's just guessing, likely to be wrong. > > I do agree that filesystem doesn't need to retry at its own level, but > btrfs incorporates disk management which is actually a version of md > layer, adding retry for this layer can gain robustness for us. > > It's true that scsi's sd layer has done SD_MAX_RETRIES(5) retries, but > can we really depend on other layers for all robustness?
I'm afraid that we have to. We don't really want to dive too much to the storage layer that's beneath the filesystem. If there was an interface like "blk_queue_retries_make_sense", then letting the upper layer could improve robustness, but otherwise I see it as false hopes an just wasting time retrying. > In terms of raid56 scenario, typically filesystem doens't fail the > raid/disk, but btrfs does, doing retry _may_ save us a lot of time of > rebuilding raid. > > Anyway, this is for a corner case, not for everyone, I think I need to > make it configurable so that at least we can provide some extra > robustness for people who super care about their data. This should be IMHO solved by redundancy. If the storage layer is not reliable it's not wise to continue using the underlying devices and rely on the retries. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
