Messages in this thread |  | | Date | Mon, 4 Nov 1996 15:34:36 +0530 (IST) | From | ganesh@cse ... | Subject | Some 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 (ganesh@cse.iitb.ernet.in) ---------------------------------------------------------------------------- Any sufficiently advanced bug is indistinguishable from a feature. ----------------------------------------------------------------------------
|  |