+2
Under review
deleting files via web gui takes forever
I just deleted a folder with 2.6 GB with less than 100 files, and I was looking at a “deleting files” notification for almost 5 minutes. After those 5 minutes I could continue using filerun.
This was the first time I saw this behaviour and I didn't find anything in the logs. Could this have been a simple coincidence and the system running filerun was just experiencing high IO?
Not going to look too deep into this one-time occurrence, just curious if anyone else has seen something similar.
Customer support service by UserEcho
Did you permanentely delete, or to Trash? Is your Trash folder location customized, or default?
Hi Vlad,
thanks for looking into this. There's no need for a lot of debugging as this was a once-off occurrence so far but if you spot something I am definitely doing wrong please point it out.
— I was deleting a folder to trash, not permanently
— the location of the trash folder hasn't been customized.
— I checked my html/customizables/config.php and the only thing related to trash is this line:
I just double-checked why I had the use_safe_move setting in place, and it appears due to this issue: https://feedback.filerun.com/en/communities/1/topics/1545-cannot-move-folder-to-trash
I don't think my files and trash are on different devices or file systems, maybe you can figure it out if I explain more:
Iinside docker-compose.yml I map these volumes:
- /sixer is a zfs based raidz2 (6 disks)
- UserA, Documents, Pictures, Videos are all datasets on this zfs fs
Different Docker mounts are the same as using different storage devices. So the move operation (in the sense of a "rename path") wouldn't work. The FileRun "save move" behavior turns "move" into "copy+delete", thus taking long time to actually write a duplicate of the entire data before deleting.
It would be more efficient to symlink "/sixer/UserA" inside "/sixer/docker/filerun/data/user-files" and just use only one Docker volume instead of two.
Ah, I see, thanks for clarifying.
So my best choice would be to use one docker volume, symlink everything I need to be in there and then get rid of the use_safe_move directive which would overall speed up my filerun instance.
Yes.
Though, if the symlink points to a file/folder outside the Docker volume, Docker shouldn't have access to it. So you might still need an additional volume in this case, but only in order for Docker to have permission to access that file path.
This is confusing. What do you mean by " if the symlink points to a file/folder outside the Docker volume"? Of course its outside or I wouldn't need a symlink? Or did I misudnerstand?
Let's talk about real examples:
OLD docker volume mappings:
NEW solution
/sixer/docker/filerun/data/user-files contains two folders:
UserA
UserB
/sixer/docker/filerun/data/userfiles/UserB contains symlinks to Documents, Pictures, Videos.
Filerun has access to all these locations and symlinks as it runs with a user:group combination which allows access to all these locations.
Do you see any problems here?
To be honest I am also wondering about this quote of yours from earlier:
How can that be inside docker? Docker maps folders from outside the container to the inside. The system running inside the container should have no clue that its filesystem is made up from different volume mappings on different file systems.
I would appreciate any hints and links to figure this one out.