KMountPoint::probablySlow and cifs mount points

[Mark Gaiser]

On Sun, Nov 24, 2013 at 10:09 PM, Albert Astals Cid <aacid at kde.org> wrote:
> El Diumenge, 24 de novembre de 2013, a les 19:42:25, Mark Gaiser va escriure:
>> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid <aacid at kde.org> wrote:
>> > In Okular we just got bug
>> > https://bugs.kde.org/show_bug.cgi?id=327846
>> > PDF Render time is unreasonably slow over cifs on high latency (WAN)
>> > network connections
>> >
>> > Basically the issue is that poppler is quite read-intensive over files,
>> > reading them over and over, and since the file is "local but really
>> > remote" it takes ages to render for big files.
>> >
>> > The only solution i can think of is doing a local copy and then working on
>> > that.
>>
>> That would work with small files (< 10 MB) but will get you into
>> trouble for bigger files.
>
> Why?
See my example below.
>
>> You can't - or shouldn't - do that in an automated manner. If the user
>> manually copies the file and then opens it in a pdf reader: fine. Just
>> don't auto copy the file. So you can probably give the user a popup
>> suggesting them to copy the file to his local drive?
>
> Why? If you open a huge file by smb:// it'll copy it to the local file anyway,
> so why should not we copy it?

Right. True but should it be like that?
Lets take playing a movie from smb as an example. If you do that now
in for example mplayer then kde will simply copy the movie to your
local drive and start playing it. But should that be the case? I
consider it a massive usability bug. One that isn't easy to fix. If
you would mount the same share as cifs then the system "thinks" it's
local and just plays the movie without copying.

That is how it should be. Copying to your local system is a nasty
workaround which should imho be prevented.

This is especially a big issue when you want to watch a movie of -
lets say - 10GB in size. I have that very often and it sucks that it's
being copied. So i find myself mounting that network drive when i want
to see something since that is both faster and prevents needless
copies.

>
>>
>> > I saw KMountPoint::probablySlow that says
>> >
>> >     /**
>> >
>> >      * Checks if the filesystem that is probably slow (nfs mounts).
>> >      * @return true if the filesystem is probably slow
>> >      */
>> >
>> > And then returns true if the the filesystem type of the mount is nfs,
>> > autofs or subfs.
>> >
>> > Any objection to replacing
>> >
>> >     /**
>> >
>> >      * Checks if the filesystem that is probably slow (nfs mounts).
>> >      * @return true if the filesystem is probably slow
>> >      */
>> >
>> > to
>> >
>> >     /**
>> >
>> >      * Checks if the filesystem that is probably slow (network mounts).
>> >      * @return true if the filesystem is probably slow
>> >      */
>> >
>> > and adding cifs to the list of mounttypes that are "probablySlow"?
>>
>> It's not my place to object since the code isn't mine. Yet i do
>> disagree. Everything becomes slow if you mount it over a WAN. Whatever
>> it is. It also depends on your internet connection and where you're
>> connecting to. Saying smb, nfs or cifs is slow - per se - is plain
>> wrong. All of those are "likely" fast if you mount them locally.
>
> That's why it's called "probablySlow", no?

It's probably slow if you use a slow connection. It's "probablyFast"
if you just use it as in internal network. Not over the internet. And
i think you should assume that most people mount those drives through
an internal network. The exception is mounting through the internet.

>
>>
>> > Or anyone has a better suggestion to fix this issue?
>>
>> What should be done is detecting is the target is mounted via a slow
>> connection. So if it's mounted via the internet then "probablySlow"
>> should return true. On the other hand, i don't know if such checks are
>> in place and if they are not there, how to implement them.
>
> How are you going to define "slow connection"?

Ping and measure latency? Or use networkmanager to discover if a
connection is made through a line that is also having the internet
connection? If so then the connection is made via internet thus
"probablySlow".

I don't know if those ideas are possible, but is sounds plausible.

>
> Cheers,
>   Albert
>
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Just my 5 cents.
>