[systemd-devel] Second (erroneous) check of rootfs?
Nikolai Zhubr
n-a-zhubr at yandex.ru
Sun Jan 11 13:14:51 PST 2015
Hi,
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.
</rant>
Thank you,
Nikolai
>
>
>
> _______________________________________________
> 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