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.
This bug is fixed in loop-AES-v3.6b (it got fixed as part of queue code
removal/rewrite). If you can reproduce this error with loop-AES-v3.6b, then
I definitely want to know about it.
Seeing small amount of EOPNOTSUPP errors (loop_end_io_transfer err=-95 ...)
in syslog is normal. This can happen when a file system is probing and/or
learning that backing device under loop device driver does not support
barriers.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
[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
* Thomas Siedlich <[email protected]> wrote:
> [solved]
Thanks, added to the FAQ.
--
left blank, right bald
loop-AES FAQ: http://mareichelt.de/pub/texts.loop-aes.php#faq