Description of problem: I tried using fsadm to resize a fs that resides on a LV, but I get the following error: root@ubuntu:~# fsadm -n -v -l resize /dev/myvg/root shift: 397: can't shift that many If I specify newsize, I don't get the error. However, when I specify newsize, it still does not behave as I would expect: although I used the -n option, the LV was actually extended. Version-Release number of selected component (if applicable): I used both 2.02.56 and 2.02.57(1) (from CVS). How reproducible: root@ubuntu:~# fsadm -n -v -l resize /dev/myvg/root 799G fsadm: "ext3" filesystem found on "/dev/mapper/myvg-root" fsadm: Device "/dev/mapper/myvg-root" size is 785979015168 bytes fsadm: Parsing tune2fs -l "/dev/mapper/myvg-root" Finding volume group myvg Executing: fsadm --verbose check /dev/myvg/root fsadm: "ext3" filesystem found on "/dev/mapper/myvg-root" fsadm: Executing fsck /dev/mapper/myvg-root fsck from util-linux-ng 2.16 e2fsck 1.41.9 (22-Aug-2009) root: clean, 1048711/47972352 files, 181942908/191889408 blocks Archiving volume group "myvg" metadata (seqno 32). Extending logical volume root to 799,00 GiB Found volume group "myvg" Found volume group "myvg" Loading myvg-root table (252:1) Suspending myvg-root (252:1) with device flush Found volume group "myvg" Resuming myvg-root (252:1) Creating volume group backup "/etc/lvm/backup/myvg" (seqno 33). Logical volume root successfully resized Executing: fsadm --verbose resize /dev/myvg/root 837812224K fsadm: "ext3" filesystem found on "/dev/mapper/myvg-root" fsadm: Device "/dev/mapper/myvg-root" size is 857919717376 bytes fsadm: Parsing tune2fs -l "/dev/mapper/myvg-root" fsadm: Resizing filesystem on device "/dev/mapper/myvg-root" to 857919717376 bytes (191889408 -> 209453056 blocks of 4096 bytes) fsadm: Executing resize2fs /dev/mapper/myvg-root 209453056 resize2fs 1.41.9 (22-Aug-2009) Please run 'e2fsck -f /dev/mapper/myvg-root' first. fsadm: Resize ext3 failed fsadm failed: 1 The filesystem was not resized, but it probably would have been, if the error above would not show up. A minor nuisance is the fact that you must use an integer for the newsize value. Specifying a floating point number returns this: root@ubuntu:~# fsadm -n -v -l resize /dev/myvg/root 799.3G fsadm: "ext3" filesystem found on "/dev/mapper/myvg-root" fsadm: Device "/dev/mapper/myvg-root" size is 857919717376 bytes fsadm: Parsing tune2fs -l "/dev/mapper/myvg-root" /sbin/fsadm: 406: arithmetic expression: expecting EOF: " 799.3 * 1073741824 "
So several problems to deal with here: 1) integer arithmetic (use 'bc' instead perhaps?) 2) misbehaving -n 3) missing -l from man page 4) according to -h and man page, new_size is optional Any more?
I also noticed the need to run "e2fsck -f" before resizing the filesystem. I am unsure why this is necessary. When I do this manually, I just lvextend and then resize2fs (since ext3 supports this).
(In reply to comment #1) > So several problems to deal with here: > > 1) integer arithmetic (use 'bc' instead perhaps?) Yes - I've been already thinking about this - except it is introducing dependency on somewhat 'unrelated' bc packages. But many bash users are using 'bc' to handle float arithmetic. Do we want to add this dependency to lvm package ?
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Original subject of this bugzilla should be fixed with upstream commits to fsadm (--dry-run functionality) https://www.redhat.com/archives/lvm-devel/2010-October/msg00035.html And should be fixed within lvm2 packages >= 2.02.75 However we still do not support floating numbers through fsadm - so keeping this bugzilla still open.
Renamed bugzilla to reflect actual problem of fsadm.(In reply to comment #1) > So several problems to deal with here: > > 1) integer arithmetic (use 'bc' instead perhaps?) > 2) misbehaving -n > 3) missing -l from man page > 4) according to -h and man page, new_size is optional > > Any more? As we have fixed upstream 2),3),4) - renamed bugzilla to reflect remaing problem 1)
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19