Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
Fedora Everything Presentation from youtube. https://www.youtube.com/watch?v=qOv-EFdVoss Regards Leslie Leslie Satenstein Montréal Québec, Canada On Sunday, October 25, 2020, 10:38:33 p.m. EDT, Chris Murphy wrote: On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel wrote: > > Hi Chris, > > This weekend past, I did create /opt and /var as subvolumes. For the empty > /opt, it was easy. For /var, it took the live ISO to help with moving > directory /var to subvolume /var. Recommended reading. https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout The "flat" method for /var means it actually gets swapped from the 'old dir var' to 'new subvolume var' at reboot time via the fstab entry resulting in it being mounted on /var. You can mount the Btrfs file system again at /mnt and clean out the root/var directory. There is a sort of "through the looking glass" experience with "flat" layout. I often regret not giving subvolumes names different from their mount point if I use this layout style. So instead of a "var" subvolume mounted at /var, I'll name it var33 (i.e. var for Fedora 33). Maybe we'll end up using native system mount units for these kinds of things so that fstab isn't overly complicated. The "nested" layout just substitutes in-place, no need for fstab entry. Way simpler. Except if you ever have to do a rollback, and then you have to move it into the new location before the rollback. That isn't always possible or maybe you wouldn't have to rollback in the first place. > I also intend to do the same with /sys on this, my beta system, I'm not sure about this. /sys is a pseudo-filesystem, the contents aren't really on the root file system. > The rational for my doing the subvolume exercise is the following: > 1) Under default installation, each snapfile of root has a copy of all > subdirectories including active /var, and /sys. I noted that /var/log and > /var/cache is rather volatile. My SSD size is 120gigs > 2) By isolating /var, /opt and /sys the root snapshot becomes less bloated. /var contains the rpm database, which means at least /var/lib/rpm is tied to /usr and to some degree /boot. That means any need to rollback one requires rolling back all in conjunction. And yet /var/log is one thing we probably do not want to rollback, and possibly the same for /var/cache in its entirety. But... work-in-progress. > 4) But /var/log is quite active, as is /var/cache. I will be using btrfs > defragment on /var. If it's a (spinning) HDD it might be suited for the autodefrag mount option so long as the workload isn't heavy database use. Autodefrag is intended for light database use like web browsers, and spinning drives. There's a proposal upstream to make it a settable property so it can be enabled selectively, rather than as a mount option. I don't ever defragment SSD/NVMe. I think you're better off using bcc-tools' fileslower to evaluate if there are unexpected latencies happening. And quantifying how much defragmenting solves the problem. You can further narrow these down the source of latency with btrfsdist, btrfsslower and biolatency. (There are ext4 and xfs equivalents.) > 5) Having /var as nodatacow puts /var to the same risk level as when /var was > on the ext4 system. If you're wanting to save space, you may want to experiment with compression. And nodatacow means no compression. I think you want to be more selective with nodatacow for very specific reasons and already the top candidate for that already get's nodatacow set automatically by libvirt when a storage pool is created. > > I will be using fstrim -a (to do SSD trims) and I want to user snapper, to > manage the subvolume snapshots. The generations of snapshots for /var and / > will be my objective. > I will be using crontab and a script to take snapshots just before the > script launches "sudo dnf update -y". OK you might want to look at the dnf snapper plugin for this. > This switch to btrfs is a learning experience for me. Fedora is my passion, > From my studies, I may discover that you are absolutely right to state that I > do not need to make the extra subvolumes. > The advantage I have over you is my career. It is called "retirement". > Retirement comes with spare time to study, to learn, to write code, to > explore, experiment and to share experiences. Cool! Have fun! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
On Mon, Oct 26, 2020 at 5:26 PM Chris Murphy wrote: > If you want more granular settings, see 'btrfs property', which can be > applied per subvolume, directory or per file. It is possible to > specify an algorithm. But is not yet possible to specify level, set it > recursively or unset it once set. Correction. Setting level does work: # btrfs property set testfile compression zstd:11 -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
On Mon, Oct 26, 2020 at 3:57 PM Leslie S Satenstein via devel wrote: > > Thank you all. > > Is it worthwhile putting compress=lzo for root. Without concern, I have done > it for /home. It'll be hardware and workload specific whether to compress and what algorithm to use. Note that the mount option is file system wide, it's not restricted to a specific mountpoint/subvolume. If you want more granular settings, see 'btrfs property', which can be applied per subvolume, directory or per file. It is possible to specify an algorithm. But is not yet possible to specify level, set it recursively or unset it once set. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
Thank you all. Is it worthwhile putting compress=lzo for root. Without concern, I have done it for /home. Regards Leslie Leslie Satenstein Montréal Québec, Canada On Monday, October 26, 2020, 2:17:40 a.m. EDT, Ian Kent wrote: On Sun, 2020-10-25 at 20:38 -0600, Chris Murphy wrote: > On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel > > > I also intend to do the same with /sys on this, my beta system, > > I'm not sure about this. /sys is a pseudo-filesystem, the contents > aren't really on the root file system. That's right, like /proc is a proc file system, /sys is a sysfs file system (similar to other pseudo file systems). They are memory based and files are generated on access, proc files mostly directly from kernel data structures, and sysfs mostly from an rb-tree data structure within the sysfs file system populated at boot. You must mount /sys as a sysfs file system in order for the rb-tree to be populated, you can't make it a btrfs file system (or any other file system for that matter). Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
On Sun, 2020-10-25 at 20:38 -0600, Chris Murphy wrote: > On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel > > > I also intend to do the same with /sys on this, my beta system, > > I'm not sure about this. /sys is a pseudo-filesystem, the contents > aren't really on the root file system. That's right, like /proc is a proc file system, /sys is a sysfs file system (similar to other pseudo file systems). They are memory based and files are generated on access, proc files mostly directly from kernel data structures, and sysfs mostly from an rb-tree data structure within the sysfs file system populated at boot. You must mount /sys as a sysfs file system in order for the rb-tree to be populated, you can't make it a btrfs file system (or any other file system for that matter). Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
Hi Chris I am again attaching a program for you to try.I AM THE AUTHOR. Extended to manage btrfs entries. fstabxref -o /tmp/fstab It reads the /dev/disk/by-xxx contents,/etc/mtab and /etc/fstab It validates each fstab entry as it builds the output. Errors are pointed out. In the process of coding it, if you have "btrfs sub create var" at the 5 levelmtab will show it as /var, ditto for the other subvols. And changing the /etc/fstab to include the / before the var in the fstab as subvol=var appears to make no difference if it is subvol=var or subvol=/var Things I discover. If you look at other distros based on btrfs, the root00 is replaced by @so @home, @var etc are used. For a while that @ thing stumped me. But then, I persisted. I am going to study your link's contents. My code is opensource and actually I find it very useful. Use labels, UUIDs, PARTUUIDS, PARTLABELS, /dev/, my code handles it. If you find it useful and want the source git repro, just ask. Regards Leslie Leslie Satenstein Montréal Québec, Canada On Sunday, October 25, 2020, 10:38:33 p.m. EDT, Chris Murphy wrote: On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel wrote: > > Hi Chris, > > This weekend past, I did create /opt and /var as subvolumes. For the empty > /opt, it was easy. For /var, it took the live ISO to help with moving > directory /var to subvolume /var. Recommended reading. https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout The "flat" method for /var means it actually gets swapped from the 'old dir var' to 'new subvolume var' at reboot time via the fstab entry resulting in it being mounted on /var. You can mount the Btrfs file system again at /mnt and clean out the root/var directory. There is a sort of "through the looking glass" experience with "flat" layout. I often regret not giving subvolumes names different from their mount point if I use this layout style. So instead of a "var" subvolume mounted at /var, I'll name it var33 (i.e. var for Fedora 33). Maybe we'll end up using native system mount units for these kinds of things so that fstab isn't overly complicated. The "nested" layout just substitutes in-place, no need for fstab entry. Way simpler. Except if you ever have to do a rollback, and then you have to move it into the new location before the rollback. That isn't always possible or maybe you wouldn't have to rollback in the first place. > I also intend to do the same with /sys on this, my beta system, I'm not sure about this. /sys is a pseudo-filesystem, the contents aren't really on the root file system. > The rational for my doing the subvolume exercise is the following: > 1) Under default installation, each snapfile of root has a copy of all > subdirectories including active /var, and /sys. I noted that /var/log and > /var/cache is rather volatile. My SSD size is 120gigs > 2) By isolating /var, /opt and /sys the root snapshot becomes less bloated. /var contains the rpm database, which means at least /var/lib/rpm is tied to /usr and to some degree /boot. That means any need to rollback one requires rolling back all in conjunction. And yet /var/log is one thing we probably do not want to rollback, and possibly the same for /var/cache in its entirety. But... work-in-progress. > 4) But /var/log is quite active, as is /var/cache. I will be using btrfs > defragment on /var. If it's a (spinning) HDD it might be suited for the autodefrag mount option so long as the workload isn't heavy database use. Autodefrag is intended for light database use like web browsers, and spinning drives. There's a proposal upstream to make it a settable property so it can be enabled selectively, rather than as a mount option. I don't ever defragment SSD/NVMe. I think you're better off using bcc-tools' fileslower to evaluate if there are unexpected latencies happening. And quantifying how much defragmenting solves the problem. You can further narrow these down the source of latency with btrfsdist, btrfsslower and biolatency. (There are ext4 and xfs equivalents.) > 5) Having /var as nodatacow puts /var to the same risk level as when /var was > on the ext4 system. If you're wanting to save space, you may want to experiment with compression. And nodatacow means no compression. I think you want to be more selective with nodatacow for very specific reasons and already the top candidate for that already get's nodatacow set automatically by libvirt when a storage pool is created. > > I will be using fstrim -a (to do SSD trims) and I want to user snapper, to > manage the subvolume snapshots. The generations of snapshots for /var and / > will be my objective. > I will be using crontab and a script to take snapshots just before the > script launches "sudo dnf update -y". OK you might want to look at the dnf snapper plugin for this. > This switch to btrfs is a learning experience for me. Fedora is my passion, > From my
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel wrote: > > Hi Chris, > > This weekend past, I did create /opt and /var as subvolumes. For the empty > /opt, it was easy. For /var, it took the live ISO to help with moving > directory /var to subvolume /var. Recommended reading. https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout The "flat" method for /var means it actually gets swapped from the 'old dir var' to 'new subvolume var' at reboot time via the fstab entry resulting in it being mounted on /var. You can mount the Btrfs file system again at /mnt and clean out the root/var directory. There is a sort of "through the looking glass" experience with "flat" layout. I often regret not giving subvolumes names different from their mount point if I use this layout style. So instead of a "var" subvolume mounted at /var, I'll name it var33 (i.e. var for Fedora 33). Maybe we'll end up using native system mount units for these kinds of things so that fstab isn't overly complicated. The "nested" layout just substitutes in-place, no need for fstab entry. Way simpler. Except if you ever have to do a rollback, and then you have to move it into the new location before the rollback. That isn't always possible or maybe you wouldn't have to rollback in the first place. > I also intend to do the same with /sys on this, my beta system, I'm not sure about this. /sys is a pseudo-filesystem, the contents aren't really on the root file system. > The rational for my doing the subvolume exercise is the following: > 1) Under default installation, each snapfile of root has a copy of all > subdirectories including active /var, and /sys. I noted that /var/log and > /var/cache is rather volatile. My SSD size is 120gigs > 2) By isolating /var, /opt and /sys the root snapshot becomes less bloated. /var contains the rpm database, which means at least /var/lib/rpm is tied to /usr and to some degree /boot. That means any need to rollback one requires rolling back all in conjunction. And yet /var/log is one thing we probably do not want to rollback, and possibly the same for /var/cache in its entirety. But... work-in-progress. > 4) But /var/log is quite active, as is /var/cache. I will be using btrfs > defragment on /var. If it's a (spinning) HDD it might be suited for the autodefrag mount option so long as the workload isn't heavy database use. Autodefrag is intended for light database use like web browsers, and spinning drives. There's a proposal upstream to make it a settable property so it can be enabled selectively, rather than as a mount option. I don't ever defragment SSD/NVMe. I think you're better off using bcc-tools' fileslower to evaluate if there are unexpected latencies happening. And quantifying how much defragmenting solves the problem. You can further narrow these down the source of latency with btrfsdist, btrfsslower and biolatency. (There are ext4 and xfs equivalents.) > 5) Having /var as nodatacow puts /var to the same risk level as when /var was > on the ext4 system. If you're wanting to save space, you may want to experiment with compression. And nodatacow means no compression. I think you want to be more selective with nodatacow for very specific reasons and already the top candidate for that already get's nodatacow set automatically by libvirt when a storage pool is created. > > I will be using fstrim -a (to do SSD trims) and I want to user snapper, to > manage the subvolume snapshots. The generations of snapshots for /var and / > will be my objective. > I will be using crontab and a script to take snapshots just before the > script launches "sudo dnf update -y". OK you might want to look at the dnf snapper plugin for this. > This switch to btrfs is a learning experience for me. Fedora is my passion, > From my studies, I may discover that you are absolutely right to state that I > do not need to make the extra subvolumes. > The advantage I have over you is my career. It is called "retirement". > Retirement comes with spare time to study, to learn, to write code, to > explore, experiment and to share experiences. Cool! Have fun! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
Hi Chris, This weekend past, I did create /opt and /var as subvolumes. For the empty /opt, it was easy. For /var, it took the live ISO to help with moving directory /var to subvolume /var I also intend to do the same with /sys on this, my beta system, Later this week I will install the "release version" on a second drive as a second system, when it is available. The rational for my doing the subvolume exercise is the following: 1) Under default installation, each snapfile of root has a copy of all subdirectories including active /var, and /sys. I noted that /var/log and /var/cache is rather volatile. My SSD size is 120gigs 2) By isolating /var, /opt and /sys the root snapshot becomes less bloated. 3) The /sys directory rarely has changes according to my survey of directory and file dates. One subvolume taken when there is a change is OK for me. 4) But /var/log is quite active, as is /var/cache. I will be using btrfs defragment on /var. 5) Having /var as nodatacow puts /var to the same risk level as when /var was on the ext4 system. I will be using fstrim -a (to do SSD trims) and I want to user snapper, to manage the subvolume snapshots. The generations of snapshots for /var and / will be my objective. I will be using crontab and a script to take snapshots just before the script launches "sudo dnf update -y". This switch to btrfs is a learning experience for me. Fedora is my passion, From my studies, I may discover that you are absolutely right to state that I do not need to make the extra subvolumes. The advantage I have over you is my career. It is called "retirement". Retirement comes with spare time to study, to learn, to write code, to explore, experiment and to share experiences. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
On Thu, Oct 15, 2020 at 8:20 PM Leslie Satenstein via devel wrote: > > I am looking to some performance considerations for the /etc/fstab btrs > default config generated by anaconda. > > It appears to have created a subvol for root (root00) and for home (home00). > I would like to put in /opt with it's subvol, and to migrate the /var to a > subvol where I can specify nodatacow. You can set nodatacow per filesystem, subvolume, directory, or file. But realize it also means no checksums and no compression. It's nice to have for very specific cases, like VM images, and not have to carve up your drive to optimize for such workloads. But I'm not sure you'll see a dramatic difference in performance outside of those specific cases. Also note that nodatacow needs to be set before the file is created. The main point of making subvolumes is to have different snapshotting policies, and possibly also different send/receive replication strategies (e.g. backup). For example some folks might consider the entirety of /var something that doesn't ver need to be snapshot or backed up. Making it a subvolume means it can have it's own regime, separate from the root subvolume. > Leaving /var as a directory under /, without specifying nodatacow concerns > me as it is a very "busy" directory, and can fill up the root00 subvol quite > quickly. What about nodatacow makes you think root is less likely to fill up, for a given workload? I'm not following what problem you think you might have, that you're trying to avoid. > I tried to create the two subvars, without success. I even went so far as to > examine the grub menu entries. What did you try? How did it fail? > Is this not possible with Fed33 beta? Fedora doesn't apply any limitations. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs question for Fedora 33 beta. How can I add nocow to /var
I forgot to mention, that one way tI can isolate /var is to use a separate partition. Ditto for /opt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Btrfs question for Fedora 33 beta. How can I add nocow to /var
I am looking to some performance considerations for the /etc/fstab btrs default config generated by anaconda. It appears to have created a subvol for root (root00) and for home (home00). I would like to put in /opt with it's subvol, and to migrate the /var to a subvol where I can specify nodatacow. Leaving /var as a directory under /, without specifying nodatacow concerns me as it is a very "busy" directory, and can fill up the root00 subvol quite quickly. I tried to create the two subvars, without success. I even went so far as to examine the grub menu entries. Is this not possible with Fed33 beta? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
