Bug 506740
Summary: | resize2fs miscalculates minimum size | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mads Kiilerich <mads> |
Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | 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
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.
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. |