Automatic filesystem checks?

hoerbert · 2016-05-25 17:16:18

Hey everyone,

after reading this thread [0] I had the urge to check the filesystem-check settings on my machine. As of [1] the check should be done on every 30th mount per default. But like in the mentioned thread, my partitions (both on my productive system and on a recently set up vm; all ext4 [besides swap of course]) also have a maximum mount count of -1 and a check interval of 0, what means the filesystems never will be checked if I understand that correctly. The output of tune2fs -l also states that the check was last done when the filesystem was created.

fstab

[hoerbert@Arch ~]$ cat /etc/fstab 
# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/sda7
UUID=75188b35-aa3e-420c-8647-5a4135cbe0ec       /               ext4            rw,relatime,data=ordered        0 1

# /dev/sda8
UUID=e65f4f6a-ae5c-4f3c-8547-b607f14cf729       /home           ext4            rw,relatime,data=ordered        0 2

# /dev/sda6
UUID=8fceb92a-db3d-4638-b8cc-1ef9e344cf7f       none            swap            defaults        0 0

tune2fs -l /

[hoerbert@Arch ~]$ sudo tune2fs -l /dev/disk/by-uuid/75188b35-aa3e-420c-8647-5a4135cbe0ec 
[sudo] Passwort für hoerbert: 
tune2fs 1.42.13 (17-May-2015)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          75188b35-aa3e-420c-8647-5a4135cbe0ec
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              6111232
Block count:              24413696
Reserved block count:     1220684
Free blocks:              19103284
Free inodes:              5836927                                                                                                                          
First block:              0                                                                                                                                
Block size:               4096                                                                                                                             
Fragment size:            4096                                                                                                                             
Reserved GDT blocks:      1018                                                                                                                             
Blocks per group:         32768                                                                                                                            
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Tue Mar 26 14:21:58 2013
Last mount time:          Wed May 25 09:28:18 2016
Last write time:          Wed May 25 09:28:18 2016
Mount count:              1360
Maximum mount count:      -1
Last checked:             Tue Mar 26 14:21:58 2013
Check interval:           0 (<none>)
Lifetime writes:          590 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       941549
Default directory hash:   half_md4
Directory Hash Seed:      018894d9-f9e9-4e4b-a424-051b66f31dcd
Journal backup:           inode blocks

tune2fs -l /home

[hoerbert@Arch ~]$ sudo tune2fs -l /dev/disk/by-uuid/e65f4f6a-ae5c-4f3c-8547-b607f14cf729 
tune2fs 1.42.13 (17-May-2015)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          e65f4f6a-ae5c-4f3c-8547-b607f14cf729
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              13131776
Block count:              52524032
Reserved block count:     2626201
Free blocks:              25708084
Free inodes:              12776813
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1011
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Tue Mar 26 14:22:07 2013
Last mount time:          Wed May 25 09:28:30 2016
Last write time:          Wed May 25 09:28:30 2016
Mount count:              1360
Maximum mount count:      -1
Last checked:             Tue Mar 26 14:22:07 2013
Check interval:           0 (<none>)
Lifetime writes:          2811 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e94fec84-0161-4e3a-bbbc-6e196dea3a92
Journal backup:           inode blocks

So my question is: Why does the wiki-page say that the filesystem is checked on every 30th boot by default, while the settings and tune2fs-data indicate otherwise? Or are the checks launched by other mechanisms and the tune2fs utility just don't "see" these checks?

Thanks in advance,

Torben

[0] https://bbs.archlinux.org/viewtopic.php?id=212971
[1] https://wiki.archlinux.org/index.php/Fs … _frequency

V1del · 2016-05-25 22:20:41

Don't know about the tune2fs directives, but if you have a value in the pass field of your fstab, said partition will be fsck'd on every boot by the fsck included in your initramfs by mkinitcpio.

Last edited by V1del (2016-05-25 22:32:47)

WorMzy · 2016-05-25 22:44:02

I don't think it will. It'll be checked if it's marked as dirty, but otherwise it'll just print that it's clean (the same as if you manually run fsck on a clean filesystem without the -f flag). If tune2fs' output is to be believed, hoerbert's filesystems haven't been checked for over three years.

tune2fs' man page recommends against disabling mount-count checking:

-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the filesystem is
mounted will be disregarded by e2fsck(8) and the kernel.
Staggering the mount-counts at which filesystems are forcibly checked will avoid
all filesystems being checked at one time when using journaled filesystems.
You should strongly consider the consequences of disabling mount-count-dependent
checking entirely. Bad disk drives, cables, memory, and kernel bugs could all cor‐
rupt a filesystem without marking the filesystem dirty or in error. If you are
using journaling on your filesystem, your filesystem will never be marked dirty, so
it will not normally be checked. A filesystem error detected by the kernel will
still force an fsck on the next reboot, but it may already be too late to prevent
data loss at that point.

However, the no-periodic-fsck setting in /etc/mke2fs.conf comes from upstream, so I don't know what to make of the situation.

Vain · 2016-05-26 05:34:32

WorMzy wrote:

However, the no-periodic-fsck setting in /etc/mke2fs.conf comes from upstream, so I don't know what to make of the situation.

Yes and, just for the record, it indeed sets max-mount-counts to -1:

http://git.kernel.org/cgit/fs/ext2/e2fs … 1bea#n2922

Checking the log of upstream's mke2fs.conf leads to this:

http://git.kernel.org/cgit/fs/ext2/e2fs … 6085f2ffaf

tl;dr: Setting was changed in 2011 to -1. Upstream believes it's annoying and not necessary.

TheChickenMan · 2016-05-26 06:15:02

Vain wrote:

Setting was changed in 2011 to -1. Upstream believes it's annoying and not necessary.

A file system error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.

This makes me a bit nervous. I am inclined to believe upstream over the dire predictions listed in the man page.
I haven't really heard about any big increase in people losing data from failing EXT4 file systems this was changed.

Lone_Wolf · 2016-05-26 22:50:12

Checking those links makes me glad my ext4 partitions were created before that change .

At worst the checks are a mild annoyance to me, but imo that's a low price for confirmation my filesystems are intact once or twice a month.

hoerbert · 2016-05-28 15:08:49

OK, let me summarize:

It is intended by upstream that there are no automatic file-system checks
Apparently the wiki is not up to date for this point
If I want file-system checks I will have to activate them on my own

Did I get everything correct here?

Vain · 2016-05-28 19:32:26

Nah, I'm not sure. Depends on what you see as "automatic file system check".

There are no scheduled file system checks anymore by default, as in "every 30 mounts". There are still file system checks if the kernel detects an unclean file system on boot.

I recently saw an fsck on boot on an Arch system (ext4) that suffered a power loss and, yes, that system had "max mount count = -1". So, I don't understand what the man page of tune2fs is trying to tell us here:

If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked.

The next sentence is even more confusing:

A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.

Yeah, fine, but how does "max mount count = 30" help here?

What I do understand is the first sentence:

Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error.

That makes perfect sense and that's why I manually set "max mount count = 30" on my systems. An fsck every now and then should do no harm. It might indeed be too late to detect the beginning of actual data loss, but at least I'll notice it at some point. (Which still doesn't sound very reassuring ...)

Arch Linux

#1 2016-05-25 17:16:18

Automatic filesystem checks?

#2 2016-05-25 22:20:41

Re: Automatic filesystem checks?

#3 2016-05-25 22:44:02

Re: Automatic filesystem checks?

#4 2016-05-26 05:34:32

Re: Automatic filesystem checks?

#5 2016-05-26 06:15:02

Re: Automatic filesystem checks?

#6 2016-05-26 22:50:12

Re: Automatic filesystem checks?

#7 2016-05-28 15:08:49

Re: Automatic filesystem checks?

#8 2016-05-28 19:32:26

Re: Automatic filesystem checks?

Board footer