Other file indexer on unionfs freezes the system

Mjölnir

Mjölnir

Hi all,

I'm posting this here not in Desktop Usage or such because I think this might be a bug of VFS or unionfs mount_unionfs(8). I did not try sysutils/fusefs-unionfs yet. unionfs is clearly documented as beeing experimental... The underlying fs is ZFS, I have
mount -t unionfs -o noatime -o below /src/$dir ~paul/Projects/FreeBSD/src/$dir

I ran into an old KDE baloo bug (KDE's file indexer; reopened that bug) when I mounted three big source trees into my $HOME. The system freezes to be unusable; the workaround is to exclude the unionfs mount points from beeing indexed. IMHO an indexer running at lowest priority and non-root UID must not freeze the system, so I'd say it's not a KDE or baloo bug but one of unionfs.

Before filing a bug report (on FreeBSD), I'd like to ask here for any suggestions and if s/o else ran into such issue.
Thx.
 
Not that I'm going to work on fixing it ... I don't even have time these days to run freebsd-update ...

Just to clarify: When you say "freezer to be...", do you mean the system gets really slow, so slow that it is painful to do work? Does it recover after a while? Does it crash? Does it completely stop? Is the speed of tasks down to 10%, 1%, or unmeasurably slow?

It is relatively easy for a user-space application to slow down a file system to the point that it becomes unpleasant to use. All you need to do is to create 100s of asynchronous IOs or threads or processes, and start file system operations (such as directory reading or fstat or file opening) in lots of places, so that caching of metadata is ineffective. Then the file system will be doing hundreds of disk IOs to serve these requests. But normal disks can do roughly 100 IOs per second, so if someone else wants to get real work done, it will take them roughly a second per operations, which feels really slow to people. The problem with this approach is that it is hard for the file system to recognize and work around: one man's denial-of-service attack is another man's efficient and fast technique.
 
I was able to switch to a text console (CTRL+ALT+F2), but the system was so unresponsive that I could not log in; the login did not respond any keystroke within a minute. So I had no chance to fire up some commands to see what's going on. GUI (KDE) was unusable (no window updates), only the mouse pointer updated correctly. My laptop has no HDD-LED, I was completely in the dark. No crash. The laptop has a SATA-3 SSD, the indexer runs under my UID, nice 19. By default, any known source code and hidden files are excluded, so the indexer most probably reads mostly filesystem metadata and skipped svn's hidden metadata directory (the source trees I mount are FreeBSD-STABLE,CURRENT, and the 12.1-REL sources).
I will try the port sysutils/fusefs-unionfs now.
 
Now I notice this strange difference in filesystem usage: df
Code: 
t450s/src/12-STABLE    145G  1.0G    144G     1%    /src/12-STABLE
t450s/src/12.1-REL     145G  506M    144G     0%    /src/12.1-REL
t450s/src/13-CUR       145G  1.0G    144G     1%    /src/13-CUR
<below>:/src/13-CUR    327G  182G    144G    56%    /home/paul/Projects/FreeBSD/src/13-CUR
<below>:/src/12-STABLE 327G  183G    144G    56%    /home/paul/Projects/FreeBSD/src/12-STABLE
<below>:/src/12.1-REL  326G  182G    144G    56%    /home/paul/Projects/FreeBSD/src/12.1-REL
 
You must log in or register to reply here.
Back
Top