I inherited an old PC-server (quad Pentium 4) that only had partitions for /
, /boot
and swap
(RAID1 with 2 1T SATA disks), but needed to update the distro (from CentOS 6.9). I decided to create a new partition so that the one containing /
could be formatted.
But I forgot to add the -p
flag to resize2fs
and now it's silently staring back at me and I can't tell how much longer it could take (it's been at it for 50+ hours). Now, I know that shrinking a filesystem can take a long time, but while I could wait for 100 hours, something like 800 hours is out of the question.
Here's what I'm thinking at the moment:
- Go ahead with the
Ctrl
+C
&&e2fsck
. - Mount the partition and manually delete 100G+ worth of data that serves us no purpose.
- Start from the top with
resize2fs -p ...
But I haven't been able to find consensus on just how dangerous it is to send SIGINT to resize2fs
.
I do have an extra backup of the important information, but would still like to do this without corrupting the filesystem. And yes, I'm aware it might be faster to just install the distro from scratch and restore my backup.
Update: I decided to interrupt it. And everything seems to be fine, but the question still stands. I'm still curious.
Best Answer
Definitely an interesting question and while your result was pretty good (and as I would hoped, since catching
SIGINT
is not exactly rocket science and pausing halfway merely relocating some data blocks doesn't seem hard either), there are enough non-success stories as well, like for example 10yo Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574292But even though that bug is 10y old, I've just ran a mock
e2fsck
andresize2fs
throughstrace
and while the former installs a whole bunch of signal handlers includingSIGINT
andSIGTERM
,resize2fs
still does not.So if anyone finds this question: Take the above as anecdotal evidence and continue to beware. :-) Note that the man page does mention a flag for creating an undo file in case of mistakes.
(And me, I just wish I ran this resize operation inside a screen session... but ok at least I do have
-p
)edit
Wait, I just realised, why not SSH in, make an LVM snapshot and
e2fsck
that while the resize is still running? I did that 5× in a row during the "Relocating blocks" phase and although I get "contains a file system with errors, check forced" on every check, it never found any errors. Now of course don't ask me about data integrity.edit
Pretty interesting response from tytso@ himself BTW at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574292#30