Re: webcam viewer?

On 4/1/2024 2:40 AM, Jeroen Belleman wrote:

On 4/1/24 04:19, Don Y wrote:
[...]
 

Common sense -- do you think a list of files in a
directory is produced by reading every file in its entirety in order
to be able to report their individual sizes??

 On Linux, when I do something in a directory that contains a
mountpoint to a remote file system, it often slows to a crawl.

You are *on* an NFS client?  (presumably running Linux?)
And, is there a remote file system ACTUALLY mounted?
The directory *contains* a mountpoint?  Or, *is* a mountpoint?
I.e., in the former case, only the mountpoint references an exported
filesystem.  In the latter, everything in the directory is external.

I suspect it tries to stat() every damn remote file, despite
doing nothing useful with the data. GUI 'open' or 'save' dialogs
are the worst offenders. I have to be careful not to stray into
such directories using GUI programs. This is a nuisance.

nfsstat() reveal anything interesting?  I.e., is the problem with
the RPC subsystem, excess network traffic, etc.?
If the export is from some other (non-Linux) host, does the problem
persist?

A traditonal command shell does not usually misbehave in that
way, fortunately.

I have most of my "remote filesystem" problems with windows clients/servers.
E.g., copying a large portion of a filesystem across the wire often leaves
the connection in a dog-slow mode where you can see individual files being
copied (slowly).
I've not determined if this is a client or server problem.  Nor if it is
related to the number of objects or the volume of data.  I just don't do
it anymore (cuz I'm sure MS isn't going to do squat to fix it!).
[It's likely number of object -- protocol starts -- as I can build a giant
tarball and ship that over reliably (then, unpack it)]