Changing mount options on install vs. after install?

[jfabernathy]

I've seen some blogs about Installing *buntu with btrfs and they modify install files so the mount options and fstab file is setup prior to installation. They modify the files:
/usr/lib/partman/mount.d/70btrfs and /usr/lib/partman/fstab.d/btrfs. I'm not sure as to why they do this because from what I've learned you can change the mount options after install. The only thing I see different is if you install with compress=zstd then the installation files are compressed. Not sure if that's good or bad. It certainly could hurt performance loading Linux commands and programs.

The links to one of the blogs is https://theduckchannel.github.io/pos...install-ubuntu

Any thoughts on this??

[GreyGeek]

What I see in that blog is the editing of the installation script to select the zstd compression algorithm over the default lzo algorithm. The last part of that blog described configuring snappy, the btrfs backup tool.
Here is the latest from the btrfs wiki that describes the use of compression of btrfs file systems. It may surprise you.
https://btrfs.wiki.kernel.org/index.php/Compression

[jfabernathy]

What I see in that blog is the editing of the installation script to select the zstd compression algorithm over the default lzo algorithm. The last part of that blog described configuring snappy, the btrfs backup tool.
Here is the latest from the btrfs wiki that describes the use of compression of btrfs file systems. It may surprise you.
https://btrfs.wiki.kernel.org/index.php/Compression

I was not interested in the part about snapper or the backup tool, but the edited on the files before installation was puzzling. From reading the BTRFS wiki it seems that the compression isn't worth the effort. On my media server I only use about 16GB total and the nvme drive is 500GB. All the media is stored on a 4TB mirror and since most of the media files are some form of compressed audio or video, using BTFS compression may be a waste of time. So even if compression saved you 50%, who cares if it hurts performance, which the wiki says it does.

So maybe I only care about noatime, space_cache-v2, and autodefrag which can all be added to fstab after you install? Or am I missing something?

[jlittle]

Thank you, I learned where ubiquity gets "@" and "@home"; that might be useful. (I had to look inside filesystem.squashfs inside a Kubuntu iso.)

IME, not in a btrfs context, zstd is much better than zlib, as it compresses smaller and is faster to decompress. zstd claims it can decompress faster than the i/o bandwidth of typical storage.

I agree that if your data are mostly media files, compression would be a waste of time. If you had some significant amount of other data that's compressible you can set compression on the directories that data will go.

Perusing zfs media, I've seen it suggested that compression improves CPU performance, because fewer data need to be copied about.

[oshunluvr]

Thank you, I learned where ubiquity gets "@" and "@home"; that might be useful. (I had to look inside filesystem.squashfs inside a Kubuntu iso.)

IME, not in a btrfs context, zstd is much better than zlib, as it compresses smaller and is faster to decompress. zstd claims it can decompress faster than the i/o bandwidth of typical storage.

I agree that if your data are mostly media files, compression would be a waste of time. If you had some significant amount of other data that's compressible you can set compression on the directories that data will go.

Perusing zfs media, I've seen it suggested that compression improves CPU performance, because fewer data need to be copied about.

I asked for a change to this behavior - specifically instead of forcing @ and @home - to allow the user to optionally set a non-default subvolume name, or even use only a single subvolume. I have had up to 7 installs on a single btrfs file system and the hoops one has to jump through to rename the installation subvolumes can be a pita. However, my suggestion was summarily and soundly rejected. I now always change the subvolume names after installation so I can add another install in the future.

As far as the compression comments, what I read said drive access speed is faster with compression because disk seek-read/write is the bottleneck - i.e. slower than the compression/decompression.

[jlittle]

I asked for a change to this behavior - specifically instead of forcing @ and @home.

If I get time, and I'm feeling reckless, I'll experiment with editing the scripts in /usr/lib/partman. It might just need something like (totally untested)

sudo sed -i -e 's/(@([^h])/@newroot\1/' -e 's/@home/@newhome/' /usr/bin/partman/**/*btrfs*

[oshunluvr]

If I get time, and I'm feeling reckless, I'll experiment with editing the scripts in /usr/lib/partman. It might just need something like (totally untested)

sudo sed -i -e 's/(@([^h])/@newroot\1/' -e 's/@home/@newhome/' /usr/bin/partman/**/*btrfs*

I never really thought about that. I could easily write a bash script using sed to make the necessary edits. Great idea!

[jlittle]

I haven't done an install yet, but the command and a mistake and needs a tweak because some occurrences of @ are at the end of their lines:

sudo sed -Ei -e 's/(@([^h]|$)/@newroot\1/' -e 's/@home/@newhome/' /usr/lib/partman/**/*btrfs*

[GreyGeek]

I asked for a change to this behavior - specifically instead of forcing @ and @home - to allow the user to optionally set a non-default subvolume name, or even use only a single subvolume. I have had up to 7 installs on a single btrfs file system and the hoops one has to jump through to rename the installation subvolumes can be a pita. However, my suggestion was summarily and soundly rejected. I now always change the subvolume names after installation so I can add another install in the future.....

Too bad it was rejected. IMO, for most users, the use of @ and @home doubles the work of backing up and restoring subvolumes.
Also, as I've mentioned before in other posts, the assumption that any @ snapshot would work with any @home snapshot is erroneous, and will always be as long as app developers divide their application files between @ and @home. So creating snapshots of @ and @home requires that they be created at the same time and given the same date-time stamp to create a matched pair. Having merged @home into @ several years ago I now have to snapshot only @ and send it to my external storage.