Skip to main content ↑ ↓
Topic: which file details scheduled FS checks (Read 523 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

which file details scheduled FS checks

I'm trying to find out why I'm getting frequent journal replays and one place I need to go (for trouble-shooting) is wherever it is that I can cancel an existing check job every 30 mounts of a data partition. Is this info stored in the data partition's filesystem or somewhere in the OS?  How does any one of several distros I use know how many times the partition has been mounted? Does that count include mounts from other OS'es?
 
Who, has loved us more?

Re: which file details scheduled FS checks

Reply #1 –
Normally one would post what partition(s) are in question, what are the formats and maybe even show the fstab file which would allow one to see what exists on your setup.
Quote
every 30 mounts of a data partition
This sounds like an ext formatted partition situation from this section.
Please read Arch Ext partition information.
Quote
It seems that our ext3 filesystems are still being checked every 30 mounts or so. This is a good default for many because it helps prevent filesystem corruption when you have hardware issues, such as bad IDE/SATA/SCSI cabling, power supply failures, etc. One of the driving forces for creating journaling filesystems was that the filesystem could easily be returned to a consistent state by recovering and replaying the needed journaled transactions. Therefore, we can safely disable these mount-count and time-dependent checks if we are certain the filesystem will be quickly checked to recover the journal if needed to restore filesystem and data consistency. Before you do this please make sure your filesystem entry in /etc/fstab has a positive integer in its 6th field (pass) so that it is checked at boot time automatically. You may do so using the following command:
Code: [Select]
# tune2fs -c 0 -i 0 /dev/sdXY
If you just want to limit the checks to happen less often without totally disabling them (for peace of mind). A great method is to change from a number of count's check to a time frame check. See tune2fs(8). Here is once every month:
Code: [Select]
# tune2fs -c 0 -i 1m /dev/sdXY

If not then please provide more information regarding your system's configuration.

Re: which file details scheduled FS checks

Reply #2 –
Thanks for the input.

All my partitions are ext4 (except swap). The problematic partition is an ext4  data partition which also stores the home of one user (userMe) but not the other users'. Each OS has its own _userMe folder there.  For example when I boot Artix then /home/userMe is a link to its dedicated /mounts/datapartition/ArtiXuserMe. There are a few folders that are linked into all the ../whateveRuserMe folders. Sylpheed is such so that regardless of which OS I boot my mail gets done in exactly the same single folder (few apps work with such practices so far). 

This data partition is getting frequent journal replays and failing FS checks. It's this issue that I'm trying to get to the bottom of.  Corruption often results when a lockup happens (such as the kde login lockup raised in my other thread).   

Since the tune2fs command seems to do the setup, I presume the parameters (like so many mounts or so much time) are stored in the FS itself.  This way, with the existing 30 mount cycle I could boot 30 different linux systems in turn and the next one would force a check? This is why I asked, for example IF the params were stored in the OS then the mountcount would tick once only each time when THAT system mounts it. I asked because I didn't know.

I may try to lower the FS check on this data partition to maybe weekly while I troubleshoot it. That should limit replays to FS failures of one sort or another and might help to pinpoint the source problem(s).

 
Who, has loved us more?

Re: which file details scheduled FS checks

Reply #3 –
Yes the tune2fs modifies and stores the format data on the storage device partition directly so it is readable no matter the booting kernel.
If one boots many times per day, a time period would be the way to go instead counting the number of mounts as per the second example.

The checks in itself are not too bad if the data is always found to free of errors. Warning bells should be going off if you are experiencing file corrections during these runs. A serious hardware issue could be the cause. I get a new device ready ASAP and backup the important stuff.

Since the environment you are using has many different distributions using shared a partition, you may run into an issue where the embedded busybox tool versions are different that are used during the boot process to do the boot file check before the partition gets fully mounted in read/write mode.  If the busybox file check does not recognized the previous file check as sound which is possible with different busybox versions, it will flag the partition to be checked no matter the setting on the partition.

Re: which file details scheduled FS checks

Reply #4 –
I haven't had time to play with tunefs yet but I have begun to lay my traps to catch the culprit in the act. On two of my seven distros I have commented out in fstab the automatic mounting of both the general data partition of another drive as well as that partition on the same drive which hosts what the /home/userMe link points to. On these systems, since only userMe has his rags remoted, I now have to log in as another user first, mount the two partitions and then log in as userMe. Much to my surprise this one move has greatly reduced the corruption and journal-replay incidence. I'll be backl with more as resources permit :-)
  
Who, has loved us more?

Re: which file details scheduled FS checks

Reply #5 –
Quote from: jspaces – on
It seems that our ext3 filesystems...  If you just want to limit the checks to happen less often without totally disabling them (for peace of mind). A great method is to change from a number of count's check to a time frame check. See tune2fs(8). Here is once every month:

# tune2fs -c 0 -i 1m /dev/sdXY

Just in passing "-c 0" now sets the count to -1

As mentioned in my last, I have disabled auto mounting via /etc/fstab in my two least-suspected distros (Leap & Tumblweed) but it turns out that I haven't seen a single replay since  :)

Now I have also set  "tune2fs -c 0 -i 1w /dev/sda"  (1 & 2) for the  data partitions on the other disk.  I don't suppose this will change much in the current tweak. Maybe a couple of weeks downline I will re-enable auto-mounting in /etc/fsatb to see what comes loose. 

Thank you very much for the advice.
 
Who, has loved us more?

Re: which file details scheduled FS checks

Reply #6 –
It is good to hear that the file checks have stopped on what sounded like every boot.

If the shared partition is something desired then I would recommend setting the fstab in all other OSes not to file check the shared partition on boot. The sure to boot the one OS with the file check regularly or at least umount the partition and manually check periodically. Having only one automatic file check on the shared partition will result in a much more stable file system.

Re: which file details scheduled FS checks

Reply #7 –
Quote from: jspaces – on
It is good to hear that the file checks have stopped on what sounded like every boot.

If the shared partition is something desired then I would recommend setting the fstab in all other OSes not to file check the shared partition on boot. The sure to boot the one OS with the file check regularly or at least umount the partition and manually check periodically. Having only one automatic file check on the shared partition will result in a much more stable file system.

Ok, I missed the nuance on the last read about the scope of fstab here.  Yes, I will write auto checking on boot out of all fstabs to start, at least provisionally.

Right now all is quiet on the front as they say, I missed it before but it seems that I had nixed automount out of more than just 2 systems, Artix being another one. Truth is I don't know the excact score but since all is well I'll leave it as is for a week or so to see if luck continues. After that I should maybe start challenging my guardian angels again (the kind souls whom I've been burning out by the busload ever since I was born) by resuming automounts one system at a time until I nail it good. 
  
Who, has loved us more?

Re: which file details scheduled FS checks

Reply #8 –
Quote from: badsector – on
....until I nail it good. 

I might have.  Been extremely busy with a milion other things, but....

When I first suspected 'AUTO' I commented out auto mounts in all 7 fstabs This resulted in what seemed like an immediate improvement as I mounted the data partitions manually
 
As I started to progressively re-enable some of them I noticed that data partition (/dev/sdb2) hosting userMe 'home' mounted properly but the other one (/dev/sdb1) was not mounted and still had to be mounted manually. This way everything worked fine, eventually on all 7 systems.

But it wasn't turning smoothly, obviously. I did some of the suggested FS tweaks and still have some to do but along the way I noted that the uuid of /dev/sdb1 did not match the one produced by blkid!  Now it all came together!

I periodically make backups to 3 identical disks with identical partitions, some of them are literal bitcopies made with dd and some of them are populated with rsync. On the last recovery made necessary by FS corruption of unknown origin (lockup while running firefox) I must have made the mistake of reverting via the dd method but from a partition populated with rsync  ...so the uuid ended up being incongruant with that in fstab.

Thank you for all the help!    :)   

[fingers crossed just in case, might even be a good way to keep them off the keyboard for a while]

     

Who, has loved us more?
 

Re: which file details scheduled FS checks

Reply #9 –
Sounds like you got it under control.
Stuff like Linux distributions interacting with each other in seemly strange ways when sharing resources is something to keep a lookout for. For example, the boot loaders, the system's ESP (EFI System Partition) and as you found out, shared mounted folders.
Peace.