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 <redacted>
To: kreijack@inwind.it
Cc: Hugo Mills <redacted>, Felix Blanke
 [off-list ref], linux-btrfs@vger.kernel.org
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills [off-list ref], kreijack@inwind.it, Hugo
 Mills [off-list ref], Felix Blanke [off-list ref],
 linux-btrfs@vger.kernel.org

On Sun, Jan 23, 2011 at 11:02:16PM +0100, Goffredo Baroncelli wrote:

quoted

On 01/23/2011 07:18 PM, Hugo Mills wrote:

quoted

   Hi, Felix,

On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote:

quoted

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).

quoted

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---