 |
VOOZH | about |
|
VOOZH | about |
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 2Here 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)
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).
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.
Jin, Jîyan, Azadî
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 2Offline
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?
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
...
UUID=1189fc3c-092c-424d-834e-6174830417c8 / f2fs defaults,relatime,inline_data,inline_dentry 0 1
...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
Powered by FluxBB