[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
It looks like this was fixed some time ago. ** Changed in: util-linux (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/313385 Title: losetup 32bit offset limit, hangs on retry, remains defunct To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/313385/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
So, I think the issue I've been having *may* be related. I store a bunch of junk on an LVM and I needed to expand that a bit. So I created a virtual disk using dd and losetup to expand my LVM. Everything seems fine, but after some case that I'm having a hard time identifying, I cease to be able to view certain parts of the file system on my LVM and my dmesg and /var/log/messages get flooded with stuff like [code] CIFS VFS: Unexpected lookup error -112 [/code] and [code] Mar 21 07:59:52 Dauntless kernel: [35010.428444] rmD 80234069 0 8160 21157 Mar 21 07:59:52 Dauntless kernel: [35010.428449] 88009783fe28 0086 88008aa606c8 806e2700 Mar 21 07:59:52 Dauntless kernel: [35010.428455] 807a6400 807a6400 807a6400 807a6400 Mar 21 07:59:52 Dauntless kernel: [35010.428460] 807a6400 807a6400 807a6400 807a6400 Mar 21 07:59:52 Dauntless kernel: [35010.428465] Call Trace: Mar 21 07:59:52 Dauntless kernel: [35010.428469] [802f5f1f] ? path_walk+0xcf/0xe0 Mar 21 07:59:52 Dauntless kernel: [35010.428473] [80502435] __mutex_lock_slowpath+0x85/0xd0 Mar 21 07:59:52 Dauntless kernel: [35010.428478] [805021d3] mutex_lock+0x23/0x30 Mar 21 07:59:52 Dauntless kernel: [35010.428481] [802f667f] do_unlinkat+0x8f/0x1d0 Mar 21 07:59:52 Dauntless kernel: [35010.428485] [802f8c13] ? do_vfs_ioctl+0x273/0x2f0 Mar 21 07:59:52 Dauntless kernel: [35010.428489] [802f6922] sys_unlinkat+0x22/0x40 Mar 21 07:59:52 Dauntless kernel: [35010.428493] [8021285a] system_call_fastpath+0x16/0x1b [/code] Also.. [code] Mar 19 22:03:34 Dauntless kernel: [ 2307.472136] smbd D 80234069 0 8729 8501 Mar 19 22:03:34 Dauntless kernel: [ 2307.472142] 88003f52dad8 0082 88003c9fde00 806e0710 Mar 19 22:03:34 Dauntless kernel: [ 2307.472149] 807a6400 807a6400 807a6400 807a6400 Mar 19 22:03:34 Dauntless kernel: [ 2307.472154] 807a6400 807a6400 807a6400 807a6400 Mar 19 22:03:34 Dauntless kernel: [ 2307.472159] Call Trace: Mar 19 22:03:34 Dauntless kernel: [ 2307.472170] [802ac615] ? __filemap_fdatawrite_range+0x55/0x70 Mar 19 22:03:34 Dauntless kernel: [ 2307.472177] [80502435] __mutex_lock_slowpath+0x85/0xd0 Mar 19 22:03:34 Dauntless kernel: [ 2307.472193] [a0d695f8] ? _FreeXid+0x28/0x30 [cifs] Mar 19 22:03:34 Dauntless kernel: [ 2307.472198] [805021d3] mutex_lock+0x23/0x30 Mar 19 22:03:34 Dauntless kernel: [ 2307.472202] [802f4b1e] real_lookup+0x3e/0x170 Mar 19 22:03:34 Dauntless kernel: [ 2307.472206] [802f4d00] do_lookup+0xb0/0x110 Mar 19 22:03:34 Dauntless kernel: [ 2307.472209] [802f536d] __link_path_walk+0x60d/0xc20 Mar 19 22:03:34 Dauntless kernel: [ 2307.472214] [802f5b6f] do_follow_link+0x1ef/0x320 Mar 19 22:03:34 Dauntless kernel: [ 2307.472217] [802f54ec] __link_path_walk+0x78c/0xc20 Mar 19 22:03:34 Dauntless kernel: [ 2307.47] [803061b6] ? mntput_no_expire+0x36/0x160 Mar 19 22:03:34 Dauntless kernel: [ 2307.472225] [802f5ebe] path_walk+0x6e/0xe0 Mar 19 22:03:34 Dauntless kernel: [ 2307.472229] [802f60d3] do_path_lookup+0xe3/0x200 Mar 19 22:03:34 Dauntless kernel: [ 2307.472232] [802f3ada] ? getname+0x4a/0xb0 Mar 19 22:03:34 Dauntless kernel: [ 2307.472236] [802f6f2b] user_path_at+0x7b/0xb0 Mar 19 22:03:34 Dauntless kernel: [ 2307.472239] [802fc603] ? vfs_lock_file+0x43/0x50 Mar 19 22:03:34 Dauntless kernel: [ 2307.472243] [802fbc23] ? locks_free_lock+0x43/0x60 Mar 19 22:03:34 Dauntless kernel: [ 2307.472247] [802ee0ed] vfs_stat_fd+0x2d/0x60 Mar 19 22:03:34 Dauntless kernel: [ 2307.472251] [802ee1cc] sys_newstat+0x2c/0x50 Mar 19 22:03:34 Dauntless kernel: [ 2307.472254] [802f8416] ? do_fcntl+0x36/0x290 Mar 19 22:03:34 Dauntless kernel: [ 2307.472259] [802eb3d9] ? fput+0x9/0x30 Mar 19 22:03:34 Dauntless kernel: [ 2307.472262] [802f86e0] ? sys_fcntl+0x70/0x90 Mar 19 22:03:34 Dauntless kernel: [ 2307.472267] [8021285a] system_call_fastpath+0x16/0x1b [/code] So, like I said, I'm not sure this is related.. But I think it may well be. Though losetup's involvement may be somewhat too obscure for this post to help much. -- losetup 32bit offset limit, hangs on retry, remains defunct https://bugs.launchpad.net/bugs/313385 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
Ohh yeah, and I'm on AMD64 8.10 -- losetup 32bit offset limit, hangs on retry, remains defunct https://bugs.launchpad.net/bugs/313385 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
your logs seem to indicate that there is a problem with samba (keywords cifs, smbd). how do you use samba in respect to the lvm device? i also don't really understand why you need to use a virtual disk to expand a LVM (but i probably won't be able to help you anyway..). what commands did you use? -- losetup 32bit offset limit, hangs on retry, remains defunct https://bugs.launchpad.net/bugs/313385 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
There are other keywords, like one of those backtraces comes out of an instance of rm. My LVM was full and I had another drive that was already doing something else. I used dd to make a file that I'm using an extra storage space on the LVM. losetup is what connects that file to the file system as a block device that the LVM can make use of. I think the error messages I've seen thus far (as provided above) are merely symptoms of this problem. But I can't honestly say I'm sure what is going on. Samba is involved at all in that there's a samba share over part of the LVM. -- losetup 32bit offset limit, hangs on retry, remains defunct https://bugs.launchpad.net/bugs/313385 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
** Summary changed:
- losetup 32bit offset limit, hang, remaining defunct
+ losetup 32bit offset limit, hangs on retry, remains defunct
** Description changed:
Binary package hint: util-linux
i made a dd image of my laptop drive and try to work with it (mount,
resizing etc).
# losetup -a
/dev/loop0: [fe01]:29253634 (/image.dd)
# fdisk -lu /dev/loop0
Disk /dev/loop0: 60.0 GB, 60011642880 bytes
240 heads, 63 sectors/track, 7752 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x46514650
Device Boot Start End Blocks Id System
/dev/loop0p1 * 63 8814959 4407448+ b W95 FAT32
/dev/loop0p2 8814960 11721023954197640f W95 Ext'd (LBA)
/dev/loop0p5 8815023 11721023954197608+ 7 HPFS/NTFS
the first partition is about 4,5GB, the rest is a logical partition.
i first tried to use http://vytautas.jakutis.lt/node/26 but that did not work
and i did not look into it, because i knew of the offset method as described
here http://www.fluidsignal.com/en/publications/knowledge/20080923090245 .
so... i tried to use the losetup -o option to create loop devices for the
partitions.
offset = start block * 512
offset p1 = 63 * 512 = 32256
= losetup -fo 32256 /dev/loop0
this worked ok (can't redo atm, see below)
offset p5 = 4513291776
this is 2^32.
if i try to use that offset, it seems to work ok the first time (it returns
instantly), but does not create a new loop device.
if you try it again, it hangs with consuming 100% cpu time of one core.
i straced it afterwards:
libc stuff, locale stuff
stat(/dev, {st_mode=S_IFDIR|0755, st_size=14560, ...}) = 0
stat(/dev/loop, 0x7fff3d71f7e0) = -1 ENOENT (No such file or
directory)
stat(/dev/loop0, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
open(/dev/loop0, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= 0
close(3)= 0
stat(/dev/loop1, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) = 0
open(/dev/loop1, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= -1 EOVERFLOW (Value too large for
defined data type)
close(3)= 0
open(/dev/loop0, O_RDWR) = 3
open(/dev/loop1, O_RDWR) = 4
readlink(/dev, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
readlink(/dev/loop0, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
ioctl(4, 0x4c00, 0x3) = -1 EBUSY (Device or resource busy)
close(4)= 0
close(3)= 0
here it loops:
stat(/dev, {st_mode=S_IFDIR|0755, st_size=14560, ...}) = 0
stat(/dev/loop, 0x7fff3d71f7e0) = -1 ENOENT (No such file or
directory)
stat(/dev/loop0, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
open(/dev/loop0, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= 0
close(3)= 0
stat(/dev/loop1, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) = 0
open(/dev/loop1, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= -1 EOVERFLOW (Value too large for
defined data type)
close(3)= 0
open(/dev/loop0, O_RDWR) = 3
open(/dev/loop1, O_RDWR) = 4
readlink(/dev, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
readlink(/dev/loop0, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
ioctl(4, 0x4c00, 0x3) = -1 EBUSY (Device or resource busy)
close(4)= 0
close(3)= 0
rinse repeat
i searched for help and found
http://www.linuxforums.org/forum/redhat-fedora-linux-help/111777-losetup-offset-there-limit-overflow.html
that indicates, that there was a bug and it was fixed before 2.13-pre7.
i use util-linux 2.14-1ubuntu2
but maybe its an amd64 bug, since im running 64bit ubuntu 8.10.
after trying a too big offset, it is broken until reboot:
i cant use a small offset.
i cant detach the whole disk image.
i cant rmmod loop.
- ill reboot now and strace the first run with a too big offset.
+ after reboot:
+ # ll
+ total 58662416
+ drwxr-xr-x 2 root root 4096 2009-01-03 05:27 d
+ -rwxr--r-- 1 ameno ameno 60011642880 2009-01-02 18:29 file.dd
+ # losetup -a
+ # losetup -f file.dd
+ # losetup -fo 32256 /dev/loop0
+ # losetup -a
+ /dev/loop0: [fe01]:29253634 (/platz/vbox/file.dd)
+ /dev/loop1: [000e]:6209 (/dev/loop0), offset 32256
+ # mount /dev/loop1 d
+ # ll d
+ total 410040
+ -rwxr-xr-x 1 root root150528 2005-09-09 01:28 arcldr.exe
+ -rwxr-xr-x 1 root root 170 2008-03-24 15:00 boot.ini
+ drwxr-xr-x 6 root root 4096 2005-09-09 01:33 Documents and Settings
+ -rwxr-xr-x 1 root root 0 2005-09-09 01:28 io.sys
+ -rwxr-xr-x 1 root root
[Bug 313385] Re: losetup 32bit offset limit, hangs on retry, remains defunct
** Description changed:
Binary package hint: util-linux
i made a dd image of my laptop drive and try to work with it (mount,
resizing etc).
# losetup -a
/dev/loop0: [fe01]:29253634 (/image.dd)
# fdisk -lu /dev/loop0
Disk /dev/loop0: 60.0 GB, 60011642880 bytes
240 heads, 63 sectors/track, 7752 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x46514650
Device Boot Start End Blocks Id System
/dev/loop0p1 * 63 8814959 4407448+ b W95 FAT32
/dev/loop0p2 8814960 11721023954197640f W95 Ext'd (LBA)
/dev/loop0p5 8815023 11721023954197608+ 7 HPFS/NTFS
the first partition is about 4,5GB, the rest is a logical partition.
i first tried to use http://vytautas.jakutis.lt/node/26 but that did not work
and i did not look into it, because i knew of the offset method as described
here http://www.fluidsignal.com/en/publications/knowledge/20080923090245 .
so... i tried to use the losetup -o option to create loop devices for the
partitions.
offset = start block * 512
offset p1 = 63 * 512 = 32256
= losetup -fo 32256 /dev/loop0
this worked ok (can't redo atm, see below)
offset p5 = 4513291776
this is 2^32.
if i try to use that offset, it seems to work ok the first time (it returns
instantly), but does not create a new loop device.
if you try it again, it hangs with consuming 100% cpu time of one core.
i straced it afterwards:
libc stuff, locale stuff
stat(/dev, {st_mode=S_IFDIR|0755, st_size=14560, ...}) = 0
stat(/dev/loop, 0x7fff3d71f7e0) = -1 ENOENT (No such file or
directory)
stat(/dev/loop0, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
open(/dev/loop0, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= 0
close(3)= 0
stat(/dev/loop1, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) = 0
open(/dev/loop1, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= -1 EOVERFLOW (Value too large for
defined data type)
close(3)= 0
open(/dev/loop0, O_RDWR) = 3
open(/dev/loop1, O_RDWR) = 4
readlink(/dev, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
readlink(/dev/loop0, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
ioctl(4, 0x4c00, 0x3) = -1 EBUSY (Device or resource busy)
close(4)= 0
close(3)= 0
here it loops:
stat(/dev, {st_mode=S_IFDIR|0755, st_size=14560, ...}) = 0
stat(/dev/loop, 0x7fff3d71f7e0) = -1 ENOENT (No such file or
directory)
stat(/dev/loop0, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
open(/dev/loop0, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= 0
close(3)= 0
stat(/dev/loop1, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) = 0
open(/dev/loop1, O_RDONLY)= 3
ioctl(3, 0x4c03, 0x7fff3d71f6f0)= -1 EOVERFLOW (Value too large for
defined data type)
close(3)= 0
open(/dev/loop0, O_RDWR) = 3
open(/dev/loop1, O_RDWR) = 4
readlink(/dev, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
readlink(/dev/loop0, 0x7fff3d71d620, 4096) = -1 EINVAL (Invalid argument)
ioctl(4, 0x4c00, 0x3) = -1 EBUSY (Device or resource busy)
close(4)= 0
close(3)= 0
rinse repeat
i searched for help and found
http://www.linuxforums.org/forum/redhat-fedora-linux-help/111777-losetup-offset-there-limit-overflow.html
that indicates, that there was a bug and it was fixed before 2.13-pre7.
i use util-linux 2.14-1ubuntu2
but maybe its an amd64 bug, since im running 64bit ubuntu 8.10.
after trying a too big offset, it is broken until reboot:
i cant use a small offset.
i cant detach the whole disk image.
i cant rmmod loop.
after reboot:
# ll
total 58662416
drwxr-xr-x 2 root root 4096 2009-01-03 05:27 d
-rwxr--r-- 1 ameno ameno 60011642880 2009-01-02 18:29 file.dd
# losetup -a
# losetup -f file.dd
# losetup -fo 32256 /dev/loop0
# losetup -a
/dev/loop0: [fe01]:29253634 (/platz/vbox/file.dd)
/dev/loop1: [000e]:6209 (/dev/loop0), offset 32256
# mount /dev/loop1 d
# ll d
total 410040
-rwxr-xr-x 1 root root150528 2005-09-09 01:28 arcldr.exe
-rwxr-xr-x 1 root root 170 2008-03-24 15:00 boot.ini
drwxr-xr-x 6 root root 4096 2005-09-09 01:33 Documents and Settings
-rwxr-xr-x 1 root root 0 2005-09-09 01:28 io.sys
-rwxr-xr-x 1 root root 0 2005-09-09 01:28 msdos.sys
-rwxr-xr-x 1 root root 34724 2005-09-09 01:28 ntdetect.com
-rwxr-xr-x 1 root root214432 2005-09-09 01:28 ntldr
-rwxr-xr-x 1 root root 419430400
