Re: loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[solved]

Hi Jari!

Jari Ruusu wrote:

Thomas Siedlich wrote:

quoted

For my kernel it should mean (if I interpret
/usr/src/linux/include/linux/bio.h right):
"Tell the IO scheduler not to wait for more requests
after this one has been submitted, even if it is a SYNC request."
"synchronous I/O hint."
"barrier"
"write"

"barrier" bit is the one that triggered EOPNOTSUPP error
from backing device.

quoted

Here:
"barrier"
and
"read"

Same here.

quoted

So "barrier" is the same in both messages. But why does it work
without loop? The backing device should be the same, shouldn't it?

Because loop-AES-v3.3a has a bug in barrier request handling that
triggers when a barrier request is sent to backing device that can't
handle barrier request. This is what happens:

1) Block layer kernel code above loop driver issues empty
   barrier request to loop driver.
2) Loop driver does not pass that empty barrier request to
   backing device.
   Instead it sets a flag to indicate "mark next request as barrier".
3) Next request arrives at loop driver, loop driver marks that one
   as barrier request, and eventually sends it to backing device.
4) Backing device driver decides that it doesn't do
   barriers at all, and aborts processing that request.

In short: due to loop driver bug, backing device driver
aborted wrong request with EOPNOTSUPP error code.

Thanks for the explanation.

This bug is fixed in loop-AES-v3.6b (it got fixed as part
of queue code removal/rewrite). 

Yes it is fixed.

If you can reproduce this error with loop-AES-v3.6b, then I
definitely want to know about it.

No I can't :-). I'm running now 2.6.38.2 (kernel.org) with
loop-AES-v3.6b and it works. I can mke2fs on the loop device
without errors. The filesystem ist mountable and I can e2fsck
the filesystem without syslog errors.

Thanks a lot Jari and sorry for the noise.

Thomas