Re: Bug in mkfs.btrfs?!

On Mon, Jan 24, 2011 at 02:53:05PM +0100, Felix Blanke wrote:

quoted

On 24. January 2011 - 13:13, Hugo Mills wrote:

quoted

On Mon, Jan 24, 2011 at 02:01:04PM +0100, Felix Blanke wrote:

quoted

Hi,

you were talking about the LOOP_GET_STATUS function. I'm not quite sure where does it
came from. Is it part of the kernel? Or does it come from the util-linux package?

   It's an ioctl (number 0x4c03) that works on loop devices, and
returns information about the loop device. Being an ioctl, it's
implemented in the kernel. Unfortunately, since it's part of the
kernel API, the size of the name field is probably fixed for the rest
of time, and so the bug can't be fixed.

That sounds great :/

   If you change the layout of the structure, then you have two
incompatible APIs: the one before, and the one after the change. Code
that's compiled to work with one version won't work with the other.
This will cause all manner of pain, and the kernel developers tend
(quite rightly) to come down hard on any attempts to do that kind of
thing.

quoted

quoted

quoted

Btw: I tested it with util-linux-2.19-rc1. The strace still contains
the truncated path, and no '*'. Therefore I think that ioctl is from
the kernel.

   Indeed.

   What I find interesting is that my copy of losetup follows symlinks
from the /dev/disk/by-id/... path back to the original device node
(/dev/dm-7 in my test case) before setting up the loop, whereas yours
seems not to.

   I think that that's probably the easiest solution to this problem:
modify losetup to use realpath(3) on the device node it's given.

quoted

I dont see where that helps with the problem. If I understand
Goffredo correct mkfs.btrfs is using the ioctl to get the path.
Letting losetup following the link will fix the output of "losetup
/dev/loopX", but it will not fix the truncated path from the ioctl
and therefore it will not fix the problem with mkfs.btrfs.

   What seems to be happening is that at the point that losetup
creates the loop device, it stores the pathname of the underlying
device node in the kernel. When you run losetup -a or mkfs.btrfs,
these use the LOOP_GET_STATUS ioctl to retrieve that pathname. The
pathname that LOOP_GET_STATUS returns is truncated to 64 bytes (63
ASCII characters, plus the zero terminator). losetup -a simply prints
it; mkfs.btrfs tries to use it as a parameter to realpath(3). It is at
this point that the symptoms of breakage occur, because the truncated
name doesn't exist, so realpath returns an error.

   If, instead, the initial losetup call tracked the symlinks back to
the original device node (i.e. something like "/dev/sdb3", or
"/dev/mapper/ruthven-btest" in my example), then the name that's
stored in the kernel would be shorter, and we'd be less likely to see
the truncation. This is what my copy of losetup seems to be doing. I
can't see any distribution-specific patches in the source for
util-linux that would do this, though.

Ah, I see :)
It is strange that your util-linux does follow the link. 

I tried to read the informations with the newest (original) util-linux. But the
assignment of the /dev/loopX was done with an older util-linux. I'll try to use the
new util-linux to decrypt a device and look what losetup is reporting. Maybe that
will solve the problem and it's just my "old" version of util-linux which has that
problem.


Felix

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- But people have always eaten people,  / what else is there to ---  
         eat?  / If the Juju had meant us not to eat people / he         
                     wouldn't have made us of meat.                      

---end quoted text---