I assume he's talking about a read-only fsck. Any decent fsck should refuse to modify a mounted filesystem.
I agree, though, that even a read-only fsck of a filesystem mounted read-write doesn't seem that useful --- the on-disk state of a mounted filesystem is going to be slightly inconsistent anyway: it's likely that not everything has been flushed to disk yet.
Now a full (read and fix) fsck of a filesystem mounted read-only may be useful, and tolerably dangerous if followed immediately by a reboot.
Posted Mar 17, 2009 23:45 UTC (Tue) by nix (subscriber, #2304)
[Link]
Indeed fsck.ext[234] is perfectly happy to modify a read-only-mounted /.
It even has special behaviour (messages and exit codes) to tell you when
you have to reboot because it just modified a mounted filesystem.
I still think it's a disgusting cheap hack sanctified only because that's
the only way Unix systems have traditionally been able to fsck /. Now
Linux has early userspace, there is no excuse for it at all other than
back-compatibility with people who don't have an initramfs or initrd (how
many of them are there? Not many, I'd wager).