Slightly delayed, but here is loop-5. It's against 2.4.2-pre4, as
testing on 2.4.1-ac19 showed other problems (oom killer would kill
dbench or bash before it could finish...). I'll take a look at ac19
next. Changes since loop-4:
o Make sure loop_thread is up. A mount -o loop could sometimes sneak
in a request before the helper thread was started. (me)
o Remove all the backing file setup, count on get_file just
holding a reference to it. (Neil Brown)
o Remove fs/buffer.c:wakeup_bdflush work around. loop doesn't block
on requests, so it shouldn't be needed.
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.2-pre4/loop-5
--
Jens Axboe
Jens,
Please excuse this possibly stupid q. I don't know as much about kernel
hacking as I would like to.
I noticed that you are rewriting the loop block device to be a block
remapper (yes, I had noticed this before, the q just never occurred to
me before); does this imply that the native block size of the loop file
fs must be the same size as the underlying fs? exemplia gratia, ext2 fs
w/ block size 1024, iso image block size 2048; or ext2 block size 1024,
reiserfs image block size 512 (I'm assuming this is possible, but don't
know for sure. of course on reiserfs the likely best size is 4096 to
match page size, since tails are packed anyway); or perhaps a more
useful/common example than the previous: iso block size 2048, ext2 block
size 1024 (most common block size, right??).
I admit that I gave one, maybe two more examples than necessary. the
idea of the first two was to cover both possibilities, i.e. loop larger
than base, and loop smaller than base. The third was merely to ward off
the possiblity that the 3rd was and impossible configuration, and to
reduce flames from various people who consider something this
"elementary" to be "obvious", either in utility or specification.
On Tue, Feb 20 2001, Adam Schrotenboer wrote:
> Jens,
>
> Please excuse this possibly stupid q. I don't know as much about kernel
> hacking as I would like to.
>
> I noticed that you are rewriting the loop block device to be a block
> remapper (yes, I had noticed this before, the q just never occurred to
> me before); does this imply that the native block size of the loop file
> fs must be the same size as the underlying fs? exemplia gratia, ext2 fs
> w/ block size 1024, iso image block size 2048; or ext2 block size 1024,
> reiserfs image block size 512 (I'm assuming this is possible, but don't
> know for sure. of course on reiserfs the likely best size is 4096 to
> match page size, since tails are packed anyway); or perhaps a more
> useful/common example than the previous: iso block size 2048, ext2 block
> size 1024 (most common block size, right??).
A remapper was the original idea, and the loop-remap-XX patches did
that. But it gave me so many head aches exactly due to for example
block size differences, and also the stacking then becomes even
more problematic.
So no, the current loop patches do not use simple buffer_head
remapping.
--
Jens Axboe