Hello,
Found just one report about that so I think you might be interested:
This is a mounted /usr that should grow after an according lvresize. Instead I
got:
# resize2fs -p /dev/vg_asdfg/usr
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg_asdfg/usr is mounted on /usr; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
resize2fs: Device or resource busy While checking for on-line resizing support
strace isn't helpful:
(...)
stat("/dev/mapper/vg_asdfg-home", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 7), ...}) = 0
stat("/dev/mapper/vg_asdfg-usr", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 9), ...}) = 0
stat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3) = 0
munmap(0x7f6ed9996000, 4096) = 0
stat("/dev/vg_asdfg/usr", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 9), ...}) = 0
open("/dev/vg_asdfg/usr", O_RDONLY|O_EXCL) = -1 EBUSY (Device or resource busy)
open("/dev/vg_asdfg/usr", O_RDWR) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 9), ...}) = 0
close(3) = 0
open("/dev/vg_asdfg/usr", O_RDONLY) = 3
lseek(3, 1024, SEEK_SET) = 1024
read(3, "\0\0\3\0\0\0\6\0\314L\0\0\333\215\1\0\2327\2\0\0\0\0\0\2\0\0\0\2\0\0\0"..., 1024) = 1024
lseek(3, 4096, SEEK_SET) = 4096
read(3, "a\0\0\0q\0\0\0\201\0\0\0\266=\0\0\364\20\4\0\0\0\0\0\0\0\0\0\0\0\32b"..., 4096) = 4096
open("/dev/vg_asdfg/usr", O_RDONLY) = 4
uname({sys="Linux", node="asdfg", ...}) = 0
ioctl(4, BLKGETSIZE64, 0x7fff6ccebcc8) = 0
close(4) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6ed9996000
write(1, "Filesystem at /dev/vg_asdfg/usr "..., 78) = 78
write(1, "old desc_blocks = 1, new_desc_bl"..., 41) = 41
open("/usr", O_RDONLY) = 4
ioctl(4, 0x40086607, 0x7fff6ccebcec) = -1 EBUSY (Device or resource busy)
write(2, "resize2fs", 9) = 9
write(2, ": ", 2) = 2
write(2, "Device or resource busy", 23) = 23
write(2, " ", 1) = 1
write(2, "While checking for on-line resiz"..., 43) = 43
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(2, "\n", 1) = 1
exit_group(1) = ?
Trying a more recent version of resize2fs [1.42-WIP (16-Oct-2011)] shows the
same message while in strace:
(...)
write(1, "old_desc_blocks = 1, new_desc_bl"..., 41) = 41
open("/usr", O_RDONLY) = 4
ioctl(4, 0x40086610, 0x7fffd39ac6a8) = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(4, 0x40086607, 0x7fffd39ac524) = -1 EBUSY (Device or resource busy)
(...)
The file system properties look completely harmless to me:
tune2fs 1.42-WIP (16-Oct-2011)
Filesystem volume name: usr
Last mounted on: /usr
Filesystem UUID: 9d6c2e6e-e704-4295-ab26-4fc0c5417ea9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 196608
Block count: 393216
Reserved block count: 19660
Free blocks: 101851
Free inodes: 145306
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 95
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 1024
Flex block group size: 16
Filesystem created: Sat Nov 12 21:15:54 2011
Last mount time: Sun Nov 13 14:35:23 2011
Last write time: Sat Nov 12 22:09:01 2011
Mount count: 5
Maximum mount count: 28
Last checked: Sat Nov 12 21:15:54 2011
Check interval: 15552000 (6 months)
Next check after: Thu May 10 22:15:54 2012
Lifetime writes: 1219 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 828e88f5-f06a-46de-922d-3091b6074eb6
Journal backup: inode blocks
Additional information:
* Kernel 3.1.1, Debian squeeze
* Next steps will be reboot, then offline e2fsck+resize2fs. Will take a while
as the space currently available is sufficient while this system should be
always up.
* A second file system created at the same time was resized successfully, so
this problem has other constraints.
* Perhaps lvm still has its finger on it, /usr was pvmove'd before. Although,
the second file system, too.
* Please s/W/w/
PBDaMz <a href="http://sczcafhukqrk.com/">sczcafhukqrk</a>, [url=http://ibhjqpsdkzsk.com/]ibhjqpsdkzsk[/url], [link=http://vmtzujxshqtd.com/]vmtzujxshqtd[/link], http://hlusiqdqyaeg.com/