On 01/07/2015 08:53 AM, Les Mikesell wrote:
On Wed, Jan 7, 2015 at 12:10 AM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2015-01-07, Gordon Messmer gordon.messmer@gmail.com wrote:
Of course, the other possibility is simply that you've formatted your own filesystems, and they have a maximum mount count or a check interval.
If Les is having to run fsck manually, as he wrote in his OP, then this is unlikely to be the cause of the issues he described in that post. There must be some sort of errors on the filesystem that caused the unattended fsck to exit nonzero.
Yes - the unattended fsck fails. Personally, I'd prefer for the default run to use '-y' in the first place. It's not like I'm more likely than fsck to know how to fix it and it is very inconvenient on remote machines. The recent case was an opennms system updating a lot of rrd files, but I've also seen it on backuppc archives with lots of files and lots of hard links. Some of these have been on VMware ESXi hosts where the physical host wasn't rebooted and the controller/power not involved at all. Eventually these will be replaced with CentOS7 systems, probably using XFS but I don't know if that will be better or worse. It is mostly on aging hardware, so it is possible that there are underlying controller issues. I also see some rare cases on similar machines where a filesystem will go read-only with some scsi errors logged, but didn't look for that yet in this case.
I know that I have seen it take 10 ot 15 minutes to sync a 7200 rpm 3 TB WD drive that had over 2 million rrd files being updated by ntopng when the system had 32GB of ram. The system is a Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz but one cpu will in in constant IO wait state until the sync finishes. I have never tried shutting it down when it was syncing though.