[systemd-devel] Second (erroneous) check of rootfs?

Nikolai Zhubr n-a-zhubr at yandex.ru
Sun Jan 11 13:14:51 PST 2015

11.01.2015 23:03, Reindl Harald:
> Am 11.01.2015 um 12:48 schrieb Nikolai Zhubr:
>> I suppose this traditional (historical) technique of maintaining
>> mount-count, running fsck at boot time before remount r/w, etc, should
>> not be so much attributed specifically to ext filesystem. Most probably
>> it existed long before even ext2 appeared. However, 15 years ago I was
>> already wondering about the motivation of running full fsck depending of
>> mount-count. What's the point really?
> because you get aware of problems

I fully agree thay getting aware is good, but...

> real story shortly before christmas: reboot of our fileserver running on
> the same virtualization cluster and SAN storage as other servers, mount
> count reached -> emergency shell, manual fsck and confirm all things to fix
> i really do not want to know what would have happened a year later with
> the filesystem, after that i rebooted all other servers with a forced
> fsck and not a single one while sharing the same hardware had an error

... I'm not quite sure e2fsck is an appropriate and reliable tool for 
storage media diagnostics and fault monitoring. How much time would you 
like to wait before you get aware your data is lost?
If you value your data, you certainly put it on some sort of redundant 
storage. Now, even most regular linux mdraid offers dedicated means for 
event monitoring with an option to send warning e-amils. Moreover, 
standard linux distributions include a cron job to do a (online) raid 
check weekly, which basically compares full contents of all array 
members, so that even if some new faulty block is currently unused by 
filesystem, it has no chance to stay unnoticed for too long. Finally, 
even the cheapest consumer-level harddisks have some usefull diagnostics 
available, like the number of relocated sectors, average error rates, 
etc. There are daemons to monitor these in any standard linux 
distribution. If values start to change suspiciously -- better replace 
than wait. I'm not even talking about any special industrial environment 
-- I'm not really aware, but I'd expect that appropriate diagnostics and 
monitoring tools should be even more developed there. But that is about 
present days, 2015. And making sure media is OK by running fsck on boot 
is something more from 1970th I'm afraid... Not that I'm suggesting to 
dismiss it, but its value is very limited.

Thank you,

> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

More information about the systemd-devel mailing list