New mount options in KDE NEON 20.04?

[mr_raider]

Played around with KDE NEON 20.04 testing in VM.

I noticed some new options the installer throws in into fstab:

[FONT=monospace]# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=E161-4D09                            /boot/efi      vfat    defaults,noatime 0 2
UUID=17131a05-d5fa-4a55-b608-2d9417412497 /              btrfs   subvol=@,defaults,noatime,space_cache,autodefrag,discard,compress=lzo 0 1
UUID=17131a05-d5fa-4a55-b608-2d9417412497 /home          btrfs   subvol=@home,defaults,noatime,space_cache,autodefrag,discard,compress=lzo 0 2
UUID=a0c7e546-fd09-4e83-afe7-d4649b0a69cd swap           swap    defaults,noatime,discard 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

[/FONT]

So here we go:

space_cache: that's new I know btrfs check always gave a v1 cache error. Is this to stop it?

autodefrag: I thought Linux didn't need defrag, especially on a rotational drive

discard: I though that was a no-no, and fstrim was the standard way of TRiM

compress=lzo: so by default compression is now enabled? WOn't that slow down writes?

[oshunluvr]

space_cache: that's new I know btrfs check always gave a v1 cache error. Is this to stop it?

I've never seen any errors related to this. The space_cache option will store the free space cache on the disk to make the caching of a block much faster. Without this, Btrfs has to scan the entire tree every time looking for the free space that can be allocated.

autodefrag: I thought Linux didn't need defrag, especially on a rotational drive

All COW file systems have a possibility of some fragmentation. BTRFS automatic file defragmentation, when enabled, detects small random writes into files (64K) and queues them for defragmentation.

discard: I though that was a no-no, and fstrim was the standard way of TRiM

I agree with you here. TRIM is (or should be) enabled by a systemd cron job.
Remove it from fstab and enable the systemd trim:

sudo systemctl enable fstrim.timer

compress=lzo: so by default compression is now enabled? WOn't that slow down writes?

It's not enabled by default or it wouldn't be listed as an option. The installer added it.
LZO is slightly faster than no compression and ZLIB is slightly faster than LZO and ZSTD is even a bit faster.
However, at my last check, ZLIB ZSTD was not supported by GRUB therefore using ZLIB ZSTD on your root file system left it unbootable.
BTRFS is faster with compression because it's done in memory not on the drive. Therefore, the file system is writing and reading LESS from the drive.

Currently, I use these options in fstab:

noatime,space_cache,compress=lzo,autodefrag,

[mr_raider]

Ahh.. what about the ssd flag? I was in teh habit of setting it in my fstab all the time.

I noticed that Lubuntu does the same thing when installing to btrfs partitions. I guess it's the calamares installer's default setting for btrfs. KDE devs had nothing to do with it I guess.

BTW Lubuntu is really coming along nicely. It's now KDE's little brother!

[oshunluvr]

I thought the SSD flag was gone. The system can tell rotating from solid state without being told anymore. Check your mtab and see if SSD remains in your options.

I just checked mine and my nvme drive has SSD in the mount options but not the sata SSDs, Curious.

Also I misspoke slightly up above - edited.

[mr_raider]

An interesting read:

https://linux-btrfs.vger.kernel.nark...autodefrag-etc

Suggests that for partitions with VMs and maybe torrents, autodefrag may not be that useful. They even suggest nodatacow on those partitions.

[GreyGeek]

BTRFS mount parameters can change without warning, so it is a good idea to bookmark the following location:
https://btrfs.wiki.kernel.org/index....#MOUNT_OPTIONS

and check for any changes. Notice that SSD is automatically detected and set. Also, space_cache=v1 is as well, as are several other options.
Here are my fstab settings:

UUID=ce2b5741-c01e-4b3d-b6ba-401ad7f7fcdf /               btrfs   defaults,subvol=@ 0       1
UUID=ce2b5741-c01e-4b3d-b6ba-401ad7f7fcdf /home           btrfs   defaults,subvol=@home 0       2

Checking the "default" value of each setting shows what "defaults" actually sets.
Most mounting options apply to the whole system and thus only the options on the first mount command apply.

[jlittle]

I
... but not the sata SSDs, Curious.

My SATA SSD gets "ssd" and "space_cache" by default; this is documented in man -s 5 btrfs. Note that the options for the first subvolume mount apply to subsequent mounts.

I wonder what /sys/block/sdX/queue/rotational says for your SATA SSDs.

[oshunluvr]

My SATA SSD gets "ssd" and "space_cache" by default; this is documented in man -s 5 btrfs. Note that the options for the first subvolume mount apply to subsequent mounts.

I wonder what /sys/block/sdX/queue/rotational says for your SATA SSDs.

Both my sata ssd's show 0 for rotational but if I attempt to force the ssd option, it comes back as a "bad option". Curious indeed. I wonder if it could e a BIOS or mobo driver thing.

[mr_raider]

What type of data would you consider for the nodatacow option? Virtual machines? Torrent downloads? Google drive sync folder?

Those all get quite a few writes i Guess.

[oshunluvr]

What type of data would you consider for the nodatacow option? Virtual machines? Torrent downloads? Google drive sync folder?

Those all get quite a few writes i Guess.

Specifically, dynamically sized or allocated files - Virtual disks that are dynamically sized instead of a fixed size and swap files. A sync to google drive is just files. Not sure about torrent downloads, that's a good question. I've never had any problems with them though. It's likely that the torrent initializes the whole file (reserves the space) then just fills in the pieces. I don't really think it has to do with the number of times a file is written, rather the way in which it is written to.

"COW" means "Copy-On-Write" which means BTRFS expects to create an entire new file before releasing the space occupied by the original file. Obviously (maybe), this is not how swap files work.

I've been using BTRFS for more than 10 years. The ability to specify an individual file as NOCOW is a relatively new feature and I've never used it. I simply have a swap partition and an EXT4 partition for virtual disks on my desktop (5 drives = plenty of room). On my laptop instead of an EXT4 partition, I just use fixed sized virtual drives.

[mr_raider]

So I did the baremetal install of Neon 20.04. Looks like the mount options are a bit different. autodefrag and space _cache are still there. Compress=lzo is gone. Discard has been discarded.

Interestingly, the swap partition is no longer mounted in fstab, even when specified to the installer. However the swap is active. Has 20.04 taken moved swap to some systemd service?

[oshunluvr]

Last install I did the default was to use the swap partition automatically if it existed. If there's no swap entry at all in fstab, they have indeed made a major change.

I believe Neon 20.04 is using Calamares instead of ubiquity. Could be that they haven't gotten around to configuring that all the way yet.

I just checked my neon VM installation - no swap at all

and no service named swap

[mr_raider]

SO installed Mankaro KDE in a VM.

Slightly different default option for btrfs:

[FONT=monospace]UUID=F99D-2B2E                            /boot/efi      vfat    umask=0077 0 2
UUID=b3a0faec-c3af-4abe-a51d-c21af89cac07 swap           swap    defaults,noatime 0 2
UUID=6507f882-216f-475b-bd67-af1901876d9e /              btrfs   subvol=@,defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 1
UUID=6507f882-216f-475b-bd67-af1901876d9e /home          btrfs   subvol=@home,defaults,noatime,space_cache,ssd,compress=zstd,commit=120 0 2
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

[/FONT]