4

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.

Roflo
  • 369
  • 4
  • 17

1 Answers1

7

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=574292

But even though that bug is 10y old, I've just ran a mock e2fsck and resize2fs through strace and while the former installs a whole bunch of signal handlers including SIGINT and SIGTERM, 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

Wilmer
  • 290
  • 3
  • 6
  • 2
    looking at the source https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/resize/resize2fs.c?id=2d2d00c6c6dc3f2aa72dccec635885f03a37a14f it appears that aborting during phase 1 & 2 shouldn't have adverse side-effects, phase 3 & 4 have no mention about the side-effects of abort, phase 5 have multiple disclaimers that aborting during this phase may scramble the file system – CervEd Apr 06 '21 at 23:25