From Newsgroup: alt.os.linux.mint
On Mon, 9/7/2026 5:50 PM, Alan K. wrote:
On 9/7/26 5:30 PM, Lawrence DrCOOliveiro wrote:
On Mon, 7 Sep 2026 15:02:51 -0400, Alan K. wrote:
If your filesystem is on an SSD, is this of value?
Being on an SSD or a hard disk makes no difference. fsck is about
checking the consistency of the filesystem.
But really, there isnrCOt much need to worry about this nowadays. WerCOre
all running journalling filesystems, arenrCOt we? And they are capable
of recovering from crashes just by replaying the journal, which only
takes maybe a minute or less -- much quicker than running fsck over
the entire filesystem.
And wearing the drive even more too, LOL.
Apparently, this gives some statistics on the running of a given filesystem.
https://askubuntu.com/questions/680980/tune2fs-mount-count-is-it-disabled-by-default-set-to-1
sudo tune2fs -l /dev/sda7
Filesystem created: Fri Sep 18 05:48:19 2015
Last mount time: Thu Oct 1 21:01:39 2015
Last write time: Thu Oct 1 21:01:39 2015
Mount count: 12
Maximum mount count: -1 <=== It is not getting regularly checked
Last checked: Sat Sep 19 03:27:50 2015
Check interval: 0 (<none>) <=== if you believe these numbers...
Lifetime writes: 1037 GB
A possible value for the maximum mount count is 30, at which point an fsck runs.
https://askubuntu.com/questions/1108888/whats-the-frequency-of-filesystem-check-on-boot
A playback journal is fine up to a point. There is a thing called latent faults, which is basically a declaration "that nothing is perfect and if errors develop, they can accumulate over time". The purpose of picking a frequency for the fsck, is to cover the possibility of some condition existing, which fragment
removal using the playback journal, does not fix. With latent faults,
the theory is, that two faults could interact and make a fault scenario
which is harder to fix. And that's when fsck starts asking you those
funky questions.
Setting it to -1 like that, may be implying that a policy is controlled
some other place in the OS. If you can find such a setting in a Google session.
An fsck can take an enormous amount of time, if you have a large number of files
on a storage device. This may tempt a person to use settings like the ones in the
table above. Tuning the thing so it is never checked, plus having a very large and deep file tree in the storage, that's just asking for trouble. Some people are surprised then, the first time they manually run fsck, and it finds so so many
problems.
I had two guys at work, they'd been sent on a course for three months,
on how to write device drivers for Sparc computers. And when they came back,
as a bonus, they'd been taught how to fix corrupted file systems. It was amusing to watch them work - they always worked as a pair. One guy was
the pattern recognition guy "does that look like a unlinked directory to you ?".
The other guy was the "cook", and he would come up with the recipe. "Well,
I see two faults there, first we fix this one, then we re-link that directory." And all the time, they were staring at some hex editor like display. I often wondered
what would happen, if one of them was sick, and a skill was missing that day. Back in those days, there were catastrophes on multiple platforms at work,
when the power would go off. It used to take us fifteen minutes just to
bring the floor back up, because it had to be done in a defined order.
And on top of that, you could have a disk consistency problem on something,
and just the boot time on any box with fancy storage, could be disappointingly slow.
Those situations still arise. We don't have those two guys in the room to help us.
One other modern trick, is "runtime consistency checking", of which I know nothing, as I've never seen descriptions of what is so wonderful about
the method. That is not an fsck, but it is some sort of background operation that verifies a very small section of the tree is working OK. One of the questions
about such things, is can the runtime checks keep up, when a disk is 100% busy ?
Sure, you could build up a queue of those for later, but the user might
select Shutdown before the queue is processed.
In any case, we never assume storage is perfect, and a sinful administrator ignores their storage, at their peril. When you're hearing "clicks of death" coming from a drive, is NOT the time to run fsck :-/ You cannot atone for
your sins, by running fsck three times in a row as a means of "catching up".
Paul
--- Synchronet 3.22a-Linux NewsLink 1.2