> 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--- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
