1

I am running systemd, and this page said to pass the kernel parameter fsck.repair=yes to have all filesystems checked.

Trying this, my ESP partition (FAT32) was dutifully checked, but there are no journal lines matching the strings fsck, btrfs, check or the device name which indicate that anything happened on / itself.

I believe that btrfs-check is not being run.

How can I find the last btrfs check date/timestamp of a filesystem?

Tom Hale
  • 28,728
  • 32
  • 139
  • 229
  • `btrfs`usually does not need to be `fsck`d; some say it is useless (see e.g. http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html). To check `btrfs`you use `scrub`, which should be run online on a regulary basis (through `cron`, eg; see http://superuser.com/questions/904331/how-does-btrfs-scrub-work-and-what-does-it-do) – ridgy Feb 05 '17 at 12:58
  • The `scrub` man page disagrees with you: `Note Scrub is not a filesystem checker (fsck) and does not verify nor repair structural damage in the filesystem.` While a check at boot may not safely be able to *correct* structural issues, having them *detected* is extremely useful. `btrfs-scrub` would tell me if I had [bitrot](https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/) in my accessible data or metadata, but only `btrfs-check` would tell me (e.g.) if there was an inode without any references. – Tom Hale Feb 05 '17 at 13:08
  • 1
    Anyway, to answer your question - your btrfs partitions won't be checked because `systemd-fsck`, [as I said here](http://unix.stackexchange.com/a/50772), executes the specific file checker - in this case `/sbin/fsck.btrfs` which is just a script that does nothing and exists with `0` (unless device does not exist) - you can view its contents with `cat /sbin/fsck.btrfs`. See also [the discussion here](https://bugzilla.redhat.com/show_bug.cgi?id=625967) – don_crissti Feb 05 '17 at 13:26

0 Answers0