Re: Formatting of backing device

Hi Kent,

nice to have you in this discussion!

quoted

I understand that the actual implementation is easier and,
maybe, simpler, since a completely new device is added,
which will have the new caching "features", while the
old one (backing device) is just a further layer.
This is similar to LVM over md over /dev/sdX.

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".

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?

As I wrote above, I see this more complex than
adding a further layer, likely I would do the same.

wouldn't be terribly useful to us so it's not at all a priority for me.
If someone else wrote the code I'd take patches, though.

No time for that, unfortunately.

I take the opportunity to congratulate personally
to you for this project, well done!

bye,

-- 

piergiorgio

Piergiorgio Sartor <piergiorgio.sartor@...> writes:

quoted

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*

quoted

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.