Ah! (the lightbulb illuminates over my head). Now I understand why you
are concerned with unaligned requests.
My thinking was that the purpose of the loop device is to support
***filesystems*** having special data transformation needs. As observed in
my own testing, filesystems mounted over a loop device request only aligned
sectors/block... hence the selection of block as the unit of CBC crypting.
It makes no conceptual difference whether block level CBC IV's are seeded
with block numbers or sector numbers. Assuming the world concurs, I will
revise my loop transfer API changes introduced in 2.1.130 to pass sector
rather than block.
Btw, carrying this thinking to the next logical level, developing transfer
module logic that CBC crypts individual sectors only to have them aggregated
into fixed filesystem blocks seems like a wasted effort. I wish we could
assume aligned sectors/block requestors in all cases.
>
> >
> > In the case of reads, should the real (backing) request (which plays prior
> > to the loop.c request) fail to return all of the required sectors then
> > end_that_request_first() invokes printk() advising that an error has
> > occurred. Thus loop.c is assured never to see incomplete blocks. Correct?
>
> Yes, the backing device (be it file or block device) is able (and does)
> return complete blocks, but how do you know that the request to
> the loop device asks for complete blocks...
>
<snip>
>
> It is of course possible to handle requests to the loop device, which
> start in the middle of a block gracefully, but it makes things even
> more complicated than they are at the moment. (Because to write
> to the middle of a block you would first need to decrypt the whole block,
> then update the second part of the block, then crypt it again and put
> it back to disk (or the buffer cache)).
Ack!
>
> so long
> Ingo
>
Thank you Ingo for mentoring with me. This type of exchange makes Linux
wonderful environment.
Best Regards,
Reed "Think Unaligned Sectors" Petty <rhp@draper.net>
-
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/