Re: Bug in mkfs.btrfs?!

[Felix Blanke <felixblanke@gmail.com>]

> On Mon, Jan 24, 2011 at 02:53:05PM +0100, Felix Blanke wrote:
> > On 24. January 2011 - 13:13, Hugo Mills wrote:
> > > On Mon, Jan 24, 2011 at 02:01:04PM +0100, Felix Blanke wrote:
> > > > 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.
> 
> > > > 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.
> 
> > 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---