On 12/10/2014 10:14 AM, Andrei POPESCU wrote:
In my not so humble opinion, one should be using such a switch to re-examine one's setup, practices, etc. You might discover some "interesting" stuff. As far as I'm concerned: 1. I'll be looking into disabling periodic checks on all my ext4 partitions[1], in line with the not so new mkfs defaults. 2. As has been pointed out in this thread, interrupting or completely skipping the check after unclean umount is *dangerous* and can lead to data loss. If you get one of these while you're on battery power it's probably a good time to think if your backup strategy is good enough[2]. 3. If one can afford the additional downtime a full fsck as part of regular maintenance *might* make sense. E.g. I could imagine on kernel upgrades (which force a reboot anyway) one boots up with the new kernel, check everything is working fine and then reboots a second time with 'fsck.mode=force'. [1] the only other filesystem I'm (still) using is xfs, which doesn't do this anyway [2] and start praying if it isn't Kind regards, Andrei
Hi, Andrei.I'm posing a question at this point because it relates directly to your post excerpted above. If you feel this is off-topic for this thread, I'll be glad to start a new thread.
I came to the same conclusions you outlined and implemented 1 and 3 among your suggestions on my home systems -- all running testing. However, I've been helping a few remote users of Debian testing -- some of them thousands of miles from me -- by doing updates/upgrades, configuration changes as needed, and so on for them.
Using fsck.mode=force on the linux command line works fine for the purpose of forcing a file system check at home, but I don't see a practical way to use it on the remote systems. Do I really have to walk each of them through editing of the linux command line or through alteration of their grub menu, etc. so they can initiate fsck manually themselves at boot time once-in-a-while? Or can you think of a way I can be in control of this without bothering them? Some of these folks would not be good candidates for performing these changes to such essential parts of their systems.
At present I can still use "touch /forcefsck", but I see the warning about this in the log, and I imagine the ability to use this command to cause an fsck to run during the next reboot may cease to be implemented at some point.
This issue -- while not what I'd call a bug -- is a feature difference that may eventually result in my having to stop performing this particular part of the maintenance. This is of some concern to me, most particularly in regard to the older systems which use ext3.
Ideas? Thanks