On Thu, Nov 15, 2018 at 06:07:46PM +0100, Michael Arndt wrote: > Brian, > > Info, supporting your remark about VFS layer: > > I did a reboot of cluster headnode and after that the remove was „fast“ meanig the typical millsecond /single file to seconds / removal of whole trees. > > What does your intuition say, what could be suspected in the VFS layer / lvm2 layer or below to trigger this problem > ( just to collect ideas, where to search). ? > If the problem only occurs after a period of time like this, I suppose that could suggest some kind of cache effect is contributing to it. You could see if an 'echo 2 > /proc/sys/vm/drop_caches' clears the problem once it occurs, for example, but note that will clear all cached dentries/inodes on the system. I'm not familiar enough with the VFS code and associated caching to speculate much beyond that. Other things that might be interesting are whether other operations on said file take the same amount of time (i.e., an mv before an rm?), whether this is a common filename pattern that sees a lot of create/delete operations (perhaps polluting a lookup cache with unlinked entries? i.e., does changing the filename have any effect?), whether a relocation of the file to another directory changes anything, whether other operations in the same dir on unrelated files show the same problem, etc. Your best bet is probably to collect as much trace data as you can and then possibly report this to the general linux-fsdevel mailing list. Note that if you're using a distro kernel, it might be more appropriate to report an issue with your distro vendor than an upstream list. Brian > Caused by the fact, that the problem was seen also two times before, the issue will reappear after some time. > > Off topic: is the mount option delaylog still functional or obsoleted, because already default behaviour ? > > best > Micha > thx for extremely friendly help >
