Code review comment for ~dbungert/curtin:nonzero-fs_pass

> We discussed this internally a bit and still think we should change the

I do wish this sort of discussion would happen either on discourse or
ubuntu-devel/ubuntu-server.

> default. (I haven't heard back from the MAAS team yet). The kernel is not the
> only thing that reads filesystems (UEFI firmware and grub both do), and for

VFAT is not a journaled filesystem, I'm 100% fine with enabling fsck on this.

As for grub the design of journaled filesystems are such that it's always
readable even on crash. Worst case IIUC is a newer files could not show up
until the journal replays.

Additionally, this journal replay (and fsck) happens after grub has run; any
new writes to the filesystem won't have been checked with fsck unless fsck
happens on shutdown (I don't think this is enabled anywhere in Ubuntu) and
still won't help in the case of a crash.

> the filesystems that do not implement any kind of non-trivial fsck, we're not
> at the boot optimization point where adding an invocation of essentially

This isn't a boot optimization; rather it can only slow boot down and for zero
benefit for journaled filesystems.

> /bin/true will have a noticeable impact. So the (small) upsides seem to
> outweigh the (even smaller) downsides and I don't think this makes enough
> difference to anyone to warrant a feature flag.

Changing behavior always warrants feature flags; they're free just like
version bumps. Let's not hide this "feature".

>
> Also we have changed things so fsck is run in clouds recently after not doing
> so was causing problems (don't know the details) and we should be consistent
> about this.

I've been opposed to this as well. For all of the same reasons here and a few
more (cloud instances not being pets, not having interactive consoles to do
repairs, fsck having a non-zero effect on time it takes to mount the rootfs)