Ubuntu Figuring Out Whether To FSCK Its File-Systems At Boot

[phoronix]

Phoronix: Ubuntu Figuring Out Whether To FSCK Its File-Systems At Boot

They are a bit late in doing so, but Ubuntu developers are working to figure out if it makes sense to run FSCK "file-system check" at boot time. It turns out Ubuntu Server and other Ubuntu installations making use of their Curtin installation component haven't enabled the functionality for FSCK at boot but now they are (re)visiting the matter...

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-FSCK-Boot-Q

[skeevy420]

Yes. Yes you fsck on boot. If you are one of the handful of people rebooting more than once a day then turn it off yourself. Most people aren't OS devs and don't need to reboot all the time as part of their workflow.

Some filesystems do not support fsck in any meaningful way, for example xfs, zfs, btrfs. There are fsck.$fstype binaries for these filesystems but they do nothing.

Fsck it, might as well turn off the automatic pool scrubbing services then

[Sonadow]

Not sure if related.

I have four installations of Debian 10. Two on laptops, one on a DIY desktop, the last on a DIY dual-Xeon workstation.

On the dual Xeon workstation, the boot process always stalls for about 10 minutes after bringing up the HID devices, then launches fsck (which finishes after about 10 seconds) before proceeding to boot. This never happens on the other three installations.

[Danny3]

I think it's bad to have it on by default on servers because when it reboots it must come up as fast as possible to have the least downtime possible to not lose money.
It seems to me that it's bad to have it on by default on desktops too because it would make the already slow boot even slower.
How about leaving people to decide when they need it and trigger it manually ?
They already did this crap on the ISO which are very annoying having to press CTRL+C every time you boot from an ISO instead of letting people do it manually like before.

But what to expect from Canonical which always think: "The user is too stupid, let's do some guesswork!"

[uxmkt]

Ubuntu Figuring Out Whether to FSCK

Is this some ext2 joke I'm too xfs to understand?

$ man fsck.xfs
fsck.xfs(8)                     System Manager's Manual                    fsck.xfs(8)

NAME
        fsck.xfs - do nothing, successfully

SYNOPSIS
        fsck.xfs [ filesys ... ]

[skeevy420]

Not sure if related.

I have four installations of Debian 10. Two on laptops, one on a DIY desktop, the last on a DIY dual-Xeon workstation.

On the dual Xeon workstation, the boot process always stalls for about 10 minutes after bringing up the HID devices, then launches fsck (which finishes after about 10 seconds) before proceeding to boot. This never happens on the other three installations.

My old Xeon workstation would take 45 seconds just to leave the BIOS screen and from there it'd vary by distribution. Xeon systems can be like that...slow to boot with all their checks. Look around in the BIOS and see if there aren't any fast boot settings or unnecessary controllers you can enable or disable.

My current system should boot faster than it does but it actually holds itself on the BIOS screen until the keyboard has initialized+3 seconds. My keyboard does this LED effect on power-on and it doesn't respond to key presses until that effect is done. Some cold boots, like an hour ago, I forget that and I think my system broke . I'm so used to my old system taking so damn long, meaning my keyboard was initialized long before I needed to touch it to access the boot menu or BIOS, that being held up by it initializing trips me up

[skeevy420]

Is this some ext2 joke I'm too xfs to understand?

$ man fsck.xfs
fsck.xfs(8) System Manager's Manual fsck.xfs(8)

NAME
fsck.xfs - do nothing, successfully

SYNOPSIS
fsck.xfs [ filesys ... ]

Some file systems don't have fsck tools so they have dummies that do nothing when fsck is set and called.

[skeevy420]

I think it's bad to have it on by default on servers because when it reboots it must come up as fast as possible to have the least downtime possible to not lose money.
It seems to me that it's bad to have it on by default on desktops too because it would make the already slow boot even slower.
How about leaving people to decide when they need it and trigger it manually ?
They already did this crap on the ISO which are very annoying having to press CTRL+C every time you boot from an ISO instead of letting people do it manually like before.

But what to expect from Canonical which always think: "The user is too stupid, let's do some guesswork!"

I agree with the server and disagree with desktops and laptops. The reason being is most people don't have the greatest power grids so better to err on the side of caution. A car wreck miles away from me made me lose power for a split second yesterday while the grid rerouted. Just long enough for me to have to boot every system and set all my clocks on everything else

I expect the average server to have a UPS, be in a building with one, or both so not needing fsck by default is fine.

[uxmkt]

Some file systems don't have fsck tools so they have dummies that do nothing when fsck is set and called.

Some file systems don't “need” fsck because they have more appropriate designs for the day and age that can survive cases like when battery runs out. Yes, there's xfs_repair, and whatever btrfs has for itself, but that's for exceptional circumstances.

[ThoreauHD]

It should be manually selected/disabled for Server.

You do not want to fsck a SAN fiber mount by default.

The rest, do whatever desktop coddling you need to do. It isn't going to crash the internet, unlike the first one.