Hannes Reinecke [hare@xxxxxxx] wrote: > Well, maybe. Not so sure if device-mapper is the correct place to implement > something like this. > > What you get if you use a device-mapper device as the 'middle' tier in > this scenario is that this device will contain only random blocks, > ie those actually accessed/modified/whatever. > Only the underlying device will contain the full information about > all blocks, and as such only the underlying device can be mounted > and provides a meaningful filesystem. > Any middle tier devices will contain a somewhat random update of > several blocks, which cannot be interpreted at all. > > This makes error checking _really_ hard, as the middle tier devices > can't be consistency checked at all; we have to hope the blocks on > there make sense to the underlying device. Are you proposing a "dm-cache" target here? That may work as HSM (hierarchical Storage management) if dm-cache target can accept tier'ed devices. But it has to keep track of access times on the blocks to move them among tier'ed devices. Can be made to work, but I think it is efficient to do it in the file system as you indicated. > > No, this scenario could be more efficiently handled on the filesystem > level, as we then have an implicit consistency check as you're restricted > to move _files_ to a different storage; but that's okay as the filesystems > in on each device themselves will be consistent. > > Would be a grand application for union mount if and when it comes around. > And probably btrfs already has it built-in, I wouldn't wonder. I am not sure if "union mount" is really needed as the file system driver can implicitly take care of HSM with a single mount. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
