On Thu, May 21, 2020 at 10:04:54AM +0200, Wilmer van der Gaast wrote:
> I just started a downsizing resize2fs operation over an SSH session
> without screen and then realised how bad an idea that was..
>
> Then found this bug as a confirmation. :-)
>
> It looks like resize2fs (still) doesn't install any signal handlers so
> I've just disabled auto-suspend on my laptop and will hope for the best.
>
> tytso@ mentions the danger of -M by the way, I guess that danger applies
> to *any* downsizing operation, not just to bare-minimum resizes done by -M?
The reason why we've never bothered with signal handlers is because it
won't help against unclean/uncommanded shutdowns --- for example such
as auto-suspend on your laptop.
In *general* things are mostly safe unless you need to do an
overlapping move of the inode table, in which case it is very hard to
make it be 100% safe.
You can use resize2fs -z undo_file, but that's currently not
super-safe, because we aren't forcing a flush between every I/O
operation --- because that would disastrous in terms of performance,
and users would then be complaining about how slow the resize
operation was, and how it was increasing their SSD write wear.
Basically, it's hard to keep everyone happy.
If you would like to help, you could try running resize2fs -p on a
test file system, and then try to randomly interrupt the resize at
various points, and then run e2fsck -fy and during which phase of the
resize you see things getting corrupted.
It's not a high priority for me, since I have way too many other
things to worry about, if it is high priority for *you*, some
contributions to the effort would be much appreciated. After all,
Open source means you get to help fix the things you care about. :-)
- Ted
