On Sun, Feb 13, 2000 at 12:44:13AM +0100, Alexander Viro wrote:
> Putting this breakage back is not a problem, indeed. But as for gratitious...
> See above for reasons. BTW, for loopback over devices encoding remains the
> same as it used to be. I'm not saying that it's ideal variant (see the comment
> in patch), but at least the thing fixes very real breakage for files with holes
> and for _any_ write access to /dev/loop. Changing it so that it would use
> ->bmap() result for IV is, indeed, possible, but I'ld rather see that done in
> encryption modules. Notice that they are getting enough information to call
> ->bmap() and get the on-disk block number. And IMO it's the right place for
> such thing - generic code should _not_ try to do it, since it will be outright
> impossible for NFS _and_ since the reverse transformation is impossible.
The right thing IMHO is to add a new vector to loop_func_table, still pass
the old absolute block number to the old vector, and use the new with
the relative index when available.
>
> The bottom line: encryption driver can trivially compensate for the change.
> So if it's a problem with on-disk format - fine, let's keep the transformation
> in the format-handling code.
Unfortunately they can not. One design problem of loopback crypto is
that you cannot store any additional information. The only way to
check if the user entered the right password is to see if ext2 can mount
the file system. There is really no way to detect old and new format.
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:23 EST