4

As the subject says, I have a Raspbian system (Buster, and this happened with the prior Raspbian version too) that runs a full fsck on one particular volume every time it boots. And this only happens for one particular volume, not all the disks - they finish immediately because they are also clean. (the volume in question is not the root filesystem, it's one that's used for ancillary storage, not any system function.)

I've been searching on this problem for months, but the finds tend to be cases where they want to cause a forced-fsck to happen. It's hard to find any posts about this particular, and opposite, problem.

I could (and have, temporarily) set the fsck flag in /etc/fstab to '0' to skip it, but would like to have it still run enough at boot to notice the clean filesystem and not run a full check.

Things I've tried so far:

Physically moving the volume (it's in a standalone USB disk case) to another Raspbian system of the same version, I observed that host does things as it should: It verifies the filesystem, noting it as clean at boot, and thus does not run a complete check.

I've looked at the usual superblock fields (tune2fs -l) for last-check date and mount-count, and set the flags to prevent the per-mount-count and date-based auto-checks, but the system still does one every time.

If I manually fsck the volume, fsck.ext4 reports it as clean immediately.

A manual complete fsck -f of the unmounted volume ran cleanly, but did not solve the problem.

But if I reboot, systemd-fsckd launches an fsck that runs through the whole thing, taking about 20-30 minutes (it's a 1.8TB volume, about 25% full).

I've also tried completely deleting the volume and the disk's partition table and starting from scratch, new partition table and new volume, new filesystem (parted, mkfs.ext4, etc). No change in the problem.

The fsck process, when running at boot-time, shows it was invoked with the usual flags (-y -C4), neither of which should cause it to always run a full check on a 'clean' volume.

What else could be causing this?

Improve this question
5
  • "What else could be causing this?" -> Power, maybe, if the Pi is supposed to provide it to the drive. If the drive browns out for an instance when first mounted, when it comes back online it would be considered dirty.
    – goldilocks ♦
    Jul 25, 2019 at 12:42
  • The drive hangs off a separately-powered USB hub, so shouldn't be losing power. That it works fine when attached to a different pi does make me wonder, though. Maybe I just thought the hub was getting power. Now I'll triple-check that. Thanks!
    – Gary Dobbins
    Jul 25, 2019 at 14:37
  • When I measured the voltage in the hub, adding the drive pulls the hub's voltage down to 4.75V. So I got a heavier-gauge cord for the power, now it holds at no less than 4.97, but the problem persists. There's no mention of that USB device doing anything odd in the dmesg log.
    – Gary Dobbins
    Jul 25, 2019 at 15:43
  • One further test I did just now: Commented-out the volume's line in /etc/fstab, unmounted it, rebooted. Once the machine was up and idle, I ran fsck on the volume. It reported clean and took no further action.
    – Gary Dobbins
    Jul 25, 2019 at 16:12
  • There would be pretty obvious indications in dmesg, so that's not it. Edit the line from fstab into the question. You could try setting it 'noauto', then mounting it manually or via some service near the end of the boot process.
    – goldilocks ♦
    Jul 25, 2019 at 16:14

1 Answer 1

Reset to default
5

I found what I believe was the cause, and it now appears to be fixed. Since this machine has a battery-backed RTC on it, fake-hwclock had been uninstalled long ago. When looking at the dump from 'journalctl -xb' I noticed the timestamps were all from several months back (about the time the machine was made, perhaps), and then didn't jump to the present until boot was almost finished. Other Pi's show more predictable clock times in that same dump. So, I installed fake-hwclock, and now it behaves like it should. Runs an fsck on every volume at boot, but none run their full mode.

Improve this answer
2
  • That's quite cool. I have spent some time scratching my head over the question (stupid review queue not displaying answers), but I didn't think of timestamps.
    – Dmitry Grigoryev
    Jul 26, 2019 at 13:39
  • 1
    I was prompted to consider clock time when I noticed a remark in one of the journal dumps - something about the last-checked time being in the future, and thought "...that's funny. I wonder if fsck handles that rationally or not, and what 'rational' actually is for such a thing."
    – Gary Dobbins
    Jul 26, 2019 at 23:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.