Bug 480022 - fsadm fails growing fs with block size != 1K
fsadm fails growing fs with block size != 1K
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.7
All Linux
low Severity medium
: rc
: ---
Assigned To: Milan Broz
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-14 11:14 EST by Bryn M. Reeves
Modified: 2013-02-28 23:07 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 480023 (view as bug list)
Environment:
Last Closed: 2009-05-18 16:10:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fix units passed to fasdm in lvresize (731 bytes, patch)
2009-01-14 12:02 EST, Bryn M. Reeves
no flags Details | Diff

  None (edit)
Description Bryn M. Reeves 2009-01-14 11:14:45 EST
Description of problem:
The fsadm script fails when attempting to grow an ext3 file system with any block size other than 1K:

# fsadm --lvresize resize /dev/tvg0/l0 1G
fsadm: --lvresize resize /dev/tvg0/l0 1G
fsadm: check /dev/tvg0/l0
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/dev/mapper/tvg0-l0: clean, 11/102400 files, 7394/102400 blocks
  Extending logical volume l0 to 1.00 GB
  Logical volume l0 successfully resized
fsadm: resize /dev/tvg0/l0 1048576
resize2fs 1.35 (28-Feb-2004)
The containing partition (or device) is only 262144 (4k) blocks.
You requested a new size of 1048576 blocks.

fsadm: Resize ext2 failed
cleanup: exec lvresize -r -L4096 /dev/mapper/tvg0-l0
  fsadm failed: 1

The new block count passed to resize2fs is out by a factor of the file system  block size in kilobytes.

Since 1K block sizes are only used for tiny media this limits the usefulness of the script.

Version-Release number of selected component (if applicable):
lvm2-2.02.37-3.el4

How reproducible:
100%

Steps to Reproduce:

t0 is a volume group with ~1G free extents (you can get away with less)

1. lvcreate -n l0 -L 400M t0
2. mke2fs -b4096 -j /dev/t0/l0
3. e2fsck -f /dev/t0/l0
4. fsadm --lvresize resize /dev/t0 1G
  
Actual results:
Block size passed to resize2fs is out by a factor of 4:

# fsadm --lvresize resize /dev/t0/l0 1G
fsadm: check /dev/tvg0/l0
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/dev/mapper/t0-l0: clean, 11/102400 files, 7394/102400 blocks
  Extending logical volume l0 to 1.00 GB
  Logical volume l0 successfully resized
fsadm: resize /dev/t0/l0 1048576
resize2fs 1.35 (28-Feb-2004)
The containing partition (or device) is only 262144 (4k) blocks.
You requested a new size of 1048576 blocks.

fsadm: Resize ext2 failed
cleanup: exec lvresize -r -L4096 /dev/mapper/tvg0-l0
  fsadm failed: 1


Expected results:
File system correctly resized.

Additional info:
Problem still exists in Fedora/upstream
Comment 1 Bryn M. Reeves 2009-01-14 11:26:58 EST
Computation of the size to pass to the child fsadm invocation from LVM2 code is in bytes, not file system blocks (which is expected; the LVM2 tools don't have any idea what content is on the device nor should they):

do_resizefs_reduce():
        if (dm_snprintf(size_buf, SIZE_BUF, "%" PRIu64,
                        (uint64_t) lp->extents * vg->extent_size / 2) < 0) {
                log_error("Couldn't generate new LV size string");
                return 0;
        }

But fsadm is expecting an argument in blocks:

 new_size — Absolute number of filesystem blocks to be in the filesystem
Comment 2 Bryn M. Reeves 2009-01-14 12:02:31 EST
Created attachment 329026 [details]
fix units passed to fasdm in lvresize

The units used to calculate the new fs size are kilobytes (extents * extent_size) so tell fsadm that by adding a "K" suffix to the size strings built in lvresize.c.
Comment 3 Bryn M. Reeves 2009-01-14 12:09:10 EST
Using the patch from comment #2 I can now grow 1k/2k/4k block size ext2/3 file systems:

# (lvremove -f t0/l0; lvcreate -n l0 -L 400M t0; mke2fs -b4096 -j /dev/t0/l0; mount /dev/t0/l0 /mnt; umount /mnt; e2fsck -f /dev/t0/l0) &> /dev/null

# fsadm --lvresize resize /dev/t0/l0 1G
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/dev/mapper/t0-l0: clean, 11/102400 files, 7394/102400 blocks
  Extending logical volume l0 to 1.00 GB
  Logical volume l0 successfully resized
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/mapper/t0-l0 to 262144 (4k) blocks.
The filesystem on /dev/mapper/t0-l0 is now 262144 blocks long.

# (lvremove -f t0/l0; lvcreate -n l0 -L 400M t0; mke2fs -b2096 -j /dev/t0/l0; mount /dev/t0/l0 /mnt; umount /mnt; e2fsck -f /dev/t0/l0) &> /dev/null

# fsadm --lvresize resize /dev/t0/l0 1G
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/dev/mapper/t0-l0: clean, 11/102544 files, 11757/204800 blocks
  Extending logical volume l0 to 1.00 GB
  Logical volume l0 successfully resized
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/mapper/t0-l0 to 524288 (2k) blocks.
The filesystem on /dev/mapper/t0-l0 is now 524288 blocks long.

# (lvremove -f t0/l0; lvcreate -n l0 -L 400M t0; mke2fs -b1024 -j /dev/t0/l0; mount /dev/t0/l0 /mnt; umount /mnt; e2fsck -f /dev/t0/l0) &> /dev/null

# fsadm --lvresize resize /dev/t0/l0 1G
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/dev/mapper/t0-l0: clean, 11/102400 files, 23472/409600 blocks
  Extending logical volume l0 to 1.00 GB
  Logical volume l0 successfully resized
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/mapper/t0-l0 to 1048576 (1k) blocks.
The filesystem on /dev/mapper/t0-l0 is now 1048576 blocks long.
Comment 5 Milan Broz 2009-01-15 13:37:13 EST
In lvm2-2.02.42-2.el4.
Comment 10 errata-xmlrpc 2009-05-18 16:10:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0967.html

Note You need to log in before you can comment on or make changes to this bug.