Bug in mkfs.btrfs?!

DISCUSSION Felix Blanke 9 participants 33 messages Jan 22, 2011 – Feb 11, 2011 1 message not in the archive Btrfs file system

lore

Share & tools

lore

Felix Blanke

author

2011-01-22 14:45 UTC #0 lore raw

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

Felix Blanke

author

2011-01-22 14:52 UTC #1 lore raw

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

Quoted 20 lines · Felix Blanke

Date: Sat, 22 Jan 2011 15:45:13 +0100
From: Felix Blanke <[email protected]>
To: [email protected]
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)

Quoted 9 lines

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

2011-01-22 15:11 UTC #2 lore raw

Quoted 5 lines · 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.

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.

Quoted 34 lines

Regards,
Felix
Quoted 20 lines · Felix Blanke
Date: Sat, 22 Jan 2011 15:45:13 +0100
From: Felix Blanke <[email protected]>
To: [email protected]
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)
Quoted 9 lines
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---

Signature · 3 lines

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

Hugo Mills

2011-01-22 15:45 UTC #3 lore raw

Quoted 11 lines · Hugo Mills

Quoted 5 lines · 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.
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.

Signature · 3 lines

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

Felix Blanke

author

2011-01-22 15:56 UTC #4 lore raw

In reply to Hugo Mills

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

Quoted 50 lines · Hugo Mills

Date: Sat, 22 Jan 2011 15:11:24 +0000
From: Hugo Mills <[email protected]>
To: Felix Blanke <[email protected]>
Cc: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>, [email protected]
Quoted 5 lines · 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.
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.
Quoted 28 lines
Regards,
Felix
Quoted 24 lines · Felix Blanke
Date: Sat, 22 Jan 2011 15:45:13 +0100
From: Felix Blanke <[email protected]>
To: [email protected]
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.

Quoted 11 lines

Quoted 6 lines
Quoted 5 lines
I'll try the patch with the --foce option.
Regards,
Felix
---end quoted text---
Signature · 3 lines
=== 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---

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) = ?

Chris Samuel

2011-01-22 22:54 UTC #5 lore raw

Quoted 9 lines · Felix Blanke

It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2

Quoted 6 lines

/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

Signature · 2 lines

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

Felix Blanke

author

2011-01-22 23:03 UTC #6 lore raw

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.

Quoted 1 line

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

Quoted 25 lines · Chris Samuel

Date: Sun, 23 Jan 2011 09:54:34 +1100
From: Chris Samuel <[email protected]>
To: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 9 lines · Felix Blanke
It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2
Quoted 6 lines
/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

Quoted 14 lines

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
Signature · 7 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---end quoted text---

Hugo Mills

2011-01-23 18:18 UTC #7 lore raw

In reply to Felix Blanke

Hi, Felix,

Quoted 9 lines · Felix Blanke

It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2

Quoted 8 lines

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

mkfs.c +1 -0

index 2e99b95..51a5096 100644
@@ -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);

utils.c +12 -0

index fd894f3..7fa3149 100644
@@ -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)

volumes.c +3 -0

index 7671855..2496fbd 100644
@@ -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:

Signature · 3 lines

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

Goffredo Baroncelli

2011-01-23 22:02 UTC #8 lore raw

Quoted 18 lines · Hugo Mills

Hi, Felix,
Quoted 15 lines · Felix Blanke
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

Quoted 6 lines

Quoted 2 lines
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

Quoted 95 lines

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.

mkfs.c +1 -0

index 2e99b95..51a5096 100644
@@ -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);

utils.c +12 -0

index fd894f3..7fa3149 100644
@@ -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)

volumes.c +3 -0

index 7671855..2496fbd 100644
@@ -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:

Felix Blanke

author

2011-01-23 23:15 UTC #9 lore raw

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

Quoted 149 lines · Goffredo Baroncelli

Date: Sun, 23 Jan 2011 23:02:16 +0100
From: Goffredo Baroncelli <[email protected]>
To: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>
CC: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 18 lines · Hugo Mills
Hi, Felix,
Quoted 15 lines · Felix Blanke
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
Quoted 6 lines
Quoted 2 lines
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
Quoted 89 lines
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.
mkfs.c +1 -0
index 2e99b95..51a5096 100644
@@ -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);
utils.c +12 -0
index fd894f3..7fa3149 100644
@@ -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)
volumes.c +2 -0
index 7671855..2496fbd 100644
@@ -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);
 

Quoted 7 lines

volumes.c int btrfs_scan_one_device(int fd, const char *path, · line 231
Quoted 6 lines
volumes.c +1 -0
+	printf("Adding device %s to list\n", path);
 	ret = device_list_add(path, disk_super, devid, fs_devices_ret);
 
 error_brelse:

---end quoted text---

Helmut Hullen

2011-01-24 07:42 UTC #10 lore raw

Hallo, Felix,

Du meintest am 24.01.11:

Quoted 4 lines

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

Felix Blanke

author

2011-01-24 09:41 UTC #11 lore raw

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

Quoted 14 lines · Helmut Hullen

Date: 24 Jan 2011 08:42:00 +0100
From: Helmut Hullen <[email protected]>
To: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Hallo, Felix,
Du meintest am 24.01.11:
Quoted 4 lines
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.

Quoted 8 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

---end quoted text---

Hugo Mills

2011-01-23 23:27 UTC #12 lore raw

In reply to Goffredo Baroncelli

Quoted 26 lines · Goffredo Baroncelli

Quoted 18 lines · Hugo Mills
Hi, Felix,
Quoted 15 lines · Felix Blanke
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
Quoted 6 lines
Quoted 2 lines
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.

Quoted 7 lines

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

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.

Signature · 3 lines

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

Felix Blanke

author

2011-01-23 23:58 UTC #13 lore raw

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

Quoted 59 lines · Hugo Mills

Date: Sun, 23 Jan 2011 23:27:20 +0000
From: Hugo Mills <[email protected]>
To: [email protected]
Cc: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>, [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills <[email protected]>, [email protected], Hugo
Mills <[email protected]>, Felix Blanke <[email protected]>, [email protected]
Quoted 26 lines · Goffredo Baroncelli
Quoted 18 lines · Hugo Mills
Hi, Felix,
Quoted 15 lines · Felix Blanke
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
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
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 13 lines

Quoted 6 lines
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.
Signature · 3 lines
=== 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---

Fajar A. Nugraha

2011-01-24 01:53 UTC #14 lore raw

On Mon, Jan 24, 2011 at 6:58 AM, Felix Blanke <[email protected]> w= rote:

Quoted 1 line

I tried the newest version 2.19-rc1. There seems to be some kind of "=

fix":

Quoted 4 lines

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

Quoted 3 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Felix Blanke

author

2011-01-24 09:38 UTC #15 lore raw

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

Quoted 7 lines · Fajar A. Nugraha

Date: Mon, 24 Jan 2011 08:53:41 +0700
From: "Fajar A. Nugraha" <[email protected]>
To: Felix Blanke <[email protected]>
Cc: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
=20
On Mon, Jan 24, 2011 at 6:58 AM, Felix Blanke <[email protected]>=

Quoted 1 line · wrote:

Quoted 1 line
I tried the newest version 2.19-rc1. There seems to be some kind of=

"fix":

Quoted 4 lines

Quoted 4 lines
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

Quoted 3 lines

Quoted 1 line
16)
=20
Quoted 1 line
If the path is to long they add a '*' :) Do you think that will sol=

ve the problem?

Quoted 8 lines

=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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Felix Blanke

author

2011-01-24 13:01 UTC #16 lore raw

In reply to Goffredo Baroncelli

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

Quoted 149 lines · Goffredo Baroncelli

Date: Sun, 23 Jan 2011 23:02:16 +0100
From: Goffredo Baroncelli <[email protected]>
To: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>
CC: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 18 lines · Hugo Mills
Hi, Felix,
Quoted 15 lines · Felix Blanke
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
Quoted 6 lines
Quoted 2 lines
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
Quoted 89 lines
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.
mkfs.c +1 -0
index 2e99b95..51a5096 100644
@@ -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);
utils.c +12 -0
index fd894f3..7fa3149 100644
@@ -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)
volumes.c +2 -0
index 7671855..2496fbd 100644
@@ -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);
 

Quoted 7 lines

volumes.c int btrfs_scan_one_device(int fd, const char *path, · line 231
Quoted 6 lines
volumes.c +1 -0
+	printf("Adding device %s to list\n", path);
 	ret = device_list_add(path, disk_super, devid, fs_devices_ret);
 
 error_brelse:

---end quoted text---

Hugo Mills

2011-01-24 13:13 UTC #17 lore raw

Quoted 4 lines · 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?

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.

Quoted 1 line

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

linux-kernel mailing list, I think.

Quoted 3 lines

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.

Signature · 3 lines

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

Felix Blanke

author

2011-01-24 13:53 UTC #18 lore raw

Quoted 12 lines · Hugo Mills

Date: Mon, 24 Jan 2011 13:13:41 +0000
From: Hugo Mills <[email protected]>
To: Felix Blanke <[email protected]>
Cc: [email protected], Hugo Mills <[email protected]>,
[email protected]
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>, [email protected], [email protected]
Quoted 2 lines · Felix Blanke
Hi,

Quoted 9 lines

Quoted 2 lines
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 :/

Quoted 10 lines

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

Quoted 7 lines

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

Quoted 7 lines

Hugo.

Signature · 3 lines

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

Hugo Mills

2011-01-24 14:29 UTC #19 lore raw

Quoted 7 lines · Felix Blanke

Quoted 6 lines · Hugo Mills
Quoted 4 lines · 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?

Quoted 8 lines

Quoted 6 lines
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.

Quoted 11 lines

Quoted 11 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 2 lines
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.

Signature · 5 lines

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

Hugo Mills

2011-01-24 14:34 UTC #20 lore raw

Quoted 7 lines · Hugo Mills

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.

Signature · 5 lines

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

Felix Blanke

author

2011-01-24 14:44 UTC #21 lore raw

Quoted 9 lines · Hugo Mills

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

Quoted 3 lines

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

Quoted 9 lines

Hugo.

Signature · 5 lines

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

Felix Blanke

author

2011-01-24 16:52 UTC #22 lore raw

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

Quoted 41 lines · Felix Blanke

Date: Mon, 24 Jan 2011 15:44:14 +0100
From: Felix Blanke <[email protected]>
To: Hugo Mills <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 9 lines · Hugo Mills
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 9 lines
Hugo.
Signature · 5 lines
=== 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.                      

Quoted 1 line

---end quoted text---

---end quoted text---

Hugo Mills

2011-01-24 17:00 UTC #23 lore raw

Quoted 4 lines · 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.

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.

Quoted 37 lines

Felix
Quoted 33 lines · Felix Blanke
Date: Mon, 24 Jan 2011 15:44:14 +0100
From: Felix Blanke <[email protected]>
To: Hugo Mills <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 9 lines · Hugo Mills
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 3 lines
Hugo.

Signature · 5 lines

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

Felix Blanke

author

2011-01-24 21:04 UTC #24 lore raw

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

Quoted 56 lines · Hugo Mills

Date: Mon, 24 Jan 2011 17:00:24 +0000
From: Hugo Mills <[email protected]>
To: Felix Blanke <[email protected]>
Cc: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>, [email protected]
Quoted 4 lines · 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.
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.
Quoted 29 lines
Felix
Quoted 25 lines · Felix Blanke
Date: Mon, 24 Jan 2011 15:44:14 +0100
From: Felix Blanke <[email protected]>
To: Hugo Mills <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 9 lines · Hugo Mills
Quoted 7 lines
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.
Quoted 3 lines
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

Quoted 15 lines

Quoted 8 lines

Quoted 8 lines
Following that link should work :)
Felix
Quoted 3 lines
Hugo.

Signature · 5 lines

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

Felix Blanke

author

2011-01-24 21:14 UTC #25 lore raw

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

Quoted 109 lines · Felix Blanke

Date: Mon, 24 Jan 2011 22:04:54 +0100
From: Felix Blanke <[email protected]>
To: Hugo Mills <[email protected]>
Cc: [email protected]
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
Quoted 56 lines · Hugo Mills
Date: Mon, 24 Jan 2011 17:00:24 +0000
From: Hugo Mills <[email protected]>
To: Felix Blanke <[email protected]>
Cc: [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Mail-Followup-To: Hugo Mills <[email protected]>, Felix Blanke
<[email protected]>, [email protected]
Quoted 4 lines · 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.
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.
Quoted 29 lines
Felix
Quoted 25 lines · Felix Blanke
Date: Mon, 24 Jan 2011 15:44:14 +0100
From: Felix Blanke <[email protected]>
To: Hugo Mills <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Bug in mkfs.btrfs?!
Quoted 9 lines · Hugo Mills
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 15 lines
Quoted 8 lines
Quoted 8 lines
Following that link should work :)
Felix
Quoted 3 lines
Hugo.
Signature · 5 lines
=== 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.            

Quoted 1 line

---end quoted text---

---end quoted text---

Felix Blanke

author

2011-01-24 14:35 UTC #26 lore raw

In reply to Hugo Mills

Quoted 54 lines · Felix Blanke

Quoted 7 lines · Hugo Mills
Quoted 6 lines · Felix Blanke
Quoted 4 lines
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?
Quoted 8 lines
Quoted 6 lines
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.
Quoted 11 lines
Quoted 11 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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.

Quoted 8 lines

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

Quoted 8 lines

Hugo.

Signature · 5 lines

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

Chris Samuel

2011-01-25 00:15 UTC #27 lore raw

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

In reply to Felix Blanke

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

Quoted 3 lines · Felix Blanke

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

Signature · 1 line

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

Petr Uzel

2011-02-10 12:29 UTC #28 lore raw

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

Quoted 31 lines · 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.
*/
Quoted 3 lines · Felix Blanke
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:

Quoted 5 lines

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

Felix Blanke

author

2011-02-11 13:04 UTC #29 lore raw

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

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

Quoted 58 lines · Petr Uzel

Date: Thu, 10 Feb 2011 13:29:27 +0100
From: Petr Uzel <[email protected]>
To: Chris Samuel <[email protected]>
Cc: Felix Blanke <[email protected]>, [email protected], Hugo Mills
<[email protected]>, [email protected], Linux Kernel <[email protected]>
Subject: Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re:
Bug in mkfs.btrfs?!)
Mail-Followup-To: Chris Samuel <[email protected]>, Felix Blanke
<[email protected]>, [email protected], Hugo Mills <[email protected]>, [email protected], Linux Kernel <[email protected]>
Quoted 31 lines · 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.
*/
Quoted 3 lines · Felix Blanke
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:
Quoted 5 lines
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

Quoted 7 lines

HTH,
Petr
--
Petr Uzel
IRC: ptr_uzl @ freenode

---end quoted text---

Milan Broz

2011-02-11 18:59 UTC #30 lore raw

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

Quoted 1 line · Felix Blanke

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Milan Broz

2011-02-11 19:31 UTC #32 lore raw

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

Quoted 3 lines · Felix Blanke

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

Felix Blanke

author

2011-02-11 19:41 UTC #33 lore raw

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

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

Felix

Quoted 11 lines · Milan Broz

Quoted 3 lines · Felix Blanke
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