Re: Patch to loop device (loop.c)
Fri, 4 Dec 1998 11:41:14 -0600

On Fri, Dec 04, 1998 at 03:47:39AM +0000, wrote:
> >
> > In the case of writes, loop.c always receives a complete block by definition.
> By which definition ? There is code in the loop device to handle
> partial writes, and the requests are done in sector counts, not
> in block counts. The loop device itself accesses the real (backing) device
> only with complete block reads/writes. But what guarantees that
> the request TO the loop device is aligned to block boundaries.

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


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at