https://bugzilla.suse.com/show_bug.cgi?id=1225852 https://bugzilla.suse.com/show_bug.cgi?id=1225852#c1 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #1 from Stanislav Brabec <sbrabec@suse.com> --- With a correct "losetup -d" in the script, error rate increased to 55 of 20000 attempts. (losetup -d is faster, as it attempts to detach only a single loop device I stepped forward, and added "losetup -a -l" in case of failure. In the most cases, the device did not exist any more, but in 2/50000 attempts it did. And what surprise: NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 1 0 /root/file.img 0 512 This indicates a problem. It should not be 512. Digging deeper, calling "losetup -a -l" multiple times, I realized that even if the loop device is created by a single ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=4096, info={lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_DIRECT_IO, lo_file_name="/root/file1.img", ...}}) internally in the kernel it is created as a basic device, and a latter it sets DIO and logical sector size: NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 1 0 /root/file.img 0 512 NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 0 0 /root/file.img 1 4096 This indicates a bug in the kernel: kernel sometimes fails to sed DIO and logical block size, but but the ioctl returns 0. And for some reason, that buggy device exists even after "udevadm settle". -- You are receiving this mail because: You are on the CC list for the bug.