You are not logged in.
Since formatting a partition to f2fs, I am finding that systemd is triggering a fsck on every boot. I found other examples of this (google/other distros) but none with a cause or solution with the exception of this fedora one wherein it was reported as being fixed. I am unable to see a diff of the fix vs last-release to see what they did.
Thoughts are welcomed.
I am mounting it via this line in /etc/fstab
LABEL=incoming /incoming f2fs defaults 0 2
Here is an example of my recent boot:
% journalctl -b | grep fsck
Apr 14 08:23:48 ease systemd[1]: Created slice system-systemd\x2dfsck.slice.
Apr 14 08:23:49 ease systemd-fsck[539]: boot: clean, 573/32768 files, 16046/131072 blocks
Apr 14 08:23:49 ease systemd-fsck[552]: homes: clean, 44592/12681216 files, 1867777/50718033 blocks
Apr 14 08:23:55 ease systemd-fsck[595]: Info: Fix the reported corruption.
Apr 14 08:23:55 ease systemd-fsck[595]: Info: [/dev/sdb2] Disk Model: xxx
Apr 14 08:23:55 ease systemd-fsck[595]: Info: Segments per section = 1
Apr 14 08:23:55 ease systemd-fsck[595]: Info: Sections per zone = 1
Apr 14 08:23:55 ease systemd-fsck[595]: Info: sector size = 512
Apr 14 08:23:55 ease systemd-fsck[595]: Info: total sectors = 419430400 (204800 MB)
Apr 14 08:23:55 ease systemd-fsck[595]: Info: MKFS version
Apr 14 08:23:55 ease systemd-fsck[595]: "Linux version 5.0.6-arch1-1-ARCH (builduser@heftig-23236) (gcc version 8.2.1 20181127 (GCC)) #1 SMP PREEMPT Wed Apr 3 09:35:20 UTC 2019"
Apr 14 08:23:55 ease systemd-fsck[595]: Info: FSCK version
Apr 14 08:23:55 ease systemd-fsck[595]: from "Linux version 5.0.7-arch1-1-ARCH (builduser@heftig-20167) (gcc version 8.2.1 20181127 (GCC)) #1 SMP PREEMPT Mon Apr 8 10:37:08 UTC 2019"
Apr 14 08:23:55 ease systemd-fsck[595]: to "Linux version 5.0.7-1-minimum (facade@ease) (gcc version 8.2.1 20181127 (GCC)) #1 SMP PREEMPT Sat Apr 13 12:27:34 EDT 2019"
Apr 14 08:23:55 ease systemd-fsck[595]: [update_superblock: 513] Info: Done to update superblock
Apr 14 08:23:55 ease systemd-fsck[595]: Info: superblock features = 0 :
Apr 14 08:23:55 ease systemd-fsck[595]: Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
Apr 14 08:23:55 ease systemd-fsck[595]: Info: total FS sectors = 419430400 (204800 MB)
Apr 14 08:23:55 ease systemd-fsck[595]: Info: CKPT version = 58dd8078
Apr 14 08:23:55 ease systemd-fsck[595]: Info: Checked valid nat_bits in checkpoint
Apr 14 08:23:55 ease systemd-fsck[595]: Info: checkpoint state = 1c5 : trimmed nat_bits crc compacted_summary unmount
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] Unreachable nat entries [Ok..] [0x0]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] SIT valid block bitmap checking [Ok..]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] Hard link checking for regular file [Ok..] [0x0]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] valid_block_count matching with CP [Ok..] [0x793511]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x1ffa]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x1ffa]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] valid_inode_count matched with CP [Ok..] [0x16f]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] free segment_count matched with CP [Ok..] [0x1521f]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] next block offset is free [Ok..]
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] fixing SIT types
Apr 14 08:23:55 ease systemd-fsck[595]: [FSCK] other corrupted bugs [Ok..]
Last edited by graysky (2019-04-14 12:39:01)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Set fs_passno (the sixth field in /etc/fstab) to zero.
Para todos todo, para nosotros nada
Offline
@Head - Yes, good work around. Doing it will also disable any auto fsck though... like to understand cause of false positive (or perhaps systemd is not umounting correctly).
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
like to understand cause of false positive
systemd-fsck@.service(8) says that systemd will automatically check any filesystem for which passno is greater than zero so I think this behaviour is expected.
Para todos todo, para nosotros nada
Offline
@Head - I saw that as well, but I have ext4 partitions that are setup as such and the boot process does not hold up...
LABEL=boot /boot ext4 defaults 0 1
LABEL=home /home ext4 defaults 0 2
LABEL=lxc /var/lib/lxc ext4 defaults 0 2
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Perhaps mask the systemd-fsck service for that device then?
Para todos todo, para nosotros nada
Offline
fsck on an ext4 partition would be a noop provided the filesystem is marked clean so would not delay boot.
Last edited by loqs (2019-04-16 23:52:52)
Offline
So either the f2fs partition is not getting properly umounted on a reboot or the flag is triggering a check on every reboot by design?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
The pass no is set to 2 so fsck is called and it would appear fsck.f2fs always does an actual check unlike fsck.ext4.
Edit:
As a test if you add the boot option fsck.repair=no does fsck.f2fs then do a quick fsck?
Last edited by loqs (2019-04-18 10:02:35)
Offline
I'm getting this issue too, the f2fs partition gets checked at almost every boot. I did notice a message though, showing the previous kernel version and the current one.
I went to check the source of fsck.f2fs and here it is, it checks if there's a new kernel version and perform a full fsck if it does. Since Arch updates kernels frequently, you'll notice this at almost every boot. Not a bug, it's a feature.
Offline
I have the same problem but this is happening to me since some versions of the kernel (I wouldn't know which one). Before it only did the check when the computer reboot and the kernel version had changed but now it always does. In addition the check is very slow and delays the start a lot.
The fstab is the same before and now:
...
UUID=1189fc3c-092c-424d-834e-6174830417c8 / f2fs defaults,relatime,inline_data,inline_dentry 0 1
...
I don't think it's right to deactivate the check (setting fs_passno to zero) because, in my case, it's the root disk.
https://i.imgur.com/G1jUfcE.jpg
What has changed so that now the check is done at every restart?
Mod note: Replaced image with URL. Please read the Code of Conduct and adhere to the image posting guidelines. -- WorMzy
Last edited by j1simon (2019-06-23 08:45:06)
Offline