On Sat, 9 May 2009 13:44:09 -0400 Theodore Tso <ty...@mit.edu> wrote:
> On Fri, May 08, 2009 at 08:39:53PM -0400, Andres Salomon wrote: > > Package: e2fsprogs > > Version: 1.41.3-1 > > > > If I attempt to shrink an ext3 filesystem while mounted (even if > > read-only) via "resize2fs /dev/hda1 8G", it refuses with: > > > > "Filesystem at /dev/hda1 is mounted on /; on-line resizing required > > On-line shrinking from $foo to $bar not supported." > > > > I don't know if this is a necessary restriction or not, but it's > > pretty annoying. If it is safe to do when the fs is mounted > > read-only, it would be nice if '-f' allowed one to bypass the > > check. > > Well, it could cause the system to panic and reboot while resize2fs is > in the middle of resizing the filesystem --- is that unsafe > enough? :-) > Sure, that would be a good reason to not allow it. :) [...] > > > > Please consider the following patch to allow the administrator to > > override the failed mount point check using the -f option. It > > would be even better if that check could be made to not happen at > > all w/ -f (or some other argument). > > So I'm extremely uncomfortable with this. I would much rather have > initramfs create a zero-length /etc/mtab file in the inital ramdisk > image, or better yet, have a fully supported and supportable system > which allows users to shrink the root filesystem. Creating a zero-length /etc/mtab file doesn't work if, for some reason, /etc is mounted read-only. Having a fully supported and supportable system isn't always available. If resize2fs is going to stipulate that the filesystem that it's shrinking is not mounted, then users are going to use it in things like recovery cds and initramfs's. I like my tools to get out of the way and allow me to what I want to do. That's why I use free software (transparency and hackability). I'm fine w/ all kinds of warnings to tell the user that they shouldn't continue, so long as they are also told of a way to actually continue. > > For example, we could have a script fragment that checks for the > existence of a file which matches the pattern /on-initrd-*.tar.gz, and > if one or more such files exists, they are copied to the initrd, and > then the root filesystem is unmountd, and one by one, the > on-initrd-*.tar.gz files are unpacked and the /on-initrd script > contained in the tar.gz file is executed. > > This could be used to perform an off-line shrink of the root > partition, by having the user request such a thing, and then > rebooting, and having it happen automatically. It could also be used > to add or remove a journal safely, as well as repack and optimize > directories (e2fsck -fD). > Sounds like additional unnecessary complexity to me. > Another approach would be to resize the filesystem using a rescue CD. > > The reason why I suggest these is they are in the long-term much more > supportable. If a user doesn't know enough to work around the > "ext2fs_check_mount_point: No such file or directory while determining > whether /dev/hda1 is mounted" error by using "touch /etc/mtab", do we > really want to trust him or her with using resize2fs -f? What if they Yes. Trust the user. We're not idiots. Or, if we are, then we'll quickly learn what not to do when it comes to using command line tools. That message could just as easily be: "ext2fs_check_mount_point: 'No such file or directory' while determining whether /dev/hda1 is mounted. DO NOT RESIZE THE FILESYSTEM WHILE IT IS MOUNTED. However, if you're positive that the filesystem is not mounted, rerun this tool with '-f' to continue." > use it when they shouldn't, and end up trashing their own > filesystem? They'll find some other way to trash their filesystem. Stopping people who know what they're doing is not a good trade-off. > > I've already had a bug filed by an Ubuntu user who saw this error > message: > > /dev/ssd/root is mounted. > > WARNING!!! Running e2fsck on a mounted filesystem may cause > SEVERE filesystem damage. > > Do you really want to continue (y/n)? > > ... and they were clueless enough to answer yes, and then when his > filesystem was severly damanged (as promised) he filed a bug > complaining about the fact. "Resize2fs -f" is even easier for said > user to screw up. So? Close the bug and move on. There's nothing you can do for a user who fails to read warnings (though I could understand their complaint if they accidentally hit <enter>, and 'y' was the default choice). Just like babies who learn that sharp pointy things hurt, users will quickly discover that: a) unlike other operating systems, Linux doesn't just pop up silly warning messages for the hell of it; they'd better read (and heed) those warnings, and b) if they're going to be messing around at the command line, they'd best be careful. There are even more dangerous commands around, like 'rm' and 'dd'. > > If I did anything at all, I'd be severly tempted to make the user type > something like: > > Warning! An attempt to resize /dev/XXX while it is mounted > may cause your system to crash and your filesystem to be > destroyed. To continue please type: 'I ACCEPT ALL LIABILITY > FOR TRASHING MY FILESYSTEM AND PROMISE NOT TO FILE A BUG'. > Or, if your /etc/mtab file is in error or missing, type ^C, fix it > by hand, and rerun re2size2fs: " > > ... and only continue if the user types the required string. :-) > That would be fine. Apt does something similar, and I'm perfectly okay with that. I'd even be happy to see the "may cause your system to crash" bit, since it wasn't immediately obvious to me what the consequences of online shrinking were. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
