Caja slows down under Bedrock because of etcfs process
 

I installed Bedrock over Artix linux and I added the stratum Devuan (unstable/ceres).
I noticed that Caja file manager freezes for a while and the process etcfs "burns" one of my 4 cores at 100% at the same time. I don't know how to fix that, but I found a workaround that looks nice so far:
Just uninstall caja under Artix (or your primary distro) and install it under Devuan (or one of your strata).
To launch it from any dock, then copy the /bedrock/strata/devuan/usr/share/applications/caja.desktop to ~/.local/share/applications/caja.desktop and change the "exec" line with "Exec=brl strat devuan caja"
I guess this kind of workaround may work with any other file manager or even any other application that slows down under Bedrock.

Not that it matters at this point, but I am curious...

Because uninstalling Caja from all but one stratum worked for you, I wonder if using "strat -r" would have been an alternate solution?

On the other hand, the way you do it now saves space taken up by duplicate programs. :D

Thanks for your quick answer !
I appreciate that because I just discovered Bedrock with enthusiasm, but I can see that community is restricted.
The problem is fixed about Caja, but I have the same kind of problem every time I use the menu "save as" in any app. A window is open, I usually choose the folder ~/Documents where there are plenty of personal files and it takes long minutes to complete the display the list of them. I tried to apply the same fix with kwrite (uninstalling it in Artix, installing it in stratum Devuan), but it is still slow.
More generally, if I "move" all my apps from Artix to Devuan, I could use a simple Devuan and the benefit of Bedrock is reduced to zero.
I have the same problem when a folder/file choosing window is open, for example adding a file in a website open with Brave.
A workaround is:
- read: always copy files to /tmp before picking them in any app
- write: always save them to /tmp in any app then move them to ~/Documents
But it is not very convenient.
Otherwise, the process "etcfs" occupies 20-30% of my cpu while I am stuck.
Is there a way to control it ?

On Bedrock, accessing files in /etc is slightly slower than traditional distros. Normally this overhead is negligible, but it can add up if a process accesses /etc a tremendously large number of times. For example, if on a given machine Bedrock's overhead is one millisecond (something not normally noticeable by human) a thousand requests will add up to a full second (which is noticeable).

It is not obvious to me why displaying ~/Documents would result in excessive requests to /etc. My guess is the software in question has a bug in it which is minor enough not to be noticeable on non-Bedrock systems, but adds up to the point where it is noticeable on Bedrock systems.

I can't reproduce the issue with the information provided. If you can capture the misbehaving software with strace, or provide more detailed instructions such that I can reproduce the issue, we can probably track down what's going. We might be able to then bug report or upstream a fix to the software in question to get them to stop requesting /etc excessively.

I noticed that more or less every operation makes one or more etcfs process loaded up yo ~30% at max. This includes app launching, opening "saveas" windows, running Windows apps through wine. So this problem doesn't occur on a particular app. It makes Bedrock based on Artix most of the time a little less smooth than Artix alone, sometimes very less. It is particularly annoying when multitasking.
Using the strat devuan caja version is more efficient than the strata artix one, but it is not very smooth. It is surprising that browsing in folders and files in caja on a webdav server is faster than on a local SDD.
When running mkvmerge, etcfs processes are low but one of them is growing up at the end of the task, maybe corresponding to I/O operations.
It looks like that the problem occurs when read/write files tasks are run, but I may be wrong.
Is there a way to speed up this access to /etc ?
Should I run strace at the same time the process etcfs is loading my cpu or at any time caja is open ?
My motherboard and my cpu (Q9550) are not recent.
https://i.imgur.com/AHBS6Mx.png

If this happens with more or less every operation, I'm lost as to what's going on. That's not normal, and I can't reproduce the issue. While Bedrock does have some overhead, it's normally negligible.

etcfs CPU usage isn't necessarily a good indicator of what's going on. When a process wants to do something with/to files, it (normally) can't do it directly, but instead asks the kernel to do it on the process' behalf. Most CPU usage software knows about this, and categorizes the kernel's CPU usage as the process' since it was the process that actually originated the request. On Bedrock, access to /etc goes through etcfs instead of the kernel, and thus etcfs gets blamed for what would normally be considered another process' CPU usage. It could be that etcfs overhead is a problem, or it could just be confusion around CPU usage reporting and unrelated to the issue.

There isn't any obvious way to speed up etcfs in Bedrock Linux 0.7.x. It's already fairly optimized for the given architecture. I have ideas to make it faster in 0.8.0, and possibly optionally remove it entirely in a following update, but it'll be a while before those are ready.

My proposal with strace just needs to log what the given program is doing while it's being problematic. If the log includes a very large number of requests to /etc that would both explain what's going on and give us a lead on how to fix it. However, that assumed it was just one program being a problem - if it's more or less everything, it's unlikely to be caught in any given strace log.

While I haven't done so recently, I normally test major releases on some old Asus Eee PC laptops and Raspberry Pis, which I expect aren't much if at all stronger than your Q9550. While I do see CPU usage spike if I hammer /etc, if I don't I don't normally notice Bedrock's overhead.

However, all of the machines I test do have SSDs. I don't have any mechanical spinning harddrive machines any more. If you have a mechanical spinning harddrive, that might explain the issue.

I wonder if Caja (btw, I never used that program, don't even know what it does) is getting file times. I think I recall something a while back where there were two functions involving time, localtime() and localtime_r() and one of the two might access /etc every time, causing etcfs to do more work?

I have 2 HDDs in my box, but the problem occurs with my SSD on which my system is installed and where my home is.
What program I should strace when I open a "save as" window for example in Brave ? I suspect that the CPU consuming program is more related with KDE (in my case) than Brave. Sorry if my question is stupid, but I never used strace.