Bug 730266

I know about this problem.

The losetup(8) uses the /proc/partitions file to get list of the devices, unfortunately this file contains only devices bigger than 1KiB... yeah, kernel sucks.

The solution is to scan /sys/block/loopN.

I suspect that:
  bd_set_size(bdev, size << 9);
in:
  drivers/block/loop.c
should round up to the next sector.

I guess a 600 bytes big loop device is only 512 bytes in size too?

The kernel needs to round down to the next full 512 bytes block. If the
entire file is smaller than 512, the size of the volume will be 0, which
is expected behavior. If the kernel wouldn't do that, it would need to
pad stuff with \0 on read and write on the last unaligned block.

Talked to Tejun, we think that losetup should always truncate the size
at 512 bytes boundaries. And possibly even warn if the filesize is not
aligned to sector boundaries, as the trailing bytes that are smaller than
a sector will be ignored by the kernel. Even when the loop device is zeroed
out, the file might still contain garbage at the end after that.

Loop has blockdevice semantics, so there is nothing really the kernel can
do with the last bytes of the files that don't fit into a 512 bytes sector.
So losetup should probably inform the user that the remainder of the file
is ignored by the kernel, and that this might not be what it was asked for.

Having a file < 512 bytes makes no sense for a blockdevice mapping. The loop
device can not be read or write, we can only handle full blocks. That the
kernel allows that is questionable, but we think that losetup should
already check these values at device setup.

If losetup wants to warn, or even refuse, to attach files < 512 bytes in size that'd be fine. I didn't intentionally want a < 512 byte file - it was a total mistake :-)

In the particular scenario I originally encountered this problem with though, I was doing the ioctl()s to attach the (mistakenly zero length) file to the loop device directly from libvirt, and then wondering why 'losetup -a' didn't show them. So it would still be desirable to find a way to get 'losetup -a' to report such files, or for the kernel itself to refuse to allow it.

(In reply to comment #3)
> Having a file < 512 bytes makes no sense for a blockdevice mapping. The loop
> device can not be read or write, we can only handle full blocks. That the
> kernel allows that is questionable

There is possible to modify the device capacity. I can imagine scenario when you associate an empty file (or set sizelimit=0) and later modify the size by LOOP_SET_CAPACITY ioctl.

> but we think that losetup should
> already check these values at device setup.

I'll add the warning about misaligned or too small sizes to losetup(1). The stupid thing is that the empty loopdev is not in /proc/partitions, so if we want to support this crazy feature then we have to _scan_ /sys/block/ :-(

Fixed by upstream commit e4062c72d1733b0b99ed1c6269c996d6194e869b (new version scans /sys/block). 

Not urgen issue, Fedora package will be updated after upgrade to the new upstream version.