How dangerous is it to interrupt an fsck?

Has anyone had any direct experience doing this?

Solution 1:

I don't have any direct knowledge or evidence, but to me, it would just be plain EVIL to not handle SIGINT.

Hm. Actually, I can offer some assurance: strings /sbin/fsck | grep sig reports:

sigaction
Warning... %s for device %s exited with signal %d.

So I'll just take this as anectdotal evidence that the fsck developers are calling sigaction to handle the relevant signals.

Solution 2:

If you control+C and wait for it to stop, you shouldn't have any issues.

The problem always occurs when it's stuck and won't stop, because you're not really sure what it's doing. Normally at this point you have severe loss of data.

Good luck.

Solution 3:

It all depends.

For example, Ubuntu (since Hardy Heron) has had a user option to interrupt (and postpone) a routine disk check if it comes up during boot. I make use of this for ext3 partitions if I need a quick boot-up (see http://brainstorm.ubuntu.com/idea/11/.

I would not personally interrupt an fsck following a dirty umount or had any reason to think that a filesystem might be compromised: not least bnecause I wouldn't want to save new data to such a file system and potentially put that data at risk as well as cause further damage to existing data or metadata.

Solution 4:

You can cancel the automatic-every-30-boots-fsck at start up. It's run at next mount. I've done it many times. It doesn't normally have any negative effects.

If you computer didn't shutdown properly, then the fsck will run. Personally I'm not going to cancel that. It doesn't really take long, and your data is important. There's no point potentially causing all your data to be lost just to save half an hour in boot up time in my opinion,

Solution 5:

fsck (at least e2fsck) can handle being interrupted with Ctrl-c.

Further to the answers from Chris and Anders, here is the output when I was running sudo e2fsck -ccktv -C 0 /dev/sda1, realized it was going to take a week to run, and cancelled it:

Interrupted at block 6030528

Interrupt caught, cleaning up
data01: Updating bad block inode.

data01: ***** FILE SYSTEM WAS MODIFIED *****

Clearly, fsck has code to handle the interruption and gracefully exit.