David Gümbel wrote: > I applied the patch and tested it. The error remains there - both the > "ls /tmp" (encrypted reiserfs) error and the "ls > ~/Mail/Spamverdacht/new/" (encrypted ext3) error. > > These are dmesg lines starting with "loop" after trying the /tmp error: > > guembel@marsupilami v4 $ cat dmesg_tmp_input_output_error.txt | grep ^loop > loop: loaded (max 8 devices) > loop1: loop_end_io_transfer err=-11 bi_rw=0x2 > loop1: loop_end_io_transfer err=-11 bi_rw=0x2 > loop1: loop_end_io_transfer err=-11 bi_rw=0x2 Got it! Above means that underlying device I/O elevator (hda), failed read-ahead requests (bi_rw=0x2) with -EWOULDBLOCK error code (err=-11, uses same error code as -EAGAIN). I/O elevator treats read-ahead requests little bit more relaxed than normal read or write requests. It has liberty to fail them in case of congestion or free memory pressure. Loop driver reported underlying device error to file system on top of loop device. File system should have ignored failed read-ahead requests, but it didn't, so you saw I/O errors as result. Same situation can happen on unencrypted file systems that do not go through loop device. It is a kernel bug. Can you test attached patch? It transforms read-ahead requests from file system to normal reads for underlying device. Normal read requests should not fail with -EWOULDBLOCK so this should cure the problem. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
Attachment:
v2.1c-5.diff.bz2
Description: Binary data
