Linux cifs-Mount erzeugt auf Synology-NAS bei vielen kleinen I/O-Operationen hohe Schreib- oder Leselast

Nutzt man ein Synology-NAS mit normalen Samba-Shares mit WIndows-Clients und kombiniert das mit einer Workload, die vornehmlich aus kleinen bis sehr kleinen Lese- oder Schreiboperationen besteht, funktioniert alles vortrefflich.

Erzeugt man nun eine identische Workload (z. B. kleine Leseoperationen durch das Lesen kleiner Chunks beim Betrieb von BitTorrent-Clients zum teilen von Linux-Distributionen) auf einem über cifs gemounteten Share, wird man schnell die immense Leselast auf dem Synology bemerken, die erzeugt wird.

Schlechtes Beispiel

//10.0.0.1/Ubuntu /media/Ubuntu cifs username=benutzer,password=passwort,uid=1000,gid=1000 0 0

In diesem schlechteren Beispiel sind die Werte rsize, wsize und bsize nicht gesetzt. Es greifen also Standardwerte. Die aktuelle man-page zu „mount.cifs“ sagt dazu:

   rsize=bytes
          Maximum amount of data that the kernel will request in a read request in bytes. Maximum size that servers will accept is typically 8MB for SMB3 or later dialects.  De‐
          fault requested during mount is 4MB. Prior to the 4.20 kernel the default requested was 1MB. Prior to the SMB2.1 dialect the maximum was usually 64K.

   wsize=bytes
          Maximum  amount  of  data that the kernel will send in a write request in bytes. Maximum size that servers will accept is typically 8MB for SMB3 or later dialects. De‐
          fault requested during mount is 4MB. Prior to the 4.20 kernel the default requested was 1MB. Prior to the SMB2.1 dialect the maximum was usually 64K.

   bsize=bytes
          Override the default blocksize (1MB) reported on SMB3 files (requires kernel version of 5.1 or later). Prior to kernel version 5.1, the blocksize was  always  reported
          as  16K  instead  of  1MB (and was not configurable) which can hurt the performance of tools like cp and scp (especially for uncached I/O) which decide on the read and
          write size to use for file copies based on the inode blocksize. bsize may not be less than 16K or greater than 16M.

Demnach wäre bei mir per Standard:

rsize: 4MB
wsize: 4MB
bsize: 1MB

Unterschiedliche Kernel und unterschiedliche Distributionen nutzen hier unterschiedliche Werte (RHEL-basiert, Ubuntu-basiert usw.), nehmt die Tabelle also nicht ganz genau und prüft ggf. nochmal spezifisch für euer System.

Geht man von also von einzelnen Leseoperationen um die 128K aus, erzeugt jede dieser Leseoperationen einen 4M-Lesevorgang. Das ist für große Dateien, welche Sequenziell gelesen werden sicher ok, aber für bestimmte Workloads ungeeignet, daher folgt ein besseres Beispiel.

Besseres Beispiel

//10.0.0.1/Ubuntu /media/Ubuntu cifs username=benutzer,password=passwort,uid=1000,gid=1000,rsize=16384,wsize=16384 0 0

Dieses bessere Beispiel ist zwar für die Workload besser geeignet, aber fällt dann dafür bei großen Dateien unter Umständen zurück was die Leistung betrifft. Weiß man das, kann man jedoch damit umgehen.