background_fsck="NO"

[PacketMan]

It's a rainy day, and ham radio field day is not going so well for me. I have a specific objective to achieve today, and not even close to getting there.

Filesystem is UFS. Drives are spinning disks. (SSD upgrades are down the road.)

I have a couple remote 'lower horsepower' FreeBSD machines, UPS is not an option, and nor even practical. Sometimes I have an issue occur, where when the machine is repowered, and background fsck is running, and some other programs start using the disks fairly heavy. Anyway, keeping the story short, I'd like to delay the startup of said programs until any and all fsck has completed.

After doing some reading from some older books, online posts, and FreeBSD FSCK man page, it's still not clear to me.

If I do background_fsck="NO" in /etc/rc.conf, does that mean the 2nd go of fsck (i.e. on the mounted filesystem) does not run at all, or does it mean it will run, but do so in the foreground, and thus other programs will not run until it's completed? I'm thinking it does not go at all, but was hoping for an affirmative answer.

And assuming I am correct, what and how would I modify, such that FreeBSD does any and all possible FSCK, with the "Y" option since these are remote machines, before allowing programs to start? Are there additional options that can be enabled for FSCK during it's 1st pass when in single-user mode?

Thanks again, all,
PacketMan

 

[SirDice]

If I do background_fsck="NO" in /etc/rc.conf, does that mean the 2nd go of fsck (i.e. on the mounted filesystem) does not run at all, or does it mean it will run, but do so in the foreground, and thus other programs will not run until it's completed? I'm thinking it does not go at all, but was hoping for an affirmative answer.

Normally it only does a 'preen' check, which can only fix some minor issues, you may also want to change these two:

fsck_flags="-p"   # May be changed to -f (or -f -y) to force a full fsck
fsck_y_enable="NO"  # Set to YES to do fsck -y if the initial preen fails

And yes, setting background_fsck="NO" will cause the fsck(8) to run in the foreground, before the filesystems are mounted read/write.

If you have lots of additional disks in /etc/fstab take note of the "pass" number, it's sometimes beneficial using 1, 2 or even 3, to 'stagger' the fsck(8) instead of having it run on all disks simultaneously.

 

[PacketMan]

I've got it set the way I think I want. The machines take around 10-15 minutes to boot now and I am a-ok with that.

My config:

fsck_y_enable="YES"
fsck_flags="-f -y"
background_fsck="NO"

I'm thinking I can remove the first line, but will try that another day when I have some time. Thanks again.

 

[SirDice]

The machines take around 10-15 minutes to boot now

That's one of the reasons why it's done in the background, and really only a sort of 'quick' scan. Those big storage disks we nowadays have take ages to do a complete and thorough scan (journalling helps but is certainly not foolproof). Normally when a system is correctly shutdown filesystem issues shouldn't happen, thus a quick scan typically suffices.

 

[bob2112]

Is there a reason why you haven't simply enabled UFS journalling? This enables the equivalent of a foreground preen to be done in seconds.


Look at the -j option of tunefs.

 

[larshenrikoern]

Is there a reason why you haven't simply enabled UFS journalling? This enables the equivalent of a foreground preen to be done in seconds.


Look at the -j option of tunefs.

Look at SirDice's post. And journaling is sometimes prone to errors. Have been there next time i go with ufs, it will be without both journaling and softupdates. I am sure it might be a better experience. At least with fewer errors

 

[bob2112]

Look at SirDice's post. And journaling is sometimes prone to errors. Have been there next time i go with ufs, it will be without both journaling and softupdates. I am sure it might be a better experience. At least with fewer errors

Preens have there own problems. IMO choosing a background preen over SU-journalling isn't a good trade-off . A preen isn't looking for serious corruption, but because of the amount of work it does, it has a better chance of stumbling across it. However a background fsck can't actually do anything about it, except log it and flag it for the next boot. There is a lot of advocacy for SU-journalling these day, probably some bugs have been fixed. And I suspect that some of the problems around UFS/SU are down to unreliable hardware.

A lot of people these days are running ZFS even without redundancy. If I couldn't run ZFS, I'd probably go back to UFS on gjournal which is full journalling at the device level. I do use UFS with SU-journalling for offline storage and I've not had a problem. A manual full fsck I did recently found nothing.

Without SUs you have to do a full fsck which can take hours. I did for a time configure rc.d/fsck to do this out of paranoia, but it didn't really solve anything. I didn't turn off SUs, that seems like a bad idea. SUs are intended both to protect the file system and to leave the data in a self-consistent state. If you turn-off SUs without using gjournal instead, nothing is even trying to do either.

 

[larshenrikoern]

Last time I used UFS (around a year ago) I regularly had to force a full fsck because of errors. So I lost some data because of errors until I disabled both journaling and SU. After that no errors and therefore no need for fsck.