On Thu, Feb 16, 2012 at 3:17 PM, Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx> wrote: > Hi joseph, > >> Your reasoning is quite sound assuming the cache device is present at >> activation time. >> >> In the case where the cache device has failed but the backing device >> has persisted the failure then the case looks somewhat more like this: >> 1) OS probes all devices, searches for caches and finds none. >> 2) Activate the raw backing device with possibly corrupt data.... > > as I mentioned, this is a bit borderline. > > One reason is that it would be a failure in > any case, depending on what the system will > do with the backing device. Perhaps, but there are two types of failures that are absolutely critical to distinguish between: Recoverable, and unrecoverable. If there is a superblock, any error in which the cache device is not available at activation is recoverable so long as the cache device can be made available at some other time. If there is a superblock, whether such a situation is recoverable is now undefined, and dependent on the implementation of the filesystem. This is a recipe for a horrible disaster. > Second, as per md, the configuration could > be in a file in initramfs, which will allow > to support this type of failure *and* have > the backing device unformatted. Actually, in modern initramfs' (see dracut) the way md devices are set up is via dynamic scanning, NOT via a static configuration file. This is possible *because* md devices have a superblock on the backing devices. This is *desirable* because a generic initramfs reduces the burden on the user (to know what they are doing) and on the distribution (to support users who roll their own initramfs) And dracut's entire logic is based on acting on devices as they are detected, so delaying all uevents until everything has been found would catastrophically break it. Especially because it acting on those events can create more devices which also need probed. What if your cache is on LVM but your backing devices are whole disks? Waiting until all devices have been probed before poking userspace means that you will never find the cache at all. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
