Red Hat Bugzilla – Bug 249645
RFE- a resize2fs --minimal query option would be nice
Last modified: 2009-02-25 12:08:23 EST
Description of problem: jkatz requested I file this bug. It would be nice if resize2fs would have a --minimal feature or if there was some way to discover (other than brute force retrying of various sizes) what the minimal size is that you can resize an ext2/3 filesystem to. This would clean up some code in cleanupDeleted in livecd-creator Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I'll look into this - one thing that might help in the meantime, is a debug flag available now, which tells you how much space would be needed: [root@inode e2fsprogs-1.39]# resize2fs -d 2 fsfile 1024 resize2fs 1.39 (29-May-2006) Resizing the filesystem on fsfile to 1024 (1k) blocks. Number of free blocks: 847/4294965071, Needed: 2225 <<---- Need 2225 more Going into desperation mode for block allocations resize2fs: No space left on device while trying to resize fsfile [root@inode e2fsprogs-1.39]# bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1024+2225 <---- what we asked for + what was needed 3249 <--- so, this is our minimum size quit [root@inode e2fsprogs-1.39]# resize2fs -d 2 fsfile 3249 resize2fs 1.39 (29-May-2006) Resizing the filesystem on fsfile to 3249 (1k) blocks. Number of free blocks: 847/0, Needed: 0 The filesystem on fsfile is now 3249 blocks long. and we can't go smaller: [root@inode e2fsprogs-1.39]# resize2fs -d 2 fsfile 3248 resize2fs 1.39 (29-May-2006) Resizing the filesystem on fsfile to 3248 (1k) blocks. Number of free blocks: 0/4294967295, Needed: 1 Going into desperation mode for block allocations resize2fs: No space left on device while trying to resize fsfile
FWIW, before I filed this, I had looked at the resize2fs code, to see if there was something obvious. The thing that dissuaded me, was that I found several independent places where it would jump to the failure-too-small case, for seemingly completely different reasons. So I'm not sure if the single heuristic you describe is a complete solution.
You might be right... out of curiosity, what heuristic do you use now, i.e. what do you use as a starting point (currently used block count?) and how do you see it fail (by how many blocks)? I have a patch I'm playing with, but haven't pointed it at a large variety of populated filesystems yet. -Eric
Currently with livecd-creator there is no heuristic. Just a low bar of 0, a high bar of the current size, and then a binary search, simply using success or failure of the command as the metric to reset one of the bars, until they converge. There is certainly room to improve that. Would speed up the livecd creation process by a small, but significant amount.
It'd be interesting to know how the final size usually compares to the originally reported free blocks, I guess - just out of curiosity... but I digress... :)
Changing the summary slightly to reflect that just having a way to be told the minimum would be nice as opposed to the option to determine and resize to the minimum. While both have their uses, the former can trivially be used to pass to the latter. And the former is helpful for showing the minimum filesystem size in, eg, anaconda as well as the resizing in livecd-creator.
sent patch upstream http://article.gmane.org/gmane.comp.file-systems.ext4/4397 if you specify a resize size of 0 or < than the minimum resize size e2fsprogs will spit out the minimum number of blocks needed for a resize.
Does it require that you go through a fsck of the filesystem first? If so, it's going to be a little bit less than ideal for the purposes of finding the minimum size a filesystem can be resized to for anaconda. Since we really would prefer not to make any changes to the filesystem unless the user explicitly requests doing so
you can specify -f if you want to skip the fsck check. Upstream doesn't want this feature to be its own option, instead opting to have it spit out the correctly calculated minimum number of blocks needed in cases where the resize size is too small, so this code is in the actual resize code, which means I can't short circuit the fsck check.
Okie doke -- I'll give it a try as soon as I can to see how it works. With school stuff, it might be a couple of weeks until I get a chance, though
We're pretty late in the F9 cycle for this change, moving to 10.
Actually, switching back to F9Target. Without it, we can't really give users a good idea of the minimum they can resize to in the installer. And I think esandeen said it's upstream
Adding FutureFeature keyword to RFE's.
I think this is done, right? Can we close this as CURRENTRELEASE? commit 199ddaaa445e14fca8113b0db85e2576267071c9 Author: Josef Bacik <jbacik@redhat.com> Date: Thu Mar 13 13:46:10 2008 -0400 resize2fs: Add options to print (and resizing to) the minimum filesystem size Add the -P option to print the minimum filesystem size and exit. Add the -M option to force resizing the filesystem to the minimum filesystem size. Signed-off-by: Josef Back <jbacik@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>