Bug in mkfs.btrfs?!

Bug in mkfs.btrfs?!

[Felix Blanke]

Hi,

I wanted to create a new btrfs fs for my backups.
When trying to mkfs.btrfs for that  device, I'm getting

"error checking /dev/loop2 mount status"


With strace I see where the problem is:

lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)



The problem is there is something missing at the end of the link, should be
something like "-part1", "-part2" etc.


I'll try the patch with the --foce option.

Regards,
Felix

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

I was able to create the fs with the --force options. But that bug should be fixed,
too :)

Is that link maybe too long? It is created by udev, and there was never a problem
using that link.


Regards,
Felix

On 22. January 2011 - 15:45, Felix Blanke wrote:
> Date: Sat, 22 Jan 2011 15:45:13 +0100
> From: Felix Blanke <felixblanke@gmail.com>
> To: linux-btrfs@vger.kernel.org
> Subject: Bug in mkfs.btrfs?!
> 
> Hi,
> 
> I wanted to create a new btrfs fs for my backups.
> When trying to mkfs.btrfs for that  device, I'm getting
> 
> "error checking /dev/loop2 mount status"
> 
> 
> With strace I see where the problem is:
> 
> lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
> 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
> 
> 
> 
> The problem is there is something missing at the end of the link, should be
> something like "-part1", "-part2" etc.
> 
> 
> I'll try the patch with the --foce option.
> 
> Regards,
> Felix
> 
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Sat, Jan 22, 2011 at 03:52:22PM +0100, Felix Blanke wrote:
> I was able to create the fs with the --force options. But that bug should be fixed,
> too :)
> 
> Is that link maybe too long? It is created by udev, and there was never a problem
> using that link.

   Yes, it certainly looks like it. There's 63 characters in the name
in your strace report, so it looks like it's being truncated somewhere.

   What was the exact command line you used to get the error?

   Hugo.

> Regards,
> Felix
> 
> On 22. January 2011 - 15:45, Felix Blanke wrote:
> > Date: Sat, 22 Jan 2011 15:45:13 +0100
> > From: Felix Blanke <felixblanke@gmail.com>
> > To: linux-btrfs@vger.kernel.org
> > Subject: Bug in mkfs.btrfs?!
> > 
> > Hi,
> > 
> > I wanted to create a new btrfs fs for my backups.
> > When trying to mkfs.btrfs for that  device, I'm getting
> > 
> > "error checking /dev/loop2 mount status"
> > 
> > 
> > With strace I see where the problem is:
> > 
> > lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
> > 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
> > 
> > 
> > 
> > The problem is there is something missing at the end of the link, should be
> > something like "-part1", "-part2" etc.
> > 
> > 
> > I'll try the patch with the --foce option.
> > 
> > Regards,
> > Felix
> > 
> ---end quoted text---

-- 
=== 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
     --- Great oxymorons of the world, no. 9: Standard Deviation ---     

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

On Sat, Jan 22, 2011 at 03:11:24PM +0000, Hugo Mills wrote:
> On Sat, Jan 22, 2011 at 03:52:22PM +0100, Felix Blanke wrote:
> > I was able to create the fs with the --force options. But that bug should be fixed,
> > too :)
> > 
> > Is that link maybe too long? It is created by udev, and there was never a problem
> > using that link.
> 
>    Yes, it certainly looks like it. There's 63 characters in the name
> in your strace report, so it looks like it's being truncated somewhere.
> 
>    What was the exact command line you used to get the error?

   Also, can you post the full strace output? (Just so I can get a
better idea of where it's getting to in the code).

   I've just tried it myself:

$ sudo mkfs.btrfs /dev/disk/by-id/dm-uuid-LVM-XRQLHQNa0xEeIZL4ofuBGIcfkr1Dhry8YHhkjaw4bvZA4meDFQfEMy5elIsVNeWl 

WARNING! - Btrfs v0.19-36-g70c6c10 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/disk/by-id/dm-uuid-LVM-XRQLHQNa0xEeIZL4ofuBGIcfkr1Dhry8YHhkjaw4bvZA4meDFQfEMy5elIsVNeWl
	nodesize 4096 leafsize 4096 sectorsize 4096 size 1.00GB
Btrfs v0.19-36-g70c6c10

   Seems perfectly happy with a 92-character device name...

   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
     --- Great oxymorons of the world, no. 9: Standard Deviation ---     

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]

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.

Regards,
Felix

P.S.: The btrfs wiki is down. If someone reads this and have time to answer:

Means "-d single" that the data are not spread across the devices? The default is
raid0, right? I want some kind of security that if a device crashes only the
files on that damaged device are gone. Raid1 will be the next step, but act. I don't
have money for that :)


On 22. January 2011 - 15:11, Hugo Mills wrote:
> Date: Sat, 22 Jan 2011 15:11:24 +0000
> From: Hugo Mills <hugo-lkml@carfax.org.uk>
> To: Felix Blanke <felixblanke@gmail.com>
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> Mail-Followup-To: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
>  <felixblanke@gmail.com>, linux-btrfs@vger.kernel.org
> 
> On Sat, Jan 22, 2011 at 03:52:22PM +0100, Felix Blanke wrote:
> > I was able to create the fs with the --force options. But that bug should be fixed,
> > too :)
> > 
> > Is that link maybe too long? It is created by udev, and there was never a problem
> > using that link.
> 
>    Yes, it certainly looks like it. There's 63 characters in the name
> in your strace report, so it looks like it's being truncated somewhere.
> 
>    What was the exact command line you used to get the error?
> 
>    Hugo.
> 
> > Regards,
> > Felix
> > 
> > On 22. January 2011 - 15:45, Felix Blanke wrote:
> > > Date: Sat, 22 Jan 2011 15:45:13 +0100
> > > From: Felix Blanke <felixblanke@gmail.com>
> > > To: linux-btrfs@vger.kernel.org
> > > Subject: Bug in mkfs.btrfs?!
> > > 
> > > Hi,
> > > 
> > > I wanted to create a new btrfs fs for my backups.
> > > When trying to mkfs.btrfs for that  device, I'm getting
> > > 
> > > "error checking /dev/loop2 mount status"
> > > 
> > > 
> > > With strace I see where the problem is:
> > > 
> > > lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
> > > 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
> > > 
> > > 
> > > 
> > > The problem is there is something missing at the end of the link, should be
> > > something like "-part1", "-part2" etc.
> > > 
> > > 
> > > I'll try the patch with the --foce option.
> > > 
> > > Regards,
> > > Felix
> > > 
> > ---end quoted text---
> 
> -- 
> === 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
>      --- Great oxymorons of the world, no. 9: Standard Deviation ---     


---end quoted text---

[-- Attachment #2: strace --]
[-- Type: text/plain, Size: 7366 bytes --]

execve("/sbin/mkfs.btrfs", ["mkfs.btrfs", "/dev/loop2"], [/* 41 vars */]) = 0
brk(0)                                  = 0x653000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd7e42d000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=156346, ...}) = 0
mmap(NULL, 156346, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fcd7e406000
close(3)                                = 0
open("/lib/libuuid.so.1", O_RDONLY)     = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\27\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18776, ...}) = 0
mmap(NULL, 2113952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fcd7e00c000
mprotect(0x7fcd7e010000, 2093056, PROT_NONE) = 0
mmap(0x7fcd7e20f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fcd7e20f000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\354\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1424672, ...}) = 0
mmap(NULL, 3533704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fcd7dcad000
mprotect(0x7fcd7de02000, 2097152, PROT_NONE) = 0
mmap(0x7fcd7e002000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155000) = 0x7fcd7e002000
mmap(0x7fcd7e007000, 19336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fcd7e007000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd7e405000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd7e403000
arch_prctl(ARCH_SET_FS, 0x7fcd7e403740) = 0
mprotect(0x7fcd7e002000, 16384, PROT_READ) = 0
mprotect(0x7fcd7e20f000, 4096, PROT_READ) = 0
mprotect(0x620000, 4096, PROT_READ)     = 0
mprotect(0x7fcd7e42e000, 4096, PROT_READ) = 0
munmap(0x7fcd7e406000, 156346)          = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd7e42c000
write(1, "\n", 1)                       = 1
write(1, "WARNING! - Btrfs v0.19-35-g1b444"..., 57) = 57
write(1, "WARNING! - see http://btrfs.wiki"..., 57) = 57
write(1, "\n", 1)                       = 1
open("/dev/loop2", O_RDONLY)            = 3
brk(0)                                  = 0x653000
brk(0x675000)                           = 0x675000
pread(3, "D\345\355-\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2859, 65536) = 2859
pread(3, "\344\204\305\343\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2859, 67108864) = 2859
pread(3, "\31\3\223\322\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2859, 274877906944) = 2859
close(3)                                = 0
open("/proc/mounts", O_RDONLY)          = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcd7e42b000
read(3, "rootfs / rootfs rw 0 0\n/dev/sdb4"..., 1024) = 877
stat("/dev/loop2", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 2), ...}) = 0
open("/dev/loop2", O_RDONLY)            = 4
ioctl(4, 0x4c03, 0x7fffbbd8a660)        = 0
close(4)                                = 0
stat("/dev/sdb4", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 20), ...}) = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3620, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=820, ...}) = 0
lstat("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", "../../sda3", 4095) = 10
lstat("/dev/sda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3620, ...}) = 0
lstat("/dev/sdb4", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 20), ...}) = 0
stat("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
stat("/dev/sdb4", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 20), ...}) = 0
stat("/dev/loop2", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 2), ...}) = 0
open("/dev/loop2", O_RDONLY)            = 4
ioctl(4, 0x4c03, 0x7fffbbd8a660)        = 0
close(4)                                = 0
stat("/dev/loop4", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 4), ...}) = 0
open("/dev/loop4", O_RDONLY)            = 4
ioctl(4, 0x4c03, 0x7fffbbd8a660)        = 0
close(4)                                = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3620, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=820, ...}) = 0
lstat("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", "../../sda3", 4095) = 10
lstat("/dev/sda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3620, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=820, ...}) = 0
lstat("/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82030114-part1", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82030114-part1", "../../sdd1", 4095) = 10
lstat("/dev/sdd1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 49), ...}) = 0
stat("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
stat("/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82030114-part1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 49), ...}) = 0
stat("/dev/loop2", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 2), ...}) = 0
open("/dev/loop2", O_RDONLY)            = 4
ioctl(4, 0x4c03, 0x7fffbbd8a660)        = 0
close(4)                                = 0
stat("/dev/loop1", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) = 0
open("/dev/loop1", O_RDONLY)            = 4
ioctl(4, 0x4c03, 0x7fffbbd8a660)        = 0
close(4)                                = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3620, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=820, ...}) = 0
lstat("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3", "../../sda3", 4095) = 10
lstat("/dev/sda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3620, ...}) = 0
lstat("/dev/disk", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/disk/by-id", {st_mode=S_IFDIR|0755, st_size=820, ...}) = 0
lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par", 0x7fffbbd88520) = -1 ENOENT (No such file or directory)
close(3)                                = 0
munmap(0x7fcd7e42b000, 4096)            = 0
write(2, "error checking /dev/loop2 mount "..., 39) = 39
exit_group(1)                           = ?

Re: Bug in mkfs.btrfs?!

[Chris Samuel]

On Sun, January 23, 2011 2:56 am, 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

I'm not familiar with losetup, is /dev/loop2 a symlink ?

If so could you post an ls -l of /dev/loop2 please ?

cheers,
Chris
-- 
Chris Samuel, Melbourne, Australia
http://www.csamuel.org/

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

Hi,

no :) loop2 is the decrypted device.


A small example:

/dev/sda1 is encrypted. Then you run losetup with some options and /dev/sda1, enter
the password and after that /dev/loop1 will be created.

>From now on you're using /dev/loop1 as your device node, e.g.

fdisk -l /dev/loop1


If you would use /dev/sda1 instead you would just see garbage, because of the
encryption :)



Regards,
Felix

On 23. January 2011 - 09:54, Chris Samuel wrote:
> Date:	Sun, 23 Jan 2011 09:54:34 +1100
> From: Chris Samuel <chris@csamuel.org>
> To: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> 
> 
> On Sun, January 23, 2011 2:56 am, 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
> 
> I'm not familiar with losetup, is /dev/loop2 a symlink ?
> 
> If so could you post an ls -l of /dev/loop2 please ?
> 
> cheers,
> Chris
> -- 
> Chris Samuel, Melbourne, Australia
> http://www.csamuel.org/
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]

   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.

   Can you apply the following patch (to the "next" branch of the
btrfs-progs git repo), rebuild, and try again? It's just adding some
debugging output to track what it's looking at.

   Hugo.


diff --git a/mkfs.c b/mkfs.c
index 2e99b95..51a5096 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -422,6 +422,7 @@ int main(int ac, char **av)
 	printf("WARNING! - see http://btrfs.wiki.kernel.org before using\n\n");
 
 	file = av[optind++];
+	printf("Checking whether %s is part of a mounted filesystem\n", file);
 	ret = check_mounted(file);
 	if (ret < 0) {
 		fprintf(stderr, "error checking %s mount status\n", file);
diff --git a/utils.c b/utils.c
index fd894f3..7fa3149 100644
--- a/utils.c
+++ b/utils.c
@@ -610,12 +610,16 @@ int resolve_loop_device(const char* loop_dev, char* loop_file, int max_len)
 	int ret_ioctl;
 	struct loop_info loopinfo;
 
+	printf("Resolving loop device %s (length %d)\n", loop_dev, max_len);
+
 	if ((loop_fd = open(loop_dev, O_RDONLY)) < 0)
 		return -errno;
 
 	ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS, &loopinfo);
 	close(loop_fd);
 
+	printf("Loop name = %s\n", loopinfo.lo_name);
+
 	if (ret_ioctl == 0)
 		strncpy(loop_file, loopinfo.lo_name, max_len);
 	else
@@ -639,6 +643,9 @@ int is_same_blk_file(const char* a, const char* b)
 		return -errno;
 	}
 
+	printf("Realpath of %s was %s\n", a, real_a);
+	printf("Realpath of %s was %s\n", b, real_b);
+
 	/* Identical path? */
 	if(strcmp(real_a, real_b) == 0)
 		return 1;
@@ -680,6 +687,9 @@ int is_same_loop_file(const char* a, const char* b)
 	const char* final_b;
 	int ret;
 
+	printf("is_same_loop_file: %s and %s\n", a, b);
+	printf("PATH_MAX = %d\n", PATH_MAX);
+
 	/* Resolve a if it is a loop device */
 	if((ret = is_loop_device(a)) < 0) {
 	   return ret;
@@ -784,8 +794,10 @@ int check_mounted(const char* file)
 			if(strcmp(mnt->mnt_type, "btrfs") != 0)
 				continue;
 
+			printf("Testing if btrfs device is in the dev list: %s\n", mnt->mnt_fsname);
 			ret = blk_file_in_dev_list(fs_devices_mnt, mnt->mnt_fsname);
 		} else {
+			printf("Testing if non-btrfs device is block or regular: %s\n", mnt->mnt_fsname);
 			/* ignore entries in the mount table that are not
 			   associated with a file*/
 			if((ret = is_existing_blk_or_reg_file(mnt->mnt_fsname)) < 0)
diff --git a/volumes.c b/volumes.c
index 7671855..2496fbd 100644
--- a/volumes.c
+++ b/volumes.c
@@ -130,6 +130,8 @@ static int device_list_add(const char *path,
 		device->fs_devices = fs_devices;
 	}
 
+	printf("Device added with name %s\n", device->name);
+
 	if (found_transid > fs_devices->latest_trans) {
 		fs_devices->latest_devid = devid;
 		fs_devices->latest_trans = found_transid;
@@ -223,6 +225,7 @@ int btrfs_scan_one_device(int fd, const char *path,
 		*total_devs = btrfs_super_num_devices(disk_super);
 	uuid_unparse(disk_super->fsid, uuidbuf);
 
+	printf("Adding device %s to list\n", path);
 	ret = device_list_add(path, disk_super, devid, fs_devices_ret);
 
 error_brelse:


-- 
=== 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
               --- Doughnut furs ache me, Omar Dorlin. ---               

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Goffredo Baroncelli]

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]

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.

Goffredo

[1] file util.c, function resolve_loop_device
[2]
http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L26
  and
http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L15





> 
>    Can you apply the following patch (to the "next" branch of the
> btrfs-progs git repo), rebuild, and try again? It's just adding some
> debugging output to track what it's looking at.
> 
>    Hugo.
> 
> 
> diff --git a/mkfs.c b/mkfs.c
> index 2e99b95..51a5096 100644
> --- a/mkfs.c
> +++ b/mkfs.c
> @@ -422,6 +422,7 @@ int main(int ac, char **av)
>  	printf("WARNING! - see http://btrfs.wiki.kernel.org before using\n\n");
>  
>  	file = av[optind++];
> +	printf("Checking whether %s is part of a mounted filesystem\n", file);
>  	ret = check_mounted(file);
>  	if (ret < 0) {
>  		fprintf(stderr, "error checking %s mount status\n", file);
> diff --git a/utils.c b/utils.c
> index fd894f3..7fa3149 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -610,12 +610,16 @@ int resolve_loop_device(const char* loop_dev, char* loop_file, int max_len)
>  	int ret_ioctl;
>  	struct loop_info loopinfo;
>  
> +	printf("Resolving loop device %s (length %d)\n", loop_dev, max_len);
> +
>  	if ((loop_fd = open(loop_dev, O_RDONLY)) < 0)
>  		return -errno;
>  
>  	ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS, &loopinfo);
>  	close(loop_fd);
>  
> +	printf("Loop name = %s\n", loopinfo.lo_name);
> +
>  	if (ret_ioctl == 0)
>  		strncpy(loop_file, loopinfo.lo_name, max_len);
>  	else
> @@ -639,6 +643,9 @@ int is_same_blk_file(const char* a, const char* b)
>  		return -errno;
>  	}
>  
> +	printf("Realpath of %s was %s\n", a, real_a);
> +	printf("Realpath of %s was %s\n", b, real_b);
> +
>  	/* Identical path? */
>  	if(strcmp(real_a, real_b) == 0)
>  		return 1;
> @@ -680,6 +687,9 @@ int is_same_loop_file(const char* a, const char* b)
>  	const char* final_b;
>  	int ret;
>  
> +	printf("is_same_loop_file: %s and %s\n", a, b);
> +	printf("PATH_MAX = %d\n", PATH_MAX);
> +
>  	/* Resolve a if it is a loop device */
>  	if((ret = is_loop_device(a)) < 0) {
>  	   return ret;
> @@ -784,8 +794,10 @@ int check_mounted(const char* file)
>  			if(strcmp(mnt->mnt_type, "btrfs") != 0)
>  				continue;
>  
> +			printf("Testing if btrfs device is in the dev list: %s\n", mnt->mnt_fsname);
>  			ret = blk_file_in_dev_list(fs_devices_mnt, mnt->mnt_fsname);
>  		} else {
> +			printf("Testing if non-btrfs device is block or regular: %s\n", mnt->mnt_fsname);
>  			/* ignore entries in the mount table that are not
>  			   associated with a file*/
>  			if((ret = is_existing_blk_or_reg_file(mnt->mnt_fsname)) < 0)
> diff --git a/volumes.c b/volumes.c
> index 7671855..2496fbd 100644
> --- a/volumes.c
> +++ b/volumes.c
> @@ -130,6 +130,8 @@ static int device_list_add(const char *path,
>  		device->fs_devices = fs_devices;
>  	}
>  
> +	printf("Device added with name %s\n", device->name);
> +
>  	if (found_transid > fs_devices->latest_trans) {
>  		fs_devices->latest_devid = devid;
>  		fs_devices->latest_trans = found_transid;
> @@ -223,6 +225,7 @@ int btrfs_scan_one_device(int fd, const char *path,
>  		*total_devs = btrfs_super_num_devices(disk_super);
>  	uuid_unparse(disk_super->fsid, uuidbuf);
>  
> +	printf("Adding device %s to list\n", path);
>  	ret = device_list_add(path, disk_super, devid, fs_devices_ret);
>  
>  error_brelse:
> 
> 

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

Hi Goffredo,

you're damn right :)

scooter ~ # losetup -a
/dev/loop0: [0010]:3154
(/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par) encryption=AES128
/dev/loop1: [0010]:4552
(/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par) encryption=AES128
/dev/loop2: [0010]:4623
(/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3) encryption=AES128
/dev/loop3: [0010]:4604
(/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82035988-part1) encryption=AES128
/dev/loop4: [0010]:4586
(/dev/disk/by-id/ata-WDC_WD5000AAKS-65YGA0_WD-WCAS82030114-part1) encryption=AES128


Sorry that I didn't saw that earlier. If I would use /dev/sdxx instead of
/dev/disk/by-id/ for decrypting the devices it would be working. But those ids didn't
change if I remove/add a device, so it would be nice to be able to use those ids.


Do you know where  the right place to report that bug is?


Regards,
Felix



On 23. January 2011 - 23:02, Goffredo Baroncelli wrote:
> Date: Sun, 23 Jan 2011 23:02:16 +0100
> From: Goffredo Baroncelli <kreijack@libero.it>
> To: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
>  <felixblanke@gmail.com>
> CC: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> 
> 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]
> 
> 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.
> 
> Goffredo
> 
> [1] file util.c, function resolve_loop_device
> [2]
> http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L26
>   and
> http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L15
> 
> 
> 
> 
> 
> > 
> >    Can you apply the following patch (to the "next" branch of the
> > btrfs-progs git repo), rebuild, and try again? It's just adding some
> > debugging output to track what it's looking at.
> > 
> >    Hugo.
> > 
> > 
> > diff --git a/mkfs.c b/mkfs.c
> > index 2e99b95..51a5096 100644
> > --- a/mkfs.c
> > +++ b/mkfs.c
> > @@ -422,6 +422,7 @@ int main(int ac, char **av)
> >  	printf("WARNING! - see http://btrfs.wiki.kernel.org before using\n\n");
> >  
> >  	file = av[optind++];
> > +	printf("Checking whether %s is part of a mounted filesystem\n", file);
> >  	ret = check_mounted(file);
> >  	if (ret < 0) {
> >  		fprintf(stderr, "error checking %s mount status\n", file);
> > diff --git a/utils.c b/utils.c
> > index fd894f3..7fa3149 100644
> > --- a/utils.c
> > +++ b/utils.c
> > @@ -610,12 +610,16 @@ int resolve_loop_device(const char* loop_dev, char* loop_file, int max_len)
> >  	int ret_ioctl;
> >  	struct loop_info loopinfo;
> >  
> > +	printf("Resolving loop device %s (length %d)\n", loop_dev, max_len);
> > +
> >  	if ((loop_fd = open(loop_dev, O_RDONLY)) < 0)
> >  		return -errno;
> >  
> >  	ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS, &loopinfo);
> >  	close(loop_fd);
> >  
> > +	printf("Loop name = %s\n", loopinfo.lo_name);
> > +
> >  	if (ret_ioctl == 0)
> >  		strncpy(loop_file, loopinfo.lo_name, max_len);
> >  	else
> > @@ -639,6 +643,9 @@ int is_same_blk_file(const char* a, const char* b)
> >  		return -errno;
> >  	}
> >  
> > +	printf("Realpath of %s was %s\n", a, real_a);
> > +	printf("Realpath of %s was %s\n", b, real_b);
> > +
> >  	/* Identical path? */
> >  	if(strcmp(real_a, real_b) == 0)
> >  		return 1;
> > @@ -680,6 +687,9 @@ int is_same_loop_file(const char* a, const char* b)
> >  	const char* final_b;
> >  	int ret;
> >  
> > +	printf("is_same_loop_file: %s and %s\n", a, b);
> > +	printf("PATH_MAX = %d\n", PATH_MAX);
> > +
> >  	/* Resolve a if it is a loop device */
> >  	if((ret = is_loop_device(a)) < 0) {
> >  	   return ret;
> > @@ -784,8 +794,10 @@ int check_mounted(const char* file)
> >  			if(strcmp(mnt->mnt_type, "btrfs") != 0)
> >  				continue;
> >  
> > +			printf("Testing if btrfs device is in the dev list: %s\n", mnt->mnt_fsname);
> >  			ret = blk_file_in_dev_list(fs_devices_mnt, mnt->mnt_fsname);
> >  		} else {
> > +			printf("Testing if non-btrfs device is block or regular: %s\n", mnt->mnt_fsname);
> >  			/* ignore entries in the mount table that are not
> >  			   associated with a file*/
> >  			if((ret = is_existing_blk_or_reg_file(mnt->mnt_fsname)) < 0)
> > diff --git a/volumes.c b/volumes.c
> > index 7671855..2496fbd 100644
> > --- a/volumes.c
> > +++ b/volumes.c
> > @@ -130,6 +130,8 @@ static int device_list_add(const char *path,
> >  		device->fs_devices = fs_devices;
> >  	}
> >  
> > +	printf("Device added with name %s\n", device->name);
> > +
> >  	if (found_transid > fs_devices->latest_trans) {
> >  		fs_devices->latest_devid = devid;
> >  		fs_devices->latest_trans = found_transid;
> > @@ -223,6 +225,7 @@ int btrfs_scan_one_device(int fd, const char *path,
> >  		*total_devs = btrfs_super_num_devices(disk_super);
> >  	uuid_unparse(disk_super->fsid, uuidbuf);
> >  
> > +	printf("Adding device %s to list\n", path);
> >  	ret = device_list_add(path, disk_super, devid, fs_devices_ret);
> >  
> >  error_brelse:
> > 
> > 
> 
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Helmut Hullen]

Hallo, Felix,

Du meintest am 24.01.11:

> Sorry that I didn't saw that earlier. If I would use /dev/sdxx
> instead of /dev/disk/by-id/ for decrypting the devices it would be
> working. But those ids didn't change if I remove/add a device, so it
> would be nice to be able to use those ids.

I prefer working with LABELs. They can be short and self explaining.

Viele Gruesse!
Helmut

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

Lol :)

You can't use labels for the decryption, because an encrypted device has no label, it
doesn't even have a filesystem and you can't say if there are any kind of data on it
(in my case) :)

You can use labels after you have decrypted the device. Then I'm using labels, too.
But that doesn't help with  this problem :)


Regards,
Felix


On 24. January 2011 - 08:42, Helmut Hullen wrote:
> Date:	24 Jan 2011 08:42:00 +0100
> From: Helmut Hullen <Hullen@t-online.de>
> To: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> 
> Hallo, Felix,
> 
> Du meintest am 24.01.11:
> 
> > Sorry that I didn't saw that earlier. If I would use /dev/sdxx
> > instead of /dev/disk/by-id/ for decrypting the devices it would be
> > working. But those ids didn't change if I remove/add a device, so it
> > would be nice to be able to use those ids.
> 
> I prefer working with LABELs. They can be short and self explaining.
> 
> Viele Gruesse!
> Helmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

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 <hugo@carfax.org.uk>
> To: kreijack@inwind.it
> Cc: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
>  <felixblanke@gmail.com>, linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> Mail-Followup-To: Hugo Mills <hugo@carfax.org.uk>, kreijack@inwind.it, Hugo
>  Mills <hugo-lkml@carfax.org.uk>, Felix Blanke <felixblanke@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---

Re: Bug in mkfs.btrfs?!

[Fajar A. Nugraha]

On Mon, Jan 24, 2011 at 6:58 AM, Felix Blanke <felixblanke@gmail.com> w=
rote:
> 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*), en=
cryption =A0(type
> 16)

> If the path is to long they add a '*' :) Do you think that will solve=
 the problem?

It shouldn't.

However, since you're using loopback for encryption, why not use
dm-crypt instead?

--=20
=46ajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

Counter question: Why should I? :)


I used dm-crypt with luks some time ago, but it is really slooow. So I =
talked with
the dm-crypt devs. and they gave me the hint to test loop-aes, for more=
 speed. It is
about 4x faster for me :)

And I don't see any advantages using dm-crypt instead of loop-aes.



=46elix

On 24. January 2011 - 08:53, Fajar A. Nugraha wrote:
> Date: Mon, 24 Jan 2011 08:53:41 +0700
> From: "Fajar A. Nugraha" <list@fajar.net>
> To: Felix Blanke <felixblanke@gmail.com>
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
>=20
> On Mon, Jan 24, 2011 at 6:58 AM, Felix Blanke <felixblanke@gmail.com>=
 wrote:
> > 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 =A0(type
> > 16)
>=20
> > If the path is to long they add a '*' :) Do you think that will sol=
ve the problem?
>=20
> It shouldn't.
>=20
> However, since you're using loopback for encryption, why not use
> dm-crypt instead?
>=20
> --=20
> Fajar
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

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?

I'm searching for the right location where do report that bug :)


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.

Regards,
Felix

On 23. January 2011 - 23:02, Goffredo Baroncelli wrote:
> Date: Sun, 23 Jan 2011 23:02:16 +0100
> From: Goffredo Baroncelli <kreijack@libero.it>
> To: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
>  <felixblanke@gmail.com>
> CC: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> 
> 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]
> 
> 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.
> 
> Goffredo
> 
> [1] file util.c, function resolve_loop_device
> [2]
> http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L26
>   and
> http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L15
> 
> 
> 
> 
> 
> > 
> >    Can you apply the following patch (to the "next" branch of the
> > btrfs-progs git repo), rebuild, and try again? It's just adding some
> > debugging output to track what it's looking at.
> > 
> >    Hugo.
> > 
> > 
> > diff --git a/mkfs.c b/mkfs.c
> > index 2e99b95..51a5096 100644
> > --- a/mkfs.c
> > +++ b/mkfs.c
> > @@ -422,6 +422,7 @@ int main(int ac, char **av)
> >  	printf("WARNING! - see http://btrfs.wiki.kernel.org before using\n\n");
> >  
> >  	file = av[optind++];
> > +	printf("Checking whether %s is part of a mounted filesystem\n", file);
> >  	ret = check_mounted(file);
> >  	if (ret < 0) {
> >  		fprintf(stderr, "error checking %s mount status\n", file);
> > diff --git a/utils.c b/utils.c
> > index fd894f3..7fa3149 100644
> > --- a/utils.c
> > +++ b/utils.c
> > @@ -610,12 +610,16 @@ int resolve_loop_device(const char* loop_dev, char* loop_file, int max_len)
> >  	int ret_ioctl;
> >  	struct loop_info loopinfo;
> >  
> > +	printf("Resolving loop device %s (length %d)\n", loop_dev, max_len);
> > +
> >  	if ((loop_fd = open(loop_dev, O_RDONLY)) < 0)
> >  		return -errno;
> >  
> >  	ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS, &loopinfo);
> >  	close(loop_fd);
> >  
> > +	printf("Loop name = %s\n", loopinfo.lo_name);
> > +
> >  	if (ret_ioctl == 0)
> >  		strncpy(loop_file, loopinfo.lo_name, max_len);
> >  	else
> > @@ -639,6 +643,9 @@ int is_same_blk_file(const char* a, const char* b)
> >  		return -errno;
> >  	}
> >  
> > +	printf("Realpath of %s was %s\n", a, real_a);
> > +	printf("Realpath of %s was %s\n", b, real_b);
> > +
> >  	/* Identical path? */
> >  	if(strcmp(real_a, real_b) == 0)
> >  		return 1;
> > @@ -680,6 +687,9 @@ int is_same_loop_file(const char* a, const char* b)
> >  	const char* final_b;
> >  	int ret;
> >  
> > +	printf("is_same_loop_file: %s and %s\n", a, b);
> > +	printf("PATH_MAX = %d\n", PATH_MAX);
> > +
> >  	/* Resolve a if it is a loop device */
> >  	if((ret = is_loop_device(a)) < 0) {
> >  	   return ret;
> > @@ -784,8 +794,10 @@ int check_mounted(const char* file)
> >  			if(strcmp(mnt->mnt_type, "btrfs") != 0)
> >  				continue;
> >  
> > +			printf("Testing if btrfs device is in the dev list: %s\n", mnt->mnt_fsname);
> >  			ret = blk_file_in_dev_list(fs_devices_mnt, mnt->mnt_fsname);
> >  		} else {
> > +			printf("Testing if non-btrfs device is block or regular: %s\n", mnt->mnt_fsname);
> >  			/* ignore entries in the mount table that are not
> >  			   associated with a file*/
> >  			if((ret = is_existing_blk_or_reg_file(mnt->mnt_fsname)) < 0)
> > diff --git a/volumes.c b/volumes.c
> > index 7671855..2496fbd 100644
> > --- a/volumes.c
> > +++ b/volumes.c
> > @@ -130,6 +130,8 @@ static int device_list_add(const char *path,
> >  		device->fs_devices = fs_devices;
> >  	}
> >  
> > +	printf("Device added with name %s\n", device->name);
> > +
> >  	if (found_transid > fs_devices->latest_trans) {
> >  		fs_devices->latest_devid = devid;
> >  		fs_devices->latest_trans = found_transid;
> > @@ -223,6 +225,7 @@ int btrfs_scan_one_device(int fd, const char *path,
> >  		*total_devs = btrfs_super_num_devices(disk_super);
> >  	uuid_unparse(disk_super->fsid, uuidbuf);
> >  
> > +	printf("Adding device %s to list\n", path);
> >  	ret = device_list_add(path, disk_super, devid, fs_devices_ret);
> >  
> >  error_brelse:
> > 
> > 
> 
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

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.

> I'm searching for the right location where do report that bug :)

   linux-kernel mailing list, I think.

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

   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
                      --- make bzImage, not war ---                      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

On 24. January 2011 - 13:13, Hugo Mills wrote:
> Date: Mon, 24 Jan 2011 13:13:41 +0000
> From: Hugo Mills <hugo-lkml@carfax.org.uk>
> To: Felix Blanke <felixblanke@gmail.com>
> Cc: kreijack@inwind.it, Hugo Mills <hugo-lkml@carfax.org.uk>,
>  linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> Mail-Followup-To: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
>  <felixblanke@gmail.com>, kreijack@inwind.it, linux-btrfs@vger.kernel.org
> 
> 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 :/

> > I'm searching for the right location where do report that bug :)
> 
>    linux-kernel mailing list, I think.
> 
> > 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.


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
>                       --- make bzImage, not war ---                      


---end quoted text---

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3402 bytes --]

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.

   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.                      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Mon, Jan 24, 2011 at 02:29:36PM +0000, Hugo Mills wrote:
>    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.

   Hmm... Just had a thought: is
/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 on
your system a symlink or a device node? What does ls -l say?

   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.                      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

> On Mon, Jan 24, 2011 at 02:29:36PM +0000, Hugo Mills wrote:
> >    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.
> 
>    Hmm... Just had a thought: is
> /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 on
> your system a symlink or a device node? What does ls -l say?

It is a symlink created by udev:

ls -l /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 
lrwxrwxrwx 1 root root 10 Jan 23 23:39
/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 -> ../../sdb3

Following that link should work :)


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

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

util-linux-2.18-r1 and still no symlink following.

I'll ask for that at the kernel mailing list in the next days. If your (Hugo)
util-linux doesn't include any kind of patches that behaviour is really strange.


Felix

On 24. January 2011 - 15:44, Felix Blanke wrote:
> Date: Mon, 24 Jan 2011 15:44:14 +0100
> From: Felix Blanke <felixblanke@gmail.com>
> To: Hugo Mills <hugo-lkml@carfax.org.uk>
> Cc: kreijack@inwind.it, linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> 
> > On Mon, Jan 24, 2011 at 02:29:36PM +0000, Hugo Mills wrote:
> > >    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.
> > 
> >    Hmm... Just had a thought: is
> > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 on
> > your system a symlink or a device node? What does ls -l say?
> 
> It is a symlink created by udev:
> 
> ls -l /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 
> lrwxrwxrwx 1 root root 10 Jan 23 23:39
> /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 -> ../../sdb3
> 
> Following that link should work :)
> 
> 
> 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---
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Mon, Jan 24, 2011 at 05:52:58PM +0100, Felix Blanke wrote:
> util-linux-2.18-r1 and still no symlink following.
> 
> I'll ask for that at the kernel mailing list in the next days. If your (Hugo)
> util-linux doesn't include any kind of patches that behaviour is really strange.

   Just for reference:

Package description page:
http://packages.debian.org/squeeze/util-linux

Original upstream sources Debian are using:
http://ftp.de.debian.org/debian/pool/main/u/util-linux/util-linux_2.17.2.orig.tar.gz

Debian patches on top of that source (mostly to the build system):
http://ftp.de.debian.org/debian/pool/main/u/util-linux/util-linux_2.17.2-5.diff.gz

   Hugo.

> 
> Felix
> 
> On 24. January 2011 - 15:44, Felix Blanke wrote:
> > Date: Mon, 24 Jan 2011 15:44:14 +0100
> > From: Felix Blanke <felixblanke@gmail.com>
> > To: Hugo Mills <hugo-lkml@carfax.org.uk>
> > Cc: kreijack@inwind.it, linux-btrfs@vger.kernel.org
> > Subject: Re: Bug in mkfs.btrfs?!
> > 
> > > On Mon, Jan 24, 2011 at 02:29:36PM +0000, Hugo Mills wrote:
> > > >    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.
> > > 
> > >    Hmm... Just had a thought: is
> > > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 on
> > > your system a symlink or a device node? What does ls -l say?
> > 
> > It is a symlink created by udev:
> > 
> > ls -l /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 
> > lrwxrwxrwx 1 root root 10 Jan 23 23:39
> > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 -> ../../sdb3
> > 
> > Following that link should work :)
> > 
> > 
> > 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
    --- Turning,  pages turning in the widening bath, / The spine ---    
        cannot bear the humidity. / Books fall apart; the binding        
            cannot hold. / Page 129 is loosed upon the world.            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

Hi,

it is getting interesting :)


If I'm using the debian util-linux (with the patches) I'm getting an error while
executing losetup:

ioctl: LOOP_SET_STATUS: Invalid argument


Now the interesting part: The strace of the debian util-linux shows:

readlink("/dev", 0x7fffcea2a0a0, 4096)  = -1 EINVAL (Invalid argument)
readlink("/dev/disk", 0x7fffcea2a0a0, 4096) = -1 EINVAL (Invalid argument)
readlink("/dev/disk/by-id", 0x7fffcea2a0a0, 4096) = -1 EINVAL (Invalid argument)
readlink("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3",
"../../sda3", 4096) = 10
readlink("/dev/sda3", 0x7fffcea2a0a0, 4096) = -1 EINVAL (Invalid argument)


But in the gentoo util-linux there is no readlink in the strace. There are also those
readlinks with the unpatched source from that debian package.

If I use the tarball of gentoo and compile it by my own there are readlinks. I'll
take a look if there are any gentoo-patches applied during the build.

Felix

On 24. January 2011 - 17:00, Hugo Mills wrote:
> Date: Mon, 24 Jan 2011 17:00:24 +0000
> From: Hugo Mills <hugo-lkml@carfax.org.uk>
> To: Felix Blanke <felixblanke@gmail.com>
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> Mail-Followup-To: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
>  <felixblanke@gmail.com>, linux-btrfs@vger.kernel.org
> 
> On Mon, Jan 24, 2011 at 05:52:58PM +0100, Felix Blanke wrote:
> > util-linux-2.18-r1 and still no symlink following.
> > 
> > I'll ask for that at the kernel mailing list in the next days. If your (Hugo)
> > util-linux doesn't include any kind of patches that behaviour is really strange.
> 
>    Just for reference:
> 
> Package description page:
> http://packages.debian.org/squeeze/util-linux
> 
> Original upstream sources Debian are using:
> http://ftp.de.debian.org/debian/pool/main/u/util-linux/util-linux_2.17.2.orig.tar.gz
> 
> Debian patches on top of that source (mostly to the build system):
> http://ftp.de.debian.org/debian/pool/main/u/util-linux/util-linux_2.17.2-5.diff.gz
> 
>    Hugo.
> 
> > 
> > Felix
> > 
> > On 24. January 2011 - 15:44, Felix Blanke wrote:
> > > Date: Mon, 24 Jan 2011 15:44:14 +0100
> > > From: Felix Blanke <felixblanke@gmail.com>
> > > To: Hugo Mills <hugo-lkml@carfax.org.uk>
> > > Cc: kreijack@inwind.it, linux-btrfs@vger.kernel.org
> > > Subject: Re: Bug in mkfs.btrfs?!
> > > 
> > > > On Mon, Jan 24, 2011 at 02:29:36PM +0000, Hugo Mills wrote:
> > > > >    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.
> > > > 
> > > >    Hmm... Just had a thought: is
> > > > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 on
> > > > your system a symlink or a device node? What does ls -l say?
> > > 
> > > It is a symlink created by udev:
> > > 
> > > ls -l /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 
> > > lrwxrwxrwx 1 root root 10 Jan 23 23:39
> > > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 -> ../../sdb3
> > > 
> > > Following that link should work :)
> > > 
> > > 
> > > 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
>     --- Turning,  pages turning in the widening bath, / The spine ---    
>         cannot bear the humidity. / Books fall apart; the binding        
>             cannot hold. / Page 129 is loosed upon the world.            


---end quoted text---

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

If gentoo is configured for using loop-aes, a patch is applied:

http://loop-aes.sourceforge.net/updates/util-linux-ng-2.17.1-20100308.diff.bz2

Debian doesn't seem to apply that patch, therefore I'm getting that ioctl error and
can't loop my encrypted devices.

Now everything does make sense :) The difference is somewhere in that patch. It's a
huge one. Maybe I'll talk to the loop-aes maintainer (I'm subscribed to that list)
and try to deep into that.

It is def. not a btrfs related problem. If anyone wants to keep on track with my
investigation just let me now, otherwise I'll stop posting about this in the
btrfs-list.


Thanks for your help!


Felix


On 24. January 2011 - 22:04, Felix Blanke wrote:
> Date: Mon, 24 Jan 2011 22:04:54 +0100
> From: Felix Blanke <felixblanke@gmail.com>
> To: Hugo Mills <hugo-lkml@carfax.org.uk>
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Bug in mkfs.btrfs?!
> 
> Hi,
> 
> it is getting interesting :)
> 
> 
> If I'm using the debian util-linux (with the patches) I'm getting an error while
> executing losetup:
> 
> ioctl: LOOP_SET_STATUS: Invalid argument
> 
> 
> Now the interesting part: The strace of the debian util-linux shows:
> 
> readlink("/dev", 0x7fffcea2a0a0, 4096)  = -1 EINVAL (Invalid argument)
> readlink("/dev/disk", 0x7fffcea2a0a0, 4096) = -1 EINVAL (Invalid argument)
> readlink("/dev/disk/by-id", 0x7fffcea2a0a0, 4096) = -1 EINVAL (Invalid argument)
> readlink("/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3",
> "../../sda3", 4096) = 10
> readlink("/dev/sda3", 0x7fffcea2a0a0, 4096) = -1 EINVAL (Invalid argument)
> 
> 
> But in the gentoo util-linux there is no readlink in the strace. There are also those
> readlinks with the unpatched source from that debian package.
> 
> If I use the tarball of gentoo and compile it by my own there are readlinks. I'll
> take a look if there are any gentoo-patches applied during the build.
> 
> Felix
> 
> On 24. January 2011 - 17:00, Hugo Mills wrote:
> > Date: Mon, 24 Jan 2011 17:00:24 +0000
> > From: Hugo Mills <hugo-lkml@carfax.org.uk>
> > To: Felix Blanke <felixblanke@gmail.com>
> > Cc: linux-btrfs@vger.kernel.org
> > Subject: Re: Bug in mkfs.btrfs?!
> > Mail-Followup-To: Hugo Mills <hugo-lkml@carfax.org.uk>, Felix Blanke
> >  <felixblanke@gmail.com>, linux-btrfs@vger.kernel.org
> > 
> > On Mon, Jan 24, 2011 at 05:52:58PM +0100, Felix Blanke wrote:
> > > util-linux-2.18-r1 and still no symlink following.
> > > 
> > > I'll ask for that at the kernel mailing list in the next days. If your (Hugo)
> > > util-linux doesn't include any kind of patches that behaviour is really strange.
> > 
> >    Just for reference:
> > 
> > Package description page:
> > http://packages.debian.org/squeeze/util-linux
> > 
> > Original upstream sources Debian are using:
> > http://ftp.de.debian.org/debian/pool/main/u/util-linux/util-linux_2.17.2.orig.tar.gz
> > 
> > Debian patches on top of that source (mostly to the build system):
> > http://ftp.de.debian.org/debian/pool/main/u/util-linux/util-linux_2.17.2-5.diff.gz
> > 
> >    Hugo.
> > 
> > > 
> > > Felix
> > > 
> > > On 24. January 2011 - 15:44, Felix Blanke wrote:
> > > > Date: Mon, 24 Jan 2011 15:44:14 +0100
> > > > From: Felix Blanke <felixblanke@gmail.com>
> > > > To: Hugo Mills <hugo-lkml@carfax.org.uk>
> > > > Cc: kreijack@inwind.it, linux-btrfs@vger.kernel.org
> > > > Subject: Re: Bug in mkfs.btrfs?!
> > > > 
> > > > > On Mon, Jan 24, 2011 at 02:29:36PM +0000, Hugo Mills wrote:
> > > > > >    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.
> > > > > 
> > > > >    Hmm... Just had a thought: is
> > > > > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 on
> > > > > your system a symlink or a device node? What does ls -l say?
> > > > 
> > > > It is a symlink created by udev:
> > > > 
> > > > ls -l /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 
> > > > lrwxrwxrwx 1 root root 10 Jan 23 23:39
> > > > /dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-part3 -> ../../sdb3
> > > > 
> > > > Following that link should work :)
> > > > 
> > > > 
> > > > 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
> >     --- Turning,  pages turning in the widening bath, / The spine ---    
> >         cannot bear the humidity. / Books fall apart; the binding        
> >             cannot hold. / Page 129 is loosed upon the world.            
> 
> 
> ---end quoted text---
---end quoted text---

Re: Bug in mkfs.btrfs?!

[Felix Blanke]

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

LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Chris Samuel]

/*
 * CC'd to linux-kernel in case they have any feedback on this.
 *
 * Long thread, trying to work out why mkfs.btrfs failed to
 * make a filesystem on an encrypted loopback mount called
 * /dev/loop2. Cause turned out to be mkfs.btrfs calling
 * LOOP_GET_STATUS to find out if the block device was mounted
 * and getting a truncated device name back and so it later
 * fails when lstat() is called on the truncated device path.
 *
 * The long device name for the encrypted loopback mount was
 * because /dev/disk/by-id/$ID was used when Felix created it
 * to cope with devices moving around.
 */

On 25/01/11 00:01, Felix Blanke wrote:

> 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 in the kernel, and there is both LOOP_GET_STATUS (old
implementation) and LOOP_GET_STATUS64 (new implementation).

They return structures called loop_info and loop_info64
respectively and both are defined in include/linux/loop.h .

Sadly in both cases the lengths of paths are defined to be
LO_NAME_SIZE which is currently 64 and hence either
implementation will cause the problematic:

lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)

I've CC'd this to the LKML in case they have any feedback on
this apparent problem with the API.

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Petr Uzel]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote:
> /*
>  * CC'd to linux-kernel in case they have any feedback on this.
>  *
>  * Long thread, trying to work out why mkfs.btrfs failed to
>  * make a filesystem on an encrypted loopback mount called
>  * /dev/loop2. Cause turned out to be mkfs.btrfs calling
>  * LOOP_GET_STATUS to find out if the block device was mounted
>  * and getting a truncated device name back and so it later
>  * fails when lstat() is called on the truncated device path.
>  *
>  * The long device name for the encrypted loopback mount was
>  * because /dev/disk/by-id/$ID was used when Felix created it
>  * to cope with devices moving around.
>  */
> 
> On 25/01/11 00:01, Felix Blanke wrote:
> 
> > 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 in the kernel, and there is both LOOP_GET_STATUS (old
> implementation) and LOOP_GET_STATUS64 (new implementation).
> 
> They return structures called loop_info and loop_info64
> respectively and both are defined in include/linux/loop.h .
> 
> Sadly in both cases the lengths of paths are defined to be
> LO_NAME_SIZE which is currently 64 and hence either
> implementation will cause the problematic:
> 
> lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
> 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
> 
> I've CC'd this to the LKML in case they have any feedback on
> this apparent problem with the API.
 
Since 2.6.37, you can get full path to the backing file from sys:
cat /sys/block/loopX/loop/backing_file

See
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-07/msg10996.html


HTH,

Petr

--
Petr Uzel
IRC: ptr_uzl @ freenode

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Felix Blanke]

Hi,

are you sure that patch is in the kernel?

I'm using 2.6.37 and don't have those attribues in my /sys.



Felix

On 10. February 2011 - 13:29, Petr Uzel wrote:
> Date: Thu, 10 Feb 2011 13:29:27 +0100
> From: Petr Uzel <petr.uzel@suse.cz>
> To: Chris Samuel <chris@csamuel.org>
> Cc: Felix Blanke <felixblanke@gmail.com>, kreijack@inwind.it, Hugo Mills
>  <hugo-lkml@carfax.org.uk>, linux-btrfs@vger.kernel.org, Linux Kernel
>  <linux-kernel@vger.kernel.org>
> Subject: Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re:
>  Bug in mkfs.btrfs?!)
> Mail-Followup-To: Chris Samuel <chris@csamuel.org>, Felix Blanke
>  <felixblanke@gmail.com>, kreijack@inwind.it, Hugo Mills
>  <hugo-lkml@carfax.org.uk>, linux-btrfs@vger.kernel.org, Linux Kernel
>  <linux-kernel@vger.kernel.org>
> 
> On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote:
> > /*
> >  * CC'd to linux-kernel in case they have any feedback on this.
> >  *
> >  * Long thread, trying to work out why mkfs.btrfs failed to
> >  * make a filesystem on an encrypted loopback mount called
> >  * /dev/loop2. Cause turned out to be mkfs.btrfs calling
> >  * LOOP_GET_STATUS to find out if the block device was mounted
> >  * and getting a truncated device name back and so it later
> >  * fails when lstat() is called on the truncated device path.
> >  *
> >  * The long device name for the encrypted loopback mount was
> >  * because /dev/disk/by-id/$ID was used when Felix created it
> >  * to cope with devices moving around.
> >  */
> > 
> > On 25/01/11 00:01, Felix Blanke wrote:
> > 
> > > 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 in the kernel, and there is both LOOP_GET_STATUS (old
> > implementation) and LOOP_GET_STATUS64 (new implementation).
> > 
> > They return structures called loop_info and loop_info64
> > respectively and both are defined in include/linux/loop.h .
> > 
> > Sadly in both cases the lengths of paths are defined to be
> > LO_NAME_SIZE which is currently 64 and hence either
> > implementation will cause the problematic:
> > 
> > lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
> > 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
> > 
> > I've CC'd this to the LKML in case they have any feedback on
> > this apparent problem with the API.
>  
> Since 2.6.37, you can get full path to the backing file from sys:
> cat /sys/block/loopX/loop/backing_file
> 
> See
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-07/msg10996.html
> 
> 
> HTH,
> 
> Petr
> 
> --
> Petr Uzel
> IRC: ptr_uzl @ freenode


---end quoted text---

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Felix Blanke]

Hi,

are you sure that patch is in the kernel?

I'm using 2.6.37 and don't have those attribues in my /sys.



Felix

On 10. February 2011 - 13:29, Petr Uzel wrote:
> Date: Thu, 10 Feb 2011 13:29:27 +0100
> From: Petr Uzel <petr.uzel@suse.cz>
> To: Chris Samuel <chris@csamuel.org>
> Cc: Felix Blanke <felixblanke@gmail.com>, kreijack@inwind.it, Hugo Mills
>  <hugo-lkml@carfax.org.uk>, linux-btrfs@vger.kernel.org, Linux Kernel
>  <linux-kernel@vger.kernel.org>
> Subject: Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re:
>  Bug in mkfs.btrfs?!)
> Mail-Followup-To: Chris Samuel <chris@csamuel.org>, Felix Blanke
>  <felixblanke@gmail.com>, kreijack@inwind.it, Hugo Mills
>  <hugo-lkml@carfax.org.uk>, linux-btrfs@vger.kernel.org, Linux Kernel
>  <linux-kernel@vger.kernel.org>
> 
> On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote:
> > /*
> >  * CC'd to linux-kernel in case they have any feedback on this.
> >  *
> >  * Long thread, trying to work out why mkfs.btrfs failed to
> >  * make a filesystem on an encrypted loopback mount called
> >  * /dev/loop2. Cause turned out to be mkfs.btrfs calling
> >  * LOOP_GET_STATUS to find out if the block device was mounted
> >  * and getting a truncated device name back and so it later
> >  * fails when lstat() is called on the truncated device path.
> >  *
> >  * The long device name for the encrypted loopback mount was
> >  * because /dev/disk/by-id/$ID was used when Felix created it
> >  * to cope with devices moving around.
> >  */
> > 
> > On 25/01/11 00:01, Felix Blanke wrote:
> > 
> > > 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 in the kernel, and there is both LOOP_GET_STATUS (old
> > implementation) and LOOP_GET_STATUS64 (new implementation).
> > 
> > They return structures called loop_info and loop_info64
> > respectively and both are defined in include/linux/loop.h .
> > 
> > Sadly in both cases the lengths of paths are defined to be
> > LO_NAME_SIZE which is currently 64 and hence either
> > implementation will cause the problematic:
> > 
> > lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
> > 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
> > 
> > I've CC'd this to the LKML in case they have any feedback on
> > this apparent problem with the API.
>  
> Since 2.6.37, you can get full path to the backing file from sys:
> cat /sys/block/loopX/loop/backing_file
> 
> See
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-07/msg10996.html
> 
> 
> HTH,
> 
> Petr
> 
> --
> Petr Uzel
> IRC: ptr_uzl @ freenode


---end quoted text---

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Milan Broz]

On 02/11/2011 02:04 PM, Felix Blanke wrote:
> I'm using 2.6.37 and don't have those attribues in my /sys.

These attributes are there only when the loop device is configured,
IOW when backing file is attached.


Milan

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Milan Broz]

On 02/11/2011 08:23 PM, Felix Blanke wrote:
> What do you mean with "configured"?
> 
> I'm using loop devices with loop aes, and I've looked into /sys for a device which is actually in use.

Ehm. It is really Loop-AES?

Then ask author to backport it there, Loop-AES is not mainline code.
He usually replaces the whole upstream loop implementation with old patched version.

Milan

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Felix Blanke]

Yeah, for me its loop-aes.
Ah ok, didn't knew that it replaces that whole loop thing :)


Felix

On Feb 11, 2011 8:32 PM, "Milan Broz" <mbroz@redhat.com> wrote:
> On 02/11/2011 08:23 PM, Felix Blanke wrote:
>> What do you mean with "configured"?
>>
>> I'm using loop devices with loop aes, and I've looked into /sys for a device which is actually in use.
>
> Ehm. It is really Loop-AES?
>
> Then ask author to backport it there, Loop-AES is not mainline code.
> He usually replaces the whole upstream loop implementation with old patched version.
>
> Milan

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

[Felix Blanke]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

Hi,

attached is the answer from Jari Ruusu, (one of?!) the main developer of loop-aes. It
seems that checking if a loop device is mounted following the link isn't the best
idea :)

I'll have time to look deeper into his example about the 14.02. I'll then try to fix
that issue in mkfs.btrfs. If someone wants to fix it earlier, do it :) 



Regards,
Felix

[-- Attachment #2: Type: message/rfc822, Size: 5495 bytes --]

From: Jari Ruusu <jariruusu@users.sourceforge.net>
To: Felix Blanke <felixblanke@gmail.com>
Cc: linux-crypto@kernelnewbies.org
Subject: Re: Problem with losetup
Date: Wed, 26 Jan 2011 14:39:42 +0200
Message-ID: <4D40160E.605750DF@users.sourceforge.net>

First of all, I am not subscribed to linux-crypto@kernelnewbies.org mailing
list. But I do check web archive occasionally, at least for now. If you want
loop-AES maintainer to see your posts, please CC my @users.sourceforge.net
address, or linux-crypto@vger.kernel.org

Felix Blanke wrote:
> If I'm using the unpatched losetup (from util-linux-ng) and looping a
> device like
> 
> /dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3
> 
> it is using readlink to track down the link to e.g. /dev/sda3. But if
> I'm using the patched losetup I don't see any readlink in the strace.
> Because no readlink is used there is a problem with device names which
> have more then 64 characters (the field "lo_name" is an array of 64
> char). It is truncated like
> 
> /dev/loop0: [0010]:6229
> (/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par)
> encryption=AES128
> 
> That does make trouble with e.g. btrfs, because mkfs.btrfs uses the
> devicename provided by losetup to check if a device is mounted. That
> can't work with an incomplete devicename.

mkfs.btrfs authors goofed. Using truncated name is doomed to fail. Correct
way to check that is to compare loop backing file inode and device numbers
to inode and device numbers of supected file. Here is sample losetup output:

/dev/loop6: [0902]:209029 (/dev/md3) offset=4096 encryption=AES128 multi-key-v3
             ^^^^  ^^^^^^
          device     inode

Device number (0902) is hexadecimal. Inode number (209029) is decimal
number. /dev/md3 block special device node is present at mounted file system
on device 0x0902. Anything that symlinks or hardlinks to that inode 209029
on device 0x0902, is same file or device.
    
Even if losetup were to follow symlinks for that backing file name, symlink
destination would not necessarily be shorter. Although in your case it would
be shorter. Also, old versions of cryptoloop do not store the backing file
name at all. They use that same space for cipher algorithm name.

Below is source code for correct way for mkfs.btrfs to test loop backing
file status. Feel free to forward it to mkfs.btrfs authors.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD



/* loop-backing-dev-check.c / (c) 2011 Jari Ruusu / GNU GPL */

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <linux/loop.h>

int loop_backing_dev_check(char *loopdev, char *suspect)
{
    int fd, ret = 0;
    struct stat statbuf;
    struct loop_info64 info64;
    struct loop_info info;

    if(!loopdev || !*loopdev || !suspect || !*suspect) goto outret0;
    if(stat(loopdev, &statbuf) || !S_ISBLK(statbuf.st_mode)) goto outret0;
    if((statbuf.st_rdev & 0xfff00) != 0x700) goto outret0;
    if(stat(suspect, &statbuf)) goto outret0;
    if((fd = open(loopdev, O_RDONLY)) < 0) goto outret0;
    if(!ioctl(fd, LOOP_GET_STATUS64, &info64)) {
	if(statbuf.st_dev != info64.lo_device) goto closeret0;
	if(statbuf.st_ino != info64.lo_inode) goto closeret0;
	ret = 1;   /* loop backing device/file is same as suspect */
    } else if(!ioctl(fd, LOOP_GET_STATUS, &info)) {
	if(statbuf.st_dev != info.lo_device) goto closeret0;
	if(statbuf.st_ino != info.lo_inode) goto closeret0;
	ret = 1;   /* loop backing device/file is same as suspect */
    }
 closeret0:
    close(fd);
 outret0:
    return ret;
}

/* usage: ./loop-backing-dev-check /dev/loop0 /dev/fd0 */
int main(int argc, char **argv)
{
    if(argc != 3) exit(1);
    if(loop_backing_dev_check(argv[1], argv[2])) {
        printf("loop device %s is associated with %s\n", argv[1], argv[2]);
        exit(0);
    }
    exit(1);
}