Bug 506740

Summary: resize2fs miscalculates minimum size
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: esandeen, kzak, mishu, oliver, tjb
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-18 22:52:49 UTC 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 Mads Kiilerich 2009-06-18 14:33:17 UTC
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 14:59:46 UTC
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 22:52:49 UTC
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.