Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
On Wed, May 4, 2016 at 12:34 PM, Duncan <1i5t5.dun...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
On 2016-05-04 14:07, Chris Murphy wrote: On Wed, May 4, 2016 at 7:52 AM, Niccolò Belli 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
On Wed, May 4, 2016 at 7:52 AM, Niccolò Belli 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
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ò -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /etc/fstab rootfs options vs grub2 rootflags cmdline
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 y
/etc/fstab rootfs options vs grub2 rootflags cmdline
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ò -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
