05-07-2020, 08:03 PM
@Tim Curtis
Hi, Tim.
It's the rsize= parameter in the Advanced section of the Configure>Library>Music Source panel for SMB shares.
I'm not sure what a max number ought to be. I haven't gathered enough data [1] from my own system and the InterWeb is full of (mis)information depending on the NAS, the OS, etc.
Here's what the man page for current Rasbian's mount.cifs says:
I arbitrarily chose 262144 because it had cropped up in a discussion elsewhere of a problem someone was having with (I think) Red Hat Linux. Since the actual size is negotiated during a mount it would seem important only to make sure it's big enough to not limit what Raspbian and Synology (or whatever NAS is in play) can negotiate.
There's no such thing as a free lunch, of course; I'm sure there's a downsize to having the negotiated number be too big. I don't know what it is.
Regards,
Kent
[1] e.g., keep bumping the number and see what size is actually negotiated during the mount.
Hi, Tim.
It's the rsize= parameter in the Advanced section of the Configure>Library>Music Source panel for SMB shares.
I'm not sure what a max number ought to be. I haven't gathered enough data [1] from my own system and the InterWeb is full of (mis)information depending on the NAS, the OS, etc.
Here's what the man page for current Rasbian's mount.cifs says:
Code:
rsize=bytes
Maximum amount of data that the kernel will request in a read
request in bytes. Prior to kernel 3.2.0, the default was 16k,
and the maximum size was limited by the CIFSMaxBufSize module
parameter. As of kernel 3.2.0, the behavior varies according to
whether POSIX extensions are enabled on the mount and the server
supports large POSIX reads. If they are, then the default is 1M,
and the maximum is 16M. If they are not supported by the server,
then the default is 60k and the maximum is around 127k. The rea‐
son for the 60k is because it's the maximum size read that win‐
dows servers can fill. Note that this value is a maximum, and
the client may settle on a smaller size to accommodate what the
server supports. In kernels prior to 3.2.0, no negotiation is
performed.
I arbitrarily chose 262144 because it had cropped up in a discussion elsewhere of a problem someone was having with (I think) Red Hat Linux. Since the actual size is negotiated during a mount it would seem important only to make sure it's big enough to not limit what Raspbian and Synology (or whatever NAS is in play) can negotiate.
There's no such thing as a free lunch, of course; I'm sure there's a downsize to having the negotiated number be too big. I don't know what it is.
Regards,
Kent
[1] e.g., keep bumping the number and see what size is actually negotiated during the mount.