I recently experienced an outage with our Netapp array that affected our VMs, and upon rebooting, about 80% of the Debian instances running ext4 required a manual fsck -y for each partition, significantly slowing down recovery. I'm considering changing the FSCKFIX setting to yes, so that if fsck runs, it will automatically repair any issues. I'm not concerned about fsck running on every boot, but when it does, I'd prefer it to handle repairs without my intervention. Do you think modifying this behavior is advisable in a VMware environment with iSCSI storage? Also, I'm looking to update the GRUB_CMDLINE_LINUX_DEFAULT setting on modern Debian systems with Systemd. Any insights or alternatives?
2 Answers
It's unusual for a journaling filesystem like ext4 to require an fsck at all. You should check that journaling hasn't been disabled on your partitions. You can do this by running `tune2fs -l /dev/sda | grep features` and looking for 'has_journal'. That said, if you want to use FSCKFIX=yes, just be aware it may do some repairs automatically, so ponder on how vital that setting will be for your use. If you've got backups and your setup is pretty stable, it could be a safe move.
I typically run ext4 with journaling enabled and don’t face issues during boot. For special partitions like /boot, I use ext2 since those are less frequently modified. In your case, most of your problems seem to stem from /var/log, which is still designed to handle journaling well. It sounds like nothing catastrophic happened, just time-consuming. Maybe just stick with FSCKFIX=yes if you're confident in your backups; it could save you some hassle.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures