Why does Ubuntu 18.04 doesn't create multiple BTRFS subvolumes anymore during installation by default?

[Tom H]

On Tue, Oct 2, 2018 at 4:24 PM Rashkae <ubuntu at tigershaunt.com> wrote:
> On 2018-10-02 09:46 AM, Tom H wrote:
>>
>> - you're not using the 16.04 @/@home default subvolume setup (even
>> though you'd prefer ti use it) because it's not compatible with your
>> use of systemd (which is strange because a subvolume of "/" isn't,
>> AFAIK, a mount that happens later than the "/" mount);
>
> Actually, yes, @home is mounted after root, it's not a subvolume of /
> both / and /home are subvolumes that exist on the same device... (you
> can think of it as a traditional 2 partition scheme. Mechanically, for
> fstab, it works the same way. The only difference is the use of
> subvol=@ and subvol=@home options instead of device partition numbers.
>
> That being said, I would think fixing the dependencies of systemd
> units so that whatever it is waits until file systems are mounted
> would be a better approach.

I set up an 18.10 VM using the d-i installer.

I hadn't thought of the fact that @home is fsck'd. Strangely so, given
that fsck.btrfs is a no-op.

So "home.mount" depends on being fsck'd before being mounted.

But it has "Before=local-fs.target" so it should be mounted before any
user units are run.


root at localhost:~# cat /run/systemd/generator/-.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target

[Mount]
Where=/
What=/dev/disk/by-uuid/14dfb82d-ecd9-4803-9035-ac7c47fbfac0
Type=btrfs
Options=defaults,subvol=@


root at localhost:~# cat /run/systemd/generator/home.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
Requires=systemd-fsck at dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.service
After=systemd-fsck at dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.service

[Mount]
Where=/home
What=/dev/disk/by-uuid/14dfb82d-ecd9-4803-9035-ac7c47fbfac0
Type=btrfs
Options=defaults,subvol=@home


root at localhost:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @5.985s
└─multi-user.target @5.975s
  └─snapd.seeded.service @3.398s +2.575s
    └─snapd.service @2.947s +447ms
      └─basic.target @2.943s
        └─sockets.target @2.939s
          └─snapd.socket @2.908s +26ms
            └─sysinit.target @2.888s
              └─apparmor.service @1.814s +1.073s
                └─local-fs.target @1.807s
                  └─home.mount @1.796s +10ms

└─systemd-fsck at dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.service
@1.759s +35ms

└─dev-disk-by\x2duuid-14dfb82d\x2decd9\x2d4803\x2d9035\x2dac7c47fbfac0.device
@1.753s


Changing @home's passno in "/etc/fstab" to "0" should remove the fsck
dependency.