Re: Patch to loop device (loop.c)
Fri, 4 Dec 1998 03:47:39 +0000

On Thu, Dec 03, 1998 at 11:00:48AM -0600, wrote:
> Please check my understanding and correct me where I am in error:
> <logic check>
> Loop I/O requires two ll_rw_blk requests:
> one invokes the device driver supporting the real (backing) device and
> the other invokes loop.c.

I thought it is like this:
1. ll_rw_blk is asked to transfer blocks from/to loop device.
2. do_lo_request is called
3. do_lo_request calls ll_rw_blk again to access the real (backing)
4. do_lo_request returns data if it was a read.

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

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

> </logic check>

> > (I'm not sure if this is also true for blocks. If it is true
> > then it would be possible to make the code simpler because all
> > the partial sector reading stuff could be deleted.)

As I said, I'm not sure :-). If you are correct the code can be
simplified a lot, because it handles partial block accesses.
(There is code which says something like

offset=(sector % (blocksize >> 9) ) << 9;

which is definitely for mid block accesses.

If accesses only start and end on block boundaries all this
code is useless... (And we should of course use the block and not
the sector number)

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

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