Bug 555057

Summary:	[RFE] Add support for floating point numbers for newsize in fsadm
Product:	[Community] LVM and device-mapper	Reporter:	Gabriel <jarod125>
Component:	lvm2	Assignee:	LVM Team <lvm-team>
lvm2 sub component:	Command-line tools	QA Contact:	cluster-qe <cluster-qe>
Status:	NEW ---	Docs Contact:
Severity:	low
Priority:	low	CC:	agk, bmarzins, bmr, dwysocha, heinzm, jbrassow, jonathan, lvm-team, msnitzer, prajnoha, thornber, zkabelac
Version:	2.02.169	Flags:	rule-engine: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gabriel 2010-01-13 14:45:00 UTC

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 "

Comment 1 Alasdair Kergon 2010-01-13 17:39:59 UTC

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?

Comment 2 Gabriel 2010-01-13 20:31:35 UTC

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

Comment 3 Zdenek Kabelac 2010-01-14 09:00:14 UTC

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

Comment 4 Bug Zapper 2010-03-15 13:53:24 UTC

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

Comment 5 Zdenek Kabelac 2010-10-08 15:14:38 UTC

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.

Comment 6 Zdenek Kabelac 2010-10-15 10:05:03 UTC

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)

Comment 7 Fedora End Of Life 2013-04-03 20:19:30 UTC

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