[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KMountPoint::probablySlow and cifs mount points
From:       Mark Gaiser <markg85 () gmail ! com>
Date:       2013-11-25 12:54:38
Message-ID: CAPd6JnFrLt7mXGpgqatmZhBjgZTbPXrU2+Ev1bBsQg6Gf1+qVg () mail ! gmail ! com
[Download RAW message or body]

On Mon, Nov 25, 2013 at 10:45 AM, Aurélien Gâteau <agateau@kde.org> wrote:
> Le dimanche 24 novembre 2013 19:42:25 Mark Gaiser a écrit :
>> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid <aacid@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.
>> 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?
>
> I disagree with that: I believe the use should not have to worry about this
> and trust the application to be smart and do whatever is most appropriate to
> deliver the best result instead.

No. Here's why (again, but more detailed).
1. People don't expect the file to be copied. Just to be opened.
2. If you follow this route, you are already in the "probablySlow"
path thus it copies over a likely slow connection. Have you though
about the added bandwidth that takes? Not everyone is on unlimited
insanely fast internet lines. Some people have bandwidth caps. For the
record: i'm not one of those.
3. Copying it leaves the user puzzled as to where "the smart
application" might have copied the data to.
4. Copying also slowly eats your disc space. When i had this nasty
surprise with a 10GB movie i wanted to play - not copy! - i was
welcomed by a disc full error..
5. And what if i open an PDF (in this example) just to see the first
page and then close it again. That is a needless copy.
6. You could even argue that you might violate intellectual property
stuff. Insane? No! For a past employer i had to read PDF files, but
was by no means allowed to copy them due to IP infringement if i did.
So i had to use an application that doesn't make caches, temp files or
copies internally and really just opens it, shows the data to me and
closes it. In other terms: no physical copy of that file was allowed
to be made without explicit permission of some management layer.

You open up a whole can of issues if you follow the "just copy and be
done with it" route. An app should _never_ copy a file to display it
or open it. It should either just open it and be slow as hell or _ask_
the user really nicely if it can copy the file to his local system for
improved performance.

All i'd like to do is very thoroughly talk the idea out of you that
you can just automatically copy files if a connection is seemingly
slow. If an app does that, it should ask first!

>>
>> > 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.
>
> It really depends on the definition of "fast". I made measurements some time
> ago for my home setup (so LAN only): NFS over a 100Mbit connection was almost
> as fast as local access. Same NFS over a wifi connection capped at 3MBytes.
> That is much slower and can be worth adjusting the code path to take into
> account this difference.
>
>> > 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.
>
> Would be nice, but sounds difficult to do reliably, especially without
> generating too much traffic.

I doubt that.
If you do a ping or those kind of network tricks to figure out it's
speed. Then yes, it will cause some traffic. And i don't think you
should go for that.

What is possible - technically - is detecting if the connection is
made through a wired internet connection, local network connection or
even the same with wireless. Based on the "connection speed" that
NetworkManager is just showing you, you can make a first guess if the
connection is slow or fast. If you connect to an ip within the local
IP ranges (10.x.x.x, 192.168.x.x etc..) then you can assume a fast
local connection. Sure, that doesn't "need" to be true because you can
also have VPN setups where ip's might seem local, but are in fact
connected through the internet. There is no way to figure that out in
a sane manner so they would have "false positives". That doesn't
matter much. Those are the exceptions anyway. For other connections
you can first do an nslookup (or trace route) to see if they are local
or remote. Even then you can - yet again - argue that it's not going
to work if you have a local dns server.. Again not important because
those are the exceptions.

>
> I think all network-based file systems should be handled the same when it
> comes to the "probablySlow()" method: even if their performances vary, they
> will all perform worse than a local filesystem when the network they operate
> on is not at least a 100Mbit wired LAN connection. Of course exceptions exist:
> people do use wired connections, but since it is complicated to detect this,
> we need to optimize for the most common case. I think it is safe to assume
> that with tablets and laptops (some of them without ethernet ports) becoming
> more and more common, we have more and more people going wireless, so it's
> better to assume all network-based fs to be slow.
>
> Aurélien
[prev in list] [next in list] [prev in thread] [next in thread]