Is fsck obsolet for journaling FS? - Was: How do I Automount [snip]

[Tom H]

On Mon, Nov 30, 2015 at 5:53 PM, C de-Avillez <hggdh2 at ubuntu.com> wrote:
> On Sun, 29 Nov 2015 23:18:14 +0100 Ralf Mardorf <silver.bullet at zoho.com> wrote:


>> Résumé
>>
>> It's not recommended to drop fsck by dafault.
>>
>> fstab can not simply be deleted.
>>
>> And maybe it's still better to teach how to use fstab to mount devices
>> during startup, than to confirm that learning this is not required,
>> because it's possible to use gnome-disks?
>
> I did not follow all of this thread, and I do not think I lost much.
> But this email caught my attention.
>
> * fsck is indeed needed, and will -- at least for the near future --
>   still be needed. This does not mean most users will ever even hear
>   about it, or use it. There _are_ filesystems not served by fsck,
>   though (zfs comes to mind).
>
> * Now, *most* of the times fsck is needed it will be deployed
>   automagically on boot (because root is dirty). But if you have an
>   external disk, or moved a disk from a dead system to a still-live
>   one, you may need to run fsck by hand.
>
> * fstab cannot simply be deleted, indeed. If it is there, leave it
>   there. Assume that the installer saw a need to create it (usually
>   when more than one disk is in use, or when LVM2 (man 8 lvm) is
>   configured).
>
> * man fstab shows what to do. blkid (8) can show you the uuid of the
>   disk you want to add in fstab. It is recommended to use the uuid in
>   fstab (as opposed to devices) because this gives one more assurance
>   that your new drive in the system, with the data you need, will not
>   be confused, in a monumental coincidence, with your swap space.
>
> * Also, lsblk (8) gives one a nice overview of what is in the system.

When Oliver said that fstab could be deleted, he was probably thinking
of a default latest Ubuntu desktop use-case whereby someone has an EFI
box with "/boot/efi", "/", "swap", and perhaps "/home". These
partitions have a GPT PART/UUID type [1] that's recognized by systemd
and are therefore auto-mounted correctly.

[1] Frustratingly, different tools label this property differently:

blkid --> n/a
fdisk --> Type-UUID
lsblk --> PARTTYPE
partx --> TYPE


> * perhaps the fifth, and sixth fields in a fstab entry are
>   confusing, so here it is: the fifth field should *always* be zero
>   (no dump needed for this FS); the sixth field will set the sequence
>   for fsck: 1 should be the root FS, any other disk should be > 1. (so
>   fsck will first check the root, then check the next priority disks,
>   and so on). On my laptop, for example, root is 1, boot is two, and
>   the two additional filesystems I have (on a different SSD) are 3.

Unless you run "dump -W", it doesn't matter what the fifth field is.


> * so you want to dump your filesystem? Set the fifth filed in fstab to
>   1, and install dump. You will probably be the first in a long time to
>   do that. In the many years I have been dealing with UNIX, I have not
>   used dump (except for _restoring_ a saved dump once) in a very long
>   time. Even the restore was more than 10 years ago. There are now
>   better ways of backing up your disks. *My* fstabs have not have dump
>   set since I started using Linux.

The main reasons that dump fell into disuse is that:

1) we all started to use higher-level backup software rather than
OS-supplied backup tools.

2) Linus had a silly [2] rant about dump, because it screws things up
when using it on a filesystem that's mounted rw.

[2] Many of his non-kernel-development rants are uninformed. I saw a
DebConf talk of his on YouTube where he said that he didn't use Debian
because he'd been told that he couldn't run "make" to compile a kernel
but had to use "make-kpkg". Unfortunately no-one corrected him (or
told him that whoever told him that is an idiot!). He admitted in the
same that he was a bad sysadmin; clearly.