/etc/fstab rootfs options vs grub2 rootflags cmdline

/etc/fstab rootfs options vs grub2 rootflags cmdline

[Niccolò Belli]

Hi,
I have the following options for my rootfs in /etc/fstab:
rw,relatime,compress=lzo,ssd,discard,space_cache,autodefrag,subvolid=257,subvol=/@

grub2 already placed rootflags=subvol=@ in its cmdline, but not the other 
options. I suppose that some of them will automatically be set during 
remount, but I'm not sure if all of them will.

Do you know which ones should I manually add to GRUB_CMDLINE_LINUX in 
/etc/default/grub?

Is there any way to check to if they are already enabled?
mount shows /dev/mapper/cryptroot on / type btrfs 
(rw,relatime,compress=lzo,ssd,discard,space_cache,autodefrag,subvolid=257,subvol=/@) 
but I'm not sure if I can trust it: I read that space_cache should trigger 
"enabling free space tree" in dmesg but I can't see it and I don't know 
about the others.

Thanks,
Niccolò

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Duncan]

Niccolò Belli posted on Wed, 04 May 2016 11:46:10 +0200 as excerpted:

> Hi,
> I have the following options for my rootfs in /etc/fstab:
> rw,relatime,compress=lzo,ssd,discard,space_cache,autodefrag,
> subvolid=257,subvol=/@
> 
> grub2 already placed rootflags=subvol=@ in its cmdline, but not the
> other options. I suppose that some of them will automatically be set
> during remount, but I'm not sure if all of them will.
> 
> Do you know which ones should I manually add to GRUB_CMDLINE_LINUX in
> /etc/default/grub?
> 
> Is there any way to check to if they are already enabled?
> mount shows /dev/mapper/cryptroot on / type btrfs
> (rw,relatime,compress=lzo,ssd,discard,space_cache,autodefrag,
> subvolid=257,subvol=/@)
> but I'm not sure if I can trust it: I read that space_cache should
> trigger "enabling free space tree" in dmesg but I can't see it and I
> don't know about the others.

The mount output should be correct.

Two points about space_cache in particular:

1) There are now two forms of space-cache, the older and still default 
(normal) space_cache, and the newer space-cache-tree, aka space-cache-v2.  
I don't yet use the latter myself and thus haven't been paying extremely 
close attention to the details, but the point here is... See that "tree" 
on the end of the dmesg entry you thought was missing?  That's only if 
you've enabled the tree/v2 version.  So that you don't see it simply 
means you haven't specifically enabled the not-yet-default tree/v2 
version, not that (the original) space_cache isn't enabled.

For the older/default space_cache, you should see "disk space caching is 
enabled".

2) space_cache is the default these days.  I've never specifically 
enabled it on any of my btrfs, yet I get both that "disk space caching is 
enabled" in the kernel log (where I copied it from) and mount (and /proc/
self/mounts) reporting it.

So you shouldn't have to specifically enable space_cache any longer, and 
can omit that from your mount options.  It should just be enabled unless 
you specifically turn it off.  Of course if you want to use the v2/tree 
stuff, you have to specifically enable it -- once.  Then it's enabled by 
default as well (with a rollback to v1 available if you want, be sure to 
read up a bit on how to get back to v1 if you need to, before actually 
enabling v2).


About the others...

* compress=lzo you need to keep in your mount options.  Older blocks will 
remain as they are, but newly written blocks won't be compressed without 
a compression option on the current mount.

* autodefrag, similar.  FWIW, here, I make sure it's enabled from first 
mount of the filesystem -- the filesystem is never mounted writable 
without it.

* ssd is often autodetected.  You might wish to try taking out that 
option and see if it still shows up once the filesystem is mounted.  
(Technically, the ssd autodetect triggers on the setting of the 
rotational file for the associated device in sysfs.  That should be 
correct for physical devices, but various intermediate layers like 
dmcrypt, md/dmraid, etc, may not pass it thru.)  I don't have to have it 
in my options here for btrfs to enable it, but YMMV.

* discard is never enabled by default, because there's some ssds it 
doesn't work well on.  So you always have to specify that if you want it.


*** Finally, unless you have specific reason not to, specifying noatime 
is recommended, strongly recommended if you do snapshotting.  The default 
relatime is a reasonable compromise on most filesystems, as it avoids 
breaking old apps (like mutt) that depend on atime, but there's very 
little if anything modern that depends on atime, on ssds even relatime is 
almost always a needless waste of limited write-cycles, and on btrfs with 
snapshotting, even relatime updates can be a large part of your metadata 
changes between shapshots, so it's definitely worth turning off (with 
noatime) in that case unless you specifically know you need it.


As for setting them in grub using rootflags, or in fstab, with or without 
also setting them in your initr* (if you have one), here, setting them in 
fstab (without setting them in the initr* that I'm aware of, anyway), 
works just fine.

However, unlike many, I actually keep my root filesystem mounted read-
only by default -- ro in my fstab mount options along with autodefrag, 
compress=lzo, etc, and only mount it writable for system updates.  If I 
were mounting it writable even as early as the initial mount in the 
initr*, I'd want to ensure that I had autodefrag,compress=lzo,noatime, 
set there as well, either by specifically including it in the initr*, or 
by setting rootflags= on the kernel commandline via grub or whatever.  If 
your initr* first mounts it read-only, and it's not mounted writable 
until you've switched to the main system and are using the main system's 
fstab, then fstab should be fine.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Niccolò Belli]

Thanks,
Now my fstab option are 
rw,noatime,compress=lzo,discard,autodefrag,subvolid=257,subvol=/@
I tried to add rootflags=noatime,compress=lzo,discard,autodefrag to 
GRUB_CMDLINE_LINUX in /etc/default/grub as you suggested but my system 
didn't manage to boot, probably because grub automatically adds 
rootflags=subvol=@ and only a single rootflags can be taken into account. 
Do you have any suggestion?

Niccolò

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Duncan]

Niccolò Belli posted on Wed, 04 May 2016 15:52:39 +0200 as excerpted:

> Thanks,
> Now my fstab option are
> rw,noatime,compress=lzo,discard,autodefrag,subvolid=257,subvol=/@
> I tried to add rootflags=noatime,compress=lzo,discard,autodefrag to
> GRUB_CMDLINE_LINUX in /etc/default/grub as you suggested but my system
> didn't manage to boot, probably because grub automatically adds
> rootflags=subvol=@ and only a single rootflags can be taken into
> account.
> Do you have any suggestion?

What about the subvol=/@?

I think if you specifically add your own rootflags, grub won't add its 
own, and you said

noatime,compress=lzo,discard,autodefrag

but left off the subvol=/@ (unless you simply forgot to put it in the 
posting), and without that, it would have mounted the btrfs default 
subvolume, which would be (the filesystem's) / (subvolid=5) if you 
haven't changed it, and would have failed to boot as a result.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Andrei Borzenkov]

04.05.2016 18:54, Duncan пишет:
> Niccolò Belli posted on Wed, 04 May 2016 15:52:39 +0200 as excerpted:
> 
>> Thanks,
>> Now my fstab option are
>> rw,noatime,compress=lzo,discard,autodefrag,subvolid=257,subvol=/@
>> I tried to add rootflags=noatime,compress=lzo,discard,autodefrag to
>> GRUB_CMDLINE_LINUX in /etc/default/grub as you suggested but my system
>> didn't manage to boot, probably because grub automatically adds
>> rootflags=subvol=@ and only a single rootflags can be taken into
>> account.
>> Do you have any suggestion?
> 
> What about the subvol=/@?
> 
> I think if you specifically add your own rootflags, grub won't add its 
> own, and you said
> 

It will, but it will prepend it to GRUB_CMDLINE_LINUX and last
occurrence on kernel command line should win, so rootflags from
GRUB_CMDLINE_LINUX should be used.

> noatime,compress=lzo,discard,autodefrag
> 
> but left off the subvol=/@ (unless you simply forgot to put it in the 
> posting), and without that, it would have mounted the btrfs default 
> subvolume, which would be (the filesystem's) / (subvolid=5) if you 
> haven't changed it, and would have failed to boot as a result.
> 

But if I understand it correctly, GRUB already adds correct subvolume,
and none of listed options should cause failure to boot.

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Chris Murphy]

On Wed, May 4, 2016 at 7:52 AM, Niccolò Belli <darkbasic@linuxsystems.it> wrote:


> I tried to add rootflags=noatime,compress=lzo,discard,autodefrag to
> GRUB_CMDLINE_LINUX in /etc/default/grub as you suggested but my system
> didn't manage to boot, probably because grub automatically adds
> rootflags=subvol=@ and only a single rootflags can be taken into account. Do
> you have any suggestion?

Well, strictly speaking none of these options are necessary as
rootflags at boot time because ostensibly on most distros the file
system is read only until it reads fstab and then remounts rw with all
of your options. So it doesn't matter that some of them are missing.
If your distro immediately mounts btrfs rw (I think Ubuntu does?) then
it's a small problem for a small number of files that get touched
during startup. I don't think it's worth the hassle.

If you think it's worth the hassle, then you have to directly modify
the grub.cfg to include an expanded rootflags parameter. Right now
grub-mkconfig logic doesn't not include all options in fstab for
rootflags.

-- 
Chris Murphy

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Duncan]

Chris Murphy posted on Wed, 04 May 2016 12:07:39 -0600 as excerpted:

> If you think it's worth the hassle, then you have to directly modify the
> grub.cfg to include an expanded rootflags parameter. Right now
> grub-mkconfig logic doesn't not include all options in fstab for
> rootflags.

And...

That might explain why his grub2 behavior didn't match what I expected.

Here, I entirely did away with the high-level grub config machinery like 
grub-mkconfig (to the point I install-mask some of the files so they 
don't get installed and thus can't accidentally be run, by some third 
party configuration script or something, and mess up my direct config) 
and I strictly do direct editing of the actual grub.cfg (and included 
files) in grub's native shell-like script.

I tend to forget that grub has this entire higher level config machinery 
that most people use, but that wasn't configuring grub the way I wanted, 
and that I'd have to learn IN ADDITION to the low-level scripting in 
ordered to get grub to do what I wanted, if I was to continue to use the 
high-level stuff at all.  Problem solved locally by simply deleting and 
masking the high-level stuff so it doesn't install, so I had to learn 
only the low-level script config, but that doesn't help me remember that 
few others will be doing that, and that the high-level stuff even exists.

So, umm, yeah, I was envisioning editing the low-level grub.cfg script 
file directly.  If he's editing the higher level config and running grub-
mkconfig or whatever to attempt to apply it to the lower level, then yes, 
that high level machinery could apply something entirely different than 
what I envisioned at the lower level, that of course being the major 
reason I use exclusively the lower level scripting language config stuff, 
here.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Chris Murphy]

On Wed, May 4, 2016 at 12:34 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Chris Murphy posted on Wed, 04 May 2016 12:07:39 -0600 as excerpted:
>
>> If you think it's worth the hassle, then you have to directly modify the
>> grub.cfg to include an expanded rootflags parameter. Right now
>> grub-mkconfig logic doesn't not include all options in fstab for
>> rootflags.
>
> And...
>
> That might explain why his grub2 behavior didn't match what I expected.
>
> Here, I entirely did away with the high-level grub config machinery like
> grub-mkconfig (to the point I install-mask some of the files so they
> don't get installed and thus can't accidentally be run, by some third
> party configuration script or something, and mess up my direct config)
> and I strictly do direct editing of the actual grub.cfg (and included
> files) in grub's native shell-like script.
>
> I tend to forget that grub has this entire higher level config machinery
> that most people use, but that wasn't configuring grub the way I wanted,
> and that I'd have to learn IN ADDITION to the low-level scripting in
> ordered to get grub to do what I wanted, if I was to continue to use the
> high-level stuff at all.  Problem solved locally by simply deleting and
> masking the high-level stuff so it doesn't install, so I had to learn
> only the low-level script config, but that doesn't help me remember that
> few others will be doing that, and that the high-level stuff even exists.

Well this is a major reason why grubby is still used to modify
grub.cfg on Fedora/CentOS/RHEL rather than obliterate the grub.cfg in
favor of an entirely new one made from scratch using the baked in
logic of grub-mkconfig.

The problem is, grubby is crusty and resists modification itself, so
while its templating of a previous boot entry, parsing it, then making
a new boot entry that uses everything it doesn't understand or care
about in the template, only changing the things that it knows need
changing (pretty much just the path to kernel and initramfs), while
applying sanity tests, it also doesn't understand Btrfs subvolumes. So
right now /boot can't be on a Btrfs subvolume, it has to be at the top
level, as a consequence.

So, booting is hard.


-- 
Chris Murphy

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Austin S. Hemmelgarn]

On 2016-05-04 14:07, Chris Murphy wrote:
> On Wed, May 4, 2016 at 7:52 AM, Niccolò Belli <darkbasic@linuxsystems.it> wrote:
>
>
>> I tried to add rootflags=noatime,compress=lzo,discard,autodefrag to
>> GRUB_CMDLINE_LINUX in /etc/default/grub as you suggested but my system
>> didn't manage to boot, probably because grub automatically adds
>> rootflags=subvol=@ and only a single rootflags can be taken into account. Do
>> you have any suggestion?
>
> Well, strictly speaking none of these options are necessary as
> rootflags at boot time because ostensibly on most distros the file
> system is read only until it reads fstab and then remounts rw with all
> of your options. So it doesn't matter that some of them are missing.
> If your distro immediately mounts btrfs rw (I think Ubuntu does?) then
> it's a small problem for a small number of files that get touched
> during startup. I don't think it's worth the hassle.
For what it's worth:
1. This only applies on systems using an initramfs.  IF you're using 
systemd, you're using an initramfs, but it's still worth remembering.
2. Some options can't be set in rootflags (the lazytime mount option for 
example, as well as some of the FS specific ones).
3. Some options can't be changed during a remount from ro to rw (mostly 
FS specific ones, I don't know of any right now for BTRFS that can't be 
changed though.

Re: /etc/fstab rootfs options vs grub2 rootflags cmdline

[Chris Murphy]

> Niccolò Belli posted on Wed, 04 May 2016 11:46:10 +0200 as excerpted:
>
>> Hi,
>> I have the following options for my rootfs in /etc/fstab:
>> rw,relatime,compress=lzo,ssd,discard,space_cache,autodefrag,
>> subvolid=257,subvol=/@

The combination of subvolid and subvol is rejected in recent kernels.
I don't know if it's rejected only if they point to different fs
trees, or if it's always rejected to have both. In any case, both does
not make sense. Pick one.




>>
>> grub2 already placed rootflags=subvol=@ in its cmdline, but not the
>> other options.

Separate them with a comma, it's valid just as it is in fstab. All you
appear to need are:

rootflags=autodefrag,discard,compress=lzo,subvolid=257

ssd should be automatically detected unless the volume is on dmcrypt
or lvm or raid. rw, relatime, space_cache are defaults. Discard is
only advised if your SSD supports queued trim, otherwise you should
rely on the systemd fstrim.timer service being enabled instead.
Everything else in your fstab is already the default.






-- 
Chris Murphy