GNOME Bugzilla – Bug 651641
trash detection is slow with AFS
Last modified: 2018-05-24 13:10:09 UTC
Created attachment 188998 [details] backtrace of Thunar / gvfs / glib trying to stat /afs/.Trash Whenever I browse to a new directory in AFS, Thunar tries to stat /afs/.Trash and /afs/.Trash-$uid. In AFS semantics, immediate sub-directories under /afs have special significance, and the filesystem ends up doing a series of expensive DNS lookups to attempt to find non-existent fileservers for an AFS "Trash" cell. This is exaggerated with slow network links and when AFS has to try a lot of DNS search suffixes. I'm attaching a backtrace of Thunar when it is hung, waiting on the AFS DNS queries to fail. (/home/kdreyer/mydocs is a local symlink to a directory in AFS.) gio can look to see that the filesystem is AFS, and not attempt to stat /afs/.Trash or /afs/.Trash-$uid .
Created attachment 189002 [details] [review] glocalfile.c check for AFS with g_file_query_filesystem_info (In reply to comment #0) > gio can look to see that the filesystem is AFS, and not attempt to stat > /afs/.Trash or /afs/.Trash-$uid . The appropriate place for this logic is probably in gio/glocalfile.c's _g_local_file_has_trash_dir(). I'm attaching a patch against glib-2.28.6 (Fedora 15).
Created attachment 189025 [details] [review] glocalfile.c check for AFS fix strcmp check, and also add an AFS check to g_local_file_trash()
Created attachment 232794 [details] [review] glocalfile.c check for AFS Rebased onto master (330c6c11). No functional change, just corrected line offsets.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/415.