Hi,
This patch makes loop work like a block remapper. It was started
yesterday due to me trying to solve the (chronic) loop deadlocks
that have plauged 2.3/2.4 for ages. It has several advantages over
the old request handling:
* loop doesn't eat request slots. This alone saves run time memory
requirements (standard is 256 request slots per queue)
* don't have to fight block layer wrt merging, plugging, etc
* much faster, loop doesn't serialize I/O requests anymore. This also
allows the target device elevator to work a lot better.
People having loop problems, please give this a go. It may still have
a few 'issues', but I bet they are solvable now. If you are asking
'why' when seeing this patch, I urge you to
vi drivers/block/loop.c
/do_lo_request
and have a barf bag ready.
The builtin transfer functions (none and xor) work with the changes,
but external crypto additions may not. The reason is that the raw
buf and loop buf passed to them can now be identical (the previous
version always used getblk() to get a new buffer to work on).
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test11-pre5/loop-remap-2.bz2
--
* Jens Axboe <[email protected]>
* SuSE Labs
Jens Axboe wrote:
>
<snip>
>
> The builtin transfer functions (none and xor) work with the changes,
> but external crypto additions may not. The reason is that the raw
> buf and loop buf passed to them can now be identical (the previous
> version always used getblk() to get a new buffer to work on).
>
<snip>
The crypto-api from the international kernel patch has recently defined
that the encryption functions contained in it must be able to encrypt
in-place. This maps directly to the loop-gen driver, so I don't see a
problem here. (Other than that there is no real patch-int-2.4.x out
there yet). However, the ciphers have not been checked to conform to
that definition.
Marc
--
Marc Mutz <[email protected]> http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)