Caja slows down under Bedrock because of etcfs process
Bedrock LinuxThis forum is for the discussion of Bedrock Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
I noticed that more or less every operation makes one or more etcfs process loaded up yo ~30% at max.
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.
Quote:
Originally Posted by spade2004
Is there a way to speed up this access to /etc ?
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.
Quote:
Originally Posted by spade2004
Should I run strace at the same time the process etcfs is loading my cpu or at any time caja is open ?
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.
Quote:
Originally Posted by spade2004
My motherboard and my cpu (Q9550) are not recent.
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?
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 have 2 HDDs in my box, but the problem occurs with my SSD on which my system is installed and where my home is.
Quote:
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.