Poettering: The Biggest Myths
Posted Jan 30, 2013 18:54 UTC (Wed) by ttelford
Parent article: Poettering: The Biggest Myths
I realize I'm days late to the party, but there is one thing that has always bothered me about systemd: boot up fsck.
Let's say, for example, we have the following scenario:
- We have critical systems, including several large disk arrays, that have lost power with no chance of shutting down properly. (Let's say there are tightwads who feel hardware failure and data loss is cheaper than a UPS).
- No problem, when power comes back, the system starts booting up.
- Naturally, our arrays require FSCK'ing... and here we have a problem.
- Systemd (reasonably) halts all boot progress until fsck is done.
- Systemd does not, however, provide any sort of feedback as to how the FSCK is progressing.
- Obviously, this is all console mode, as the boot splash hides everything anyway
- Even worse, systemd doesn't provide any indication of a problem when an FSCK fails, requiring manual intervention.
- A sysadmin has no clue whether the FSCK is simply taking a long time, or failed altogether.
- Since there's no feedback, an Admin doesn't know if s/he needs to reboot in a recovery mode (to perform the manual FSCK actions), or if the fsck is simply taking its sweet time.
- Even without a power failure, many FSes require an FSCk after so many mounts and/or days. All the admin knows is that the boot isn't completing.
It's been a few months since I've tried using systemd because of this... and even then, I was using Debian systems, which have an old version of systemd.
So has systemd actually fixed the fsck clusterfsck? Or is it still impossible to tell whether the kernel has panicked on boot or the system is just fsck'ing?
to post comments)