From kde-core-devel Mon Nov 25 18:33:25 2013 From: David Faure Date: Mon, 25 Nov 2013 18:33:25 +0000 To: kde-core-devel Subject: Re: KMountPoint::probablySlow and cifs mount points Message-Id: <3344090.ZX5ba9lVXr () asterix> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=138540443027513 On Monday 25 November 2013 18:23:53 Mark Gaiser wrote: > I would be very much in favor > of killing the "probablySlow" function because we apparently have no > real detection to even know if something is slow or not. All the > protocols mentioned in this thread are fast if you use them on local > area networks. Here comes some historical information from the KDE dinosaur: The initial idea of probablySlow() was to disable some non-essential features that become really slow over the network - such as, in a filemanager or filedialog, opening up .desktop files or .directory files to read icon names; or displaying the number of child items in directories. This was implemented as a huge speed improvement for some NFS/SMB/SSHFS users, see https://bugs.kde.org/show_bug.cgi?id=178678 However users of fast NFS mounts then complained that all their icons were gone - https://bugs.kde.org/show_bug.cgi?id=290666 So what I did, to make everyone happy, was to read these files in a delayed manner, on demand (giving priority to the visible icons and doing the rest in the background - we already had all the support for that, because it's also what happens for mimetype determination). This is even nicer for local directories, if they are very large, or the computer is slow, etc. So it's an improvement for everyone. The child count for a directory, in KDirModel, still uses isSlow(), but should become delayed somehow, for the same reasons as above. Any takers? ;) Once that's gone, only the following code will remain, with a behavior that depends on the type of filesystem (using the more precise alternative for probablySlow() which is KFileSystemType::fileSystemType (*)) : * stat'ing less often when KDirWatch uses the good old stat-polling mechanism (OK, I meant "old", but not "good"; however it's sometimes the only mechanism available, for network mounts, if FAM isn't available). * actually using a different KDirWatch backend for network mounts (FAM, by default, rather than inotify). I suppose we could just try inotify and fallback if it fails to add a watch, though. * skipping the "is there enough size at destination" check in KIO::CopyJob; I wonder why though, is `df` or rather statvfs() very slow for a network mount? Surely it's just one roundtrip to the "server"... * and using a different locking mechanism for nfs mounts in KLockFile, but that's already deprecated in favour of QLockFile where I removed the need for such a file-system-type test. How does all this apply to the issue at hand? I don't know :-) It clearly shows that guessing the speed from the type of filesystem has been proven to be wrong, and that another more flexible solution is better, but I'm not sure what that better solution would be in the case of okular. (Reading the first 100K of the file and measuring how long that takes, sounds like a better idea than additional roundtrips for measuring speed, in any case. What has been read can be kept, rather than thrown away.). But as long as the method exist, cifs should of course be added to it, no issue there. KFileSystemType (*) supports "cifs" already. (*) Note that KFileSystemType is internal to kdelibs in kdelibs4. We just made it public in KF5 but only because of the uses listed above (child count in kio and klockfile in kde4support). I would prefer these two to be fixed so that it doesn't have to be made public. -- David Faure, faure@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5