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 -- 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
