Hi, losetup is part of "util-linux":
http://www.kernel.org/pub/linux/utils/util-linux/ I'm using 2.17.2. Don't know if that is some kind of revision. I tried the newest version 2.19-rc1. There seems to be some kind of "fix": scooter ~ # /home/fame/tmp/util-linux-2.19-rc1/mount/losetup -a /dev/loop0: [0010]:3154 (/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-pa*), encryption (type 16) /dev/loop1: [0010]:4552 (/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-pa*), encryption (type 16) /dev/loop2: [0010]:4623 (/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part*), encryption (type 16) /dev/loop3: [0010]:4604 (/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82035988-part*), encryption (type 16) /dev/loop4: [0010]:4586 (/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82030114-part*), encryption (type 16) If the path is to long they add a '*' :) Do you think that will solve the problem? I'll try it tomorrow. Regards, Felix On 23. January 2011 - 23:27, Hugo Mills wrote: > Date: Sun, 23 Jan 2011 23:27:20 +0000 > From: Hugo Mills <h...@carfax.org.uk> > To: kreij...@inwind.it > Cc: Hugo Mills <hugo-l...@carfax.org.uk>, Felix Blanke > <felixbla...@gmail.com>, linux-btrfs@vger.kernel.org > Subject: Re: Bug in mkfs.btrfs?! > Mail-Followup-To: Hugo Mills <h...@carfax.org.uk>, kreij...@inwind.it, Hugo > Mills <hugo-l...@carfax.org.uk>, Felix Blanke <felixbla...@gmail.com>, > linux-btrfs@vger.kernel.org > > On Sun, Jan 23, 2011 at 11:02:16PM +0100, Goffredo Baroncelli wrote: > > On 01/23/2011 07:18 PM, Hugo Mills wrote: > > > Hi, Felix, > > > > > > On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote: > > >> It was a simple: > > >> > > >> mkfs.btrfs -L backup -d single /dev/loop2 > > >> > > >> But it also happens without the options, like: > > >> > > >> mkfs.btrfs /dev/loop2 > > >> > > >> > > >> /dev/loop2 is a loop device, which is aes encrypted. The output of > > >> "losetup /dev/loop2": > > >> > > >> /dev/loop2: [0010]:5324 > > >> (/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3) > > >> encryption=AES128 > > >> > > >> > > >> Thanks you for looking into this! > > >> While writing this I read your second mail. The strace output is > > >> attached. > > > > > > OK, I've traced through the functions being called, and I really > > > can't see where it could be truncating the name, unless your system > > > has a stupidly small value of PATH_MAX. > > > > It seems that when mkfs.btrfs checks if the passed block device is > > already mounted, uses the ioctl LOOP_GET_STATUS [1]. This ioctl has as > > argument the struct loop_info. > > > > This ioctl, should return the info about the back-end of the loop > > device. The file name is returned via the "lo_name" field, which is an > > array of 64 char...[2] > > Good catch, Goffredo. I completely missed that. > > Interestingly, on my system, lo_name is indeed defined as 64 chars, > but I don't see Felix's problem. When I do losetup on the > /dev/disk/by-id/... link, my version of losetup seems to be following > the link: > > # losetup /dev/loop1 > /dev/disk/by-id/dm-uuid-LVM-XRQLHQNa0xEeIZL4ofuBGIcfkr1Dhry8YHhkjaw4bvZA4meDFQfEMy5elIsVNeWl > > # losetup -a > /dev/loop1: [0005]:1423915 (/dev/mapper/ruthven-btemp) > > I'm running Debian, and the mount package version 2.17.2-5 (losetup > is part of mount, it seems). > > > Felix, what is the output of the following command ? > > > > /sbin/losetup -a > > > > If my analysis is correct, this command should return the filename > > trunked at the 64th character too. > > 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 > --- Sometimes, when I'm alone, I Google myself. --- ---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
