Piergiorgio Sartor <piergiorgio.sartor@...> writes: > > The reason for getting rid of transparent caching didn't have anything > > to do with ease of implementation: the real reason is that safely doing > > persistent caching (and writeback!) is impossible with transparent > > caching. > > Well, it seems to me "impossible" is a big word... > I could image is more "invasive". Not invasive, *horribly unsafe* > > Adding back a mode that caches a device without a bcache superblock but > > without the cache being persistent isn't out of the question, but it > > I miss the point, the superblock can be stored in > the caching device, instead of the backing and > the actual device *could* stay the same. > The kernel would have to discover first the caching, > later the backing and then put things together. > So, the cache will be persistent, or? Oh sure, the cache is persistent. But device discovery order is undefined, and if the backing device is no different from one without a cache and writeback caching is enabled the kernel has no *possible* way to know that a caching device is needed or even exists. So it mounts it, but it doesn't have any of the data in the writeback cache meaning it thinks the filesystem is corrupted. Depending on the filesystem and exactly what is missing, it may run some in-kernel recovery code that alters the disk. You just lost your data. -- 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
