[solved]
Hi Jari!
Jari Ruusu wrote:
> Thomas Siedlich wrote:
> > 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.
>
> > Here:
> > "barrier"
> > and
> > "read"
>
> Same here.
>
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
