How was it determined that btrfs has a high system load due to quotas? What system tools and system analysis were used?

Greetings George

Top (btrfs-cleaner using 100%+ CPU for well over 15 minutes), plus the simple fact that every file operation, like less on a log file took ages to complete.

Filr uses BTRFS for the root partition as that is the default that SLES uses (See https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-filesystems.html)

I am not aware that Filr uses any of the features, though the OS might

You also have the option for format the vastorage and var partitions as btrfs when you do the initial install of the Filr appliance

Robin.

Thanks. Of course I was aware it uses BTRFS as Filesystem for / ;)
I was just wondering if there's a specific reason for it, like e.g snapshots or quotas being utilized, but I guess that's not the case. I wish it wouldn't use it in that case.
 
Thanks.
Massimo

The load of 100 % and more by the cleaner process is described in the knowledge database at SUSE. As a first help it is described in a document to switch off Quotas. This is only the first step, SUES says that a call should be opened to find the real reason. From field experience I can say that the "snapper" and snapshots play a role for a high load in conjunction with the cleaner process when the root partition of a system has been chosen too small. There is a rule of thumb that says that there should be at least 1.5 times the free space in the root. Unmounting /var / varstorage is a tried and tested method, removing the quotas usually only helps in the short term. The snapper has helped me out of a situation many times when updates went wrong.

I know it's described there, it's legend. I routinely disable quotas and snapshots on every BTRFS system I've been forced upon because without them being actively used any monitored, they *WILL* create issues. It's not a matter *if*, it's just a matter *when*.-

We have snapshots in VMware for that. I rather use well established methods that *I* (or the customer) decided to use, instead of being forced to fight knowingly unreliable technology I have no intention whatsoever to ever utilize.

And the size of the root partition is determined by the OVA, as you know.

Hi Robin,

"BTRFS for the root partition as that is the default that SLES uses", right, but this is not mandatory from SuSE.

Simple question, does BTRFS bring an added value on appliance root file system ?
If the answer is yes, then the documentation should mention some maintenance tips, at least, concerning snapshots management.(see below)
If the answer is no, then use another proposed and supported FS.
Note : I have never heard(yet) about the use of a snapshot rollback on a Filr server.

A few month ago I ran on an issue were Filr server was completely unstable, and finally find out Snapper snapshots sere using more than 12GB,
OT support was unable to help me out on that one, they told me the disk was full but were unable to tell me where...
only advising to delete some file to free space...
While digging the server I was finally able to delete several  huge snapshots.

These are some useful command I would share with you.
This command will show you the amount and size for each snapshots, they automatically triggered while e.g. updating the server (zypper command, e.g.) or "timeline", these are automatically scheduled by snapper ( I do not know the reason yet).

List current snapshot, with snapshot id, size, time stamp and "reason" of snapshots(takes a while to display list)

#snapper list

Delete a snapshot or series of, here we will delete from id 7 till number 35

#snapper delete 7-35

Disable timeline snapshots

#snapper -c root set-config "TIMELINE_CREATE=no"

I would advice to keep snapshot generated after an update and  then manually clean them up if everything is OK.

Note : think twice before deleting snapshot, there is no "undelete" command !