KMountPoint::probablySlow and cifs mount points

[David Faure]

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 at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5