[lkml]   [1996]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectSome thoughts on the loop device
Some thoughts on the loop device : 

(BTW I'm a newbie to this list and to kernel stuff in general. So a
lot of this stuff could already have been discussed to death, or
unnecessary, or wrong, or just plain stupid :)

The loop device uses 2 buffers on the buffer cache for each disk
block. The first buffer (allocated by filesystem code calling bread)
will contain unencrypted data, and the second, allocated by
do_lo_request, contains encrypted data read from the disk. The chances
of this second buffer being used by someone again are pretty low, and
double-buffering takes place. In case of unencrypted filesystems, both
buffers will contain the same data.

Using getblk and ll_rw_block in do_lo_request looks much cleaner, but
IMHO it would be better to have a permanently kmalloced BLOCK_SIZE
bytes which are used for reading/writing to disk. What is needed is a
function like ll_rw_block, but which takes a char * argument rather
than struct buffer_head * (something like ll_rw_swap_file). This
function can be used in do_lo_request to read/write a block from disk
to the kmalloced scratch buffer. Thus there's only 1 (unencrypted) buffer
on the cache corresponding to 1 physical disk block.

Here is an alternative idea for implementation of loop :

1. Trap requests to the loop device in ll_rw_block and call a loop_map
function (like the md code).
2. If it is _not_ a crypted fs, loop_map will call bmap, get the blockno on
actual device and change the real device (bh[i]->b_rdev) to point to the
actual device. So the do_request is called on the actual device. (again,
like md does it)
3. If it _is_ a crypted fs, loop_map calls bmap, etc. etc. BUT leaves the real
device part as MAJOR_LOOP. So do_lo_request is called which reads
the block using ll_rw_blk (actual device, etc.) or whatever, and does the
crypto stuff.
4. This ought to optimise access to uncrypted filesystems. Unfortunately,
because of the hack in ll_rw_block, it can no longer be an
independent module.

Also, we should be able to add code to boot off a looped filesystem.
Like this :
You have loadlin, zImage and a large file containing an ext2 root fs in your
DOS machine. You want to try out linux and don't want to mess with partitions.
Linux boots with /dev/hda1 (MSDOS) as the root fs, finds the file
C:\LINUX\ROOT loops it to /dev/loop1, then unmounts the root (DOS), mounts
/dev/loop1 as the root and maybe mounts /dev/hda1 on /bootfs. Would be a
neat trick :) (initrd does something like this). This could be an alternative
to UMSDOS as a way of demonstrating Linux on DOS, and with a *real* filesystem.
Also you might want to add a 'contiguous' option if your root file on dos is
defragmented and on contiguous disk blocks to simplify loop_map, giving
almost the same performance as if it were on a separate partition.

Comments invited ...

-- Ganesh
Any sufficiently advanced bug is indistinguishable from a feature.

 \ /
  Last update: 2005-03-22 13:38    [W:0.043 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site