Bug 506740 - resize2fs miscalculates minimum size
resize2fs miscalculates minimum size
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-18 10:33 EDT by Mads Kiilerich
Modified: 2009-06-18 18:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-18 18:52:49 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)

  None (edit)
Description Mads Kiilerich 2009-06-18 10:33:17 EDT
Description of problem:

[root@localhost ~]# dd if=/dev/zero of=img bs=1 count=0 seek=3000M && /sbin/mkfs.ext4 -F img && /sbin/e2fsck -f -v img
...

[root@localhost ~]# /sbin/resize2fs img 100M
resize2fs 1.41.4 (27-Jan-2009)
/sbin/resize2fs: New size smaller than minimum (26097)

[root@localhost ~]# /sbin/resize2fs img 200M
resize2fs 1.41.4 (27-Jan-2009)
Resizing the filesystem on img to 51200 (4k) blocks.
The filesystem on img is now 51200 blocks long.

[root@localhost ~]# /sbin/resize2fs img 100M
resize2fs 1.41.4 (27-Jan-2009)
Resizing the filesystem on img to 25600 (4k) blocks.
The filesystem on img is now 25600 blocks long.

So apparently resize2fs isn't fully deterministic and miscalculates the minimum size and might fail even in situations where a naïve user would expect it to succeed.

Of course that is annoying, but it also hints that there might be something seriosly wrong in resize2fs, and finally it might cause livecd-creator to resize to strange sizes.


Version-Release number of selected component (if applicable):

e2fsprogs-1.41.4-11.fc11.i586
Comment 1 Eric Sandeen 2009-06-18 10:59:46 EDT
The minimum size calculation has a fair bit of slop in it, as the real answer is fairly hard to get to.  You need to factor in some worst-case scenarios that may not play out, and after you resize to something in the middle, the worst-case is reduced, so a subsequent resize may go smaller.  livecd-creator is one of the few (the only?) use-cases which actually cares about that minimal size...

And it's not off by much:

> [root@localhost ~]# /sbin/resize2fs img 100M
> resize2fs 1.41.4 (27-Jan-2009)
> /sbin/resize2fs: New size smaller than minimum (26097)

26097 4k blocks is 101M... it's not that far off.

I think we can live with this, TBH, and I'm inclined to close it as NOTABUT_BUT_ONLY_SLIGHTLY_ODD_BEHAVIOR ;)

if you really want to, -f will override this upstream:

[root@inode test]# resize2fs img  100M
resize2fs 1.41.6 (30-May-2009)
resize2fs: New size smaller than minimum (26097)

[root@inode test]# resize2fs -f img  100M
resize2fs 1.41.6 (30-May-2009)
Resizing the filesystem on img to 25600 (4k) blocks.
The filesystem on img is now 25600 blocks long.

[root@inode test]# e2fsck -f img 
e2fsck 1.41.6 (30-May-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
img: 11/8000 files (0.0% non-contiguous), 17081/25600 blocks
[root@inode test]# echo $?
0

but it's a decent safety net to have in place.
Comment 2 Mads Kiilerich 2009-06-18 18:52:49 EDT
Ok, you are right. It is even documented in the man page as _the_ known bug in resize2fs.

When this behaviour isn't an indication that there is something serious going on and when the the miscalculation is known to be small then it is fine with me.

(Note to self: ext4 file systems can't be resized to less than 3% of initial size (due to overhead), so don't be too optimistic ...)

Closing.

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