Netzwerktimeouts mit Samba+ZFS

carbuncle

Rainbow Six
Moin,

Ich habe folgendes Problem: Bei der Datenübertragung von Windows/Linux kisten auf den Fileserver bekomme ich timeouts bei einer größeren Anzahl an Dateien (jpegs von Digicam). Man kann dann wiederholen klicken und nach einer kurzen Zeit geht es wieder.

Die Konfiguration des Fileserver:
Biostar A68N-5100 (4 core onboard cpu passiv gekühlt)
6GB Ram
2x1,5TB Platten im zfs Mirror.
Freebsd 13

Grundsätzlich ist der Datentransfer schnell, bis das Ram aufgebraucht ist. Dann swappt er auch manchmal ein paar MB.

16GB Ram sind jetzt bestellt. Die Frage ist aber ob das mein Problem lösen würde. Weil zfs würde ja dann einfach noch mehr Ram als Cache benutzen und das Problem würde einfach später auftreten. Oder irre ich da?

Vielen Dank schonmal.
 
Weil zfs würde ja dann einfach noch mehr Ram als Cache benutzen und das Problem würde einfach später auftreten. Oder irre ich da?
Genau. Der RAM verschiebt dass Problem nur nach hinten. Das Grundproblem ist, dass Netzwerkdateisysteme wie SMB oder NFS synchron sind. Der Server schickt am Ende jeder Operation ein fsync() ans Dateisystem, damit alle gegenüber dem Client bestätigten Operationen sicher ausgeschrieben sind. ZFS mag das nicht besonders, weil es das Dateisystem zwingt, alle im Flug befindlichen Transaktionen auszuschreiben. Früher tat es echt böse weh, mit OpenZFS sind die Auswirkungen nicht mehr ganz so schlimm, aber immer noch deutlich spürbar. Die einzige wirkliche Lösung ist ein Log-Device in Form einer billigen, kleinen S-ATA SSD. Alles andere, wie das Dateisystem zur asynchronen Operation zwingen, ist Gebastel und geht auf Kosten der Datensicherheit.
 
Man kann Samba selbst auf async io umstellen, dann hättest du auch kein Gefummel am Dateisystem. Ob das ne gute Idee ist muss man immer vom Anwendungsfall entscheiden, aber gerade wenns nur um das Raufkopieren von Daten geht, würde ich da keine Kopfschmerzen haben.

Ich wär mir aber nicht sicher ob da nicht noch was anderes im Argen liegt bei dir. Bei ner normalen GBit Leitung sollten deine Platten auch synchron problemlos Jpegs schreiben können (aus sicht eines Filesystems sind das ja nicht wirklich kleine Datein). Was mir da so in den Sinn kommt: Fragmentierung vom ZFS Pool? Falsche Sektorsize die aus jedem write ein read-modify-write machen?
 
Grätscht da eventuell die Indexierung/Thumbnail-Generierung mit rein, sodass er sich in den timeout läuft? Ab jedem einzelnen neuen JPG-File Thumbnails erneut im Ordner erneut generieren oder so?

Macht es einen Unterschied, ob du die JPGs erst von der Cam auf den PC lokal ziehst und dann rüber?
 
Meine smb4 config sieht folgendermaßen aus:

# Samba 4 config
#
# author: j0b314
# date: 2021-04-21


[global]
workgroup = WORKGROUP
server string = Samba Server Version %v
netbios name = fswps01
wins support = no
security = user
passdb backend = tdbsam

# For better throughput
#use sendfile=true

# Enables Shadow Copies under windows (VSS)
vfs objects = shadow_copy2, zfsacl
shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = vss-%Y%m%d%H%M%S
shadow: localtime = yes

# Todo a shadow copy, e.g.:
# zfs snapshot zroot/public@vss-$(date +%Y%m%d%H%M%S)


# Enable home directories (e.g. \\fswps01\j0b314)
[homes]
comment = Home directories
browseable = no
writeable = yes

# Public folder for documents, etc.
#
[public]
path = /zroot/public
comment = Place for commonly used files
valid users = @smbusers
writable = yes
browsable = yes
read only = no
guest ok = no
public = no
create mask = 0666
directory mask = 0775

# Folder for digital camera pictures
#
[pictures]
path = /zroot/pictures
comment = Place for pictures
valid users = @smbusers
writeable = yes
browseable = yes
read only = no
guest ok = no
public = no
create mask = 0666
directory mask = 0775

# Just music...
#
[music]
path = /zroot/music
comment = Music share
valid users = @smbusers
writeable = yes
browseable = yes
read only = no
guest ok = no
public = no
create mask = 0666
directory mask = 0775

# Video files
#
[media]
path = /zroot/media
comment = Place for media like movies
valid users = @smbusers
writeable = yes
browseable = yes
read only = no
guest ok = no
public = no
create mask = 0666
directory mask = 0775

Da ist eigentlich nichts schlimmes drin.

Der mirror wurde bei der Freebsd 13 Installation generiert:

j0b314@fswps01:/usr/local/etc $ zpool status
pool: zroot
state: ONLINE
scan: scrub repaired 0B in 01:11:29 with 0 errors on Fri Jun 25 11:31:03 2021
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p4 ONLINE 0 0 0
ada1p4 ONLINE 0 0 0

errors: No known data errors

Die Sektorgröße sollte auch stimmen:

j0b314@fswps01:/usr/local/etc $ doas fdisk /dev/ada0
Password:
******* Working on device /dev/ada0 *******
parameters extracted from in-core disklabel are:
cylinders=2907021 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=2907021 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
start 1, size 2930277167 (1430799 Meg), flag 0
beg: cyl 0/ head 0/ sector 2;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
j0b314@fswps01:/usr/local/etc $ doas fdisk /dev/ada1
Password:
******* Working on device /dev/ada1 *******
parameters extracted from in-core disklabel are:
cylinders=2907021 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=2907021 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
start 1, size 2930277167 (1430799 Meg), flag 0
beg: cyl 0/ head 0/ sector 2;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Die Platten werden beim boot folgendermaßen erkannt:

Aug 30 11:56:07 fswps01 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
Aug 30 11:56:07 fswps01 kernel: ada0: <SAMSUNG HD155UI 1AQ10001> ATA8-ACS SATA 2.x device
Aug 30 11:56:07 fswps01 kernel: ada0: Serial Number S2HEJ1BB200248
Aug 30 11:56:07 fswps01 kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Aug 30 11:56:07 fswps01 kernel: ada0: Command Queueing enabled
Aug 30 11:56:07 fswps01 kernel: ada0: 1430799MB (2930277168 512 byte sectors)
Aug 30 11:56:07 fswps01 kernel: ada0: quirks=0x1<4K>
Aug 30 11:56:07 fswps01 kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
Aug 30 11:56:07 fswps01 kernel: ada1: <SAMSUNG HD155UI 1AQ10001> ATA8-ACS SATA 2.x device
Aug 30 11:56:07 fswps01 kernel: ada1: Serial Number S2HEJ1BB200252
Aug 30 11:56:07 fswps01 kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Aug 30 11:56:07 fswps01 kernel: ada1: Command Queueing enabled
Aug 30 11:56:07 fswps01 kernel: ada1: 1430799MB (2930277168 512 byte sectors)
Aug 30 11:56:07 fswps01 kernel: ada1: quirks=0x1<4K>

Es sind halt noch Festplatten und keine SSDs. Die Netzwerkanbindung läuft mit vollen 1GBit. Ich kann da auch etwas über 100 MB/sec rüberkopieren. ZFS cacht dann fleissig im RAM zwischen. Wenn die Daten dann auf die Platten geschrieben werden kann es passieren dass das kopieren der Daten stockt.
 
Die J
Grätscht da eventuell die Indexierung/Thumbnail-Generierung mit rein, sodass er sich in den timeout läuft? Ab jedem einzelnen neuen JPG-File Thumbnails erneut im Ordner erneut generieren oder so?

Macht es einen Unterschied, ob du die JPGs erst von der Cam auf den PC lokal ziehst und dann rüber?
Die Jpegs werden von einem Laptop/SSD direkt übers Netzwerk kopiert. Die kommen nicht von einer digicam. Sie sind schon da.
 
Das mit 'nur Festplatten' ist vollkommen in Ordnung, die reichen locker für den Einsatzzweck. Auch die smb4.conf sieht sauber aus.

Passiert das nur mit Bildern oder auch bei anderen Files? Wenn ersteres, dann würde ich auf den Clientsystemen alles was nach Voransicht/Quickansicht/Thumbnails aussieht mal deaktivieren.
 
Also ich hab jetzt mal getestet bei mir (11.7 GB / 7100 JPEGS) auf ein ZFS Raidz1 mit 4 SATA2 Platten: Übertragung schwankt zwischen 50 und 70 MByte/s, im Schnitt 60. Für mich ist das für ein GBit LAN mit Consumer-Komponenten ein guter Wert. Aber ich weiß natürlich nicht was bei dir schnell/langsam ist :D

smb.conf dabei komplett default (jetzt zum testen).

Bei dir fällt mir das VSS Zeug auf, kA was das für Auswirkungen hat und wie das bei ZFS funktioniert.
 
Bei mir bricht dass dann so stark ein dass die clients (Win/Lin) einen Netzwerkfehler melden. Unter Windows kann man dann wiederholen klicken und dann gehts weiter. Die Kiste ist dann extrem damit beschäftigt die Daten auf die zwei Platten zu schreiben. Das ist aber halt nur ein mirror und kein raidz1. Bevor er anfängt auf die Platten zu schreiben ist die Performance mit 100 MB/sec halt echt geil ;).
 
Ja aber 2 SATA Platten sollten das doch locker packen. Zeig pls mal "zfs list"

/edit: sry, meinte "zpool list"
 
Egal wie langsam oder schlecht die Komponenten sind, die Übertragungsrate wird und darf irgendwann einbrechen, sobald etwas 'flaschenhalst'. :D Nur der timeout an sich macht mich stutzig, das sollte einfach gar nicht sein. Hattest du das Problem nicht vor einigen Monaten bereits?

Ist da evtl. mit der NIC was nicht richtig konfiguriert? Kannst du Überhitzung ausschließen, knickt die NIC dadurch evtl. kurzzeitig weg? Wie ich das sehe, ist das Ding komplett passiv gekühlt.

Anders: Gibts denn Gemecker irgendwie in den logs, wenn es passiert? dmesg, samba...?

Läuft der powerd/powerdxx? Ein A4-5100 braucht das noch.
Hast du das Kernelmodul 'amdtemp' geladen?

Für dauerhaft in die rc.conf eintragen
kld_list="amdtemp"

Für live laden:
kldload amdtemp

Zum Nachschauen, ob Grillzeit ist ;) :
sysctl -a | grep temp
 
Egal wie langsam oder schlecht die Komponenten sind, die Übertragungsrate wird und darf irgendwann einbrechen, sobald etwas 'flaschenhalst'. :D Nur der timeout an sich macht mich stutzig, das sollte einfach gar nicht sein. Hattest du das Problem nicht vor einigen Monaten bereits?

Ist da evtl. mit der NIC was nicht richtig konfiguriert? Kannst du Überhitzung ausschließen, knickt die NIC dadurch evtl. kurzzeitig weg? Wie ich das sehe, ist das Ding komplett passiv gekühlt.

Anders: Gibts denn Gemecker irgendwie in den logs, wenn es passiert? dmesg, samba...?

Läuft der powerd/powerdxx? Ein A4-5100 braucht das noch.
Hast du das Kernelmodul 'amdtemp' geladen?

Für dauerhaft in die rc.conf eintragen
kld_list="amdtemp"

Für live laden:
kldload amdtemp

Zum Nachschauen, ob Grillzeit ist ;) :
sysctl -a | grep temp
Amdtemp ist geladen, die Temperatur geht auf 75 Grad Celsius. Es könnte natürlich sein dass er runtertaktet (wenn das ding sowas beherrscht). Powerd muss ich mal schauen ob das geladen wird.

Ich werde mal einen Lüfter draufschrauben damit die Temperatur etwas runtergeht.

Die logs werde ich nochmal checken.
 
75°C kann gut die Abregeltemperatur sein. Andererseits ist ZFS nicht wirklich CPU-limitiert und die Kühlung müsste schon miserabel sein, um alleine durch ein wenig Daten per Samba kopieren die CPU zu überhitzen... Ich würde mit noch mal die Zeit nehmen gstat zu beobachten und versuchen zu erkenne, was bremst. Hängen die Platten wirklich am Bandbreitenlimit, also schreiben sie permament mit >150 MB/s oder blockieren sie doch eher an den bei mechanischen Platten lächerlich geringen IOPS? IOPS wären ein deutlicher Hinweis, dass es sich lohnt im Bereich synchronem schreiben Näher zu schauen.
 
75°C kann gut die Abregeltemperatur sein. Andererseits ist ZFS nicht wirklich CPU-limitiert und die Kühlung müsste schon miserabel sein, um alleine durch ein wenig Daten per Samba kopieren die CPU zu überhitzen... Ich würde mit noch mal die Zeit nehmen gstat zu beobachten und versuchen zu erkenne, was bremst. Hängen die Platten wirklich am Bandbreitenlimit, also schreiben sie permament mit >150 MB/s oder blockieren sie doch eher an den bei mechanischen Platten lächerlich geringen IOPS? IOPS wären ein deutlicher Hinweis, dass es sich lohnt im Bereich synchronem schreiben Näher zu schauen.
Ok gstat schau ich mir genauer an. Aber wieviele IOPs wären denn für Magnetplatten normal?
 
Zwischen 100-250.

Zum Testen:
diskinfo -i ada0
Vollständiger Test:
diskinfo -citv ada0

gstat ist quasi live, zpool iostat -v gibt immer nur Schnittwerte ab dem Boot wieder.
j0b314@fswps01:~ $ doas diskinfo -i ada1
Password:
ada1
512 # sectorsize
1500301910016 # mediasize in bytes (1.4T)
2930277168 # mediasize in sectors
4096 # stripesize
0 # stripeoffset
2907021 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
SAMSUNG HD155UI # Disk descr.
S2HEJ1BB200252 # Disk ident.
ahcich1 # Attachment
No # TRIM/UNMAP support
5400 # Rotation rate in RPM
Not_Zoned # Zone Mode

Asynchronous random reads:
sectorsize: 438 ops in 4.207558 sec =
104 IOPS
4 kbytes: 424 ops in 4.166316 sec =
102 IOPS
32 kbytes: 414 ops in 4.304140 sec =
96 IOPS
128 kbytes: 367 ops in 4.501425 sec =
82 IOPS
1024 kbytes: 277 ops in 5.628574 sec =
49 IOPS

j0b314@fswps01:~ $
Kann es sein dass die Dinger einfach super lahm sind?

Coretemp im idle ist bei 65°C.
 
Kann es sein dass die Dinger einfach super lahm sind?
Von dem Blickwinkel ja, aber das ist im zu erwartenden Bereich bei 5400 Umdrehungen.
Vergleichswerte von mir:

5400:
Code:
    sectorsize:       475 ops in    4.148854 sec =      114 IOPS
    4 kbytes:         474 ops in    4.125539 sec =      115 IOPS
    32 kbytes:        457 ops in    4.160750 sec =      110 IOPS
    128 kbytes:       418 ops in    4.340625 sec =       96 IOPS
    1024 kbytes:      253 ops in    6.201096 sec =       41 IOPS
7200:
Code:
    sectorsize:       835 ops in    3.639500 sec =      229 IOPS
    4 kbytes:         795 ops in    3.707961 sec =      214 IOPS
    32 kbytes:        764 ops in    3.612710 sec =      211 IOPS
    128 kbytes:       651 ops in    3.833131 sec =      170 IOPS
    1024 kbytes:      401 ops in    4.493159 sec =       89 IOPS
15000:
Code:
    sectorsize:      1517 ops in    3.288192 sec =      461 IOPS
    4 kbytes:        1500 ops in    3.329557 sec =      451 IOPS
    32 kbytes:       1396 ops in    3.366387 sec =      415 IOPS
    128 kbytes:      1123 ops in    3.526762 sec =      318 IOPS
    1024 kbytes:      462 ops in    4.191107 sec =      110 IOPS
SSD:
Code:
    sectorsize:     72374 ops in    3.005764 sec =    24078 IOPS
    4 kbytes:       71587 ops in    3.005142 sec =    23822 IOPS
    32 kbytes:      22296 ops in    3.016267 sec =     7392 IOPS
    128 kbytes:      6141 ops in    3.060179 sec =     2007 IOPS
    1024 kbytes:      894 ops in    3.473993 sec =      257 IOPS

Was jetzt aber nicht bedeutet, dass du das Problem mit schnelleren Platten gelöst bekommst. Für sequentielles Schreiben (was einen Ordner mit JPGs raufschieben ist), sollten sie so schnell sein, dass es 1GBit abdeckt.
Sind die Platten im BIOS auf AHCI eingestellt? Ohne AHCI gibts nämlich kein NCQ.
Ist der Schreibcache aktiviert auf den Platten?

camcontrol identify ada0 | grep NCQ
smartctl -g wcache /dev/ada0

Aktivieren:
smartctl -s wcache,on /dev/ada0

Was sagt denn gstat nun während dem Kopiervorgang? Je mehr rot bei % gezeigt wird, umso mehr läuft die jeweilige Platte tatsächlich auf Anschlag.
 
Ok heute Morgen bin ich nochmal am kopieren von Dateien und da ist mir das aufgefallen:

Sep 1 08:03:04 fswps01 kernel: re0: watchdog timeout
Sep 1 08:03:04 fswps01 kernel: re0: link state changed to DOWN
Sep 1 08:03:08 fswps01 kernel: re0: link state changed to UP
Sep 1 08:03:08 fswps01 dhclient[5643]: New IP Address (re0): 192.168.178.150
Sep 1 08:03:08 fswps01 dhclient[5647]: New Subnet Mask (re0): 255.255.255.0
Sep 1 08:03:08 fswps01 dhclient[5651]: New Broadcast Address (re0): 192.168.178.255
Sep 1 08:03:08 fswps01 dhclient[5655]: New Routers (re0): 192.168.178.1

Die Netzwerkkarte resettet sich also komplett. Das könnte bei den Windows Clients auch den Timeout erklären.

Der Test läuft im Moment mit Thunar (xfce) auf einer Manjaro Box. Es kann sein dass der ein Connection lost besser verträgt. Ich werde das mal mit einem "cp" testen.

gstat zeigt nichts ungewöhnliches. Die Zahlen werden manchmal rot aber ich kann hier keinen Flaschenhals kopieren. Es werden gerade kleinere JPEGs kopiert, da geht der Write Speed nicht über 45 MB/sec. Ist jetzt nicht ungewöhnlich.

Aber dass re0 sich komplett zurück setzt macht mich stutzig, das darf nicht sein. Die CPU wird 75°C warm, evtl mag das der Realtek Chip nicht. Der hat aber eigentlich genug Abstand zum Kühlkörper.
 
Laut dem bug report:

ist der re driver in GENERIC buggy. Deswegen gibt es einen Port:

Den probiere ich jetzt nochmal aus.

@KobRheTilla Hab deinen Post zu spät gesehen.
 
Interessant. Folgender Effekt nach Nutzung des original Realtek Treibers aus den Ports:

1. Nach übertragen von ca. 50GB bricht die Schreibleistung von 30-50 MB/sec auf 3-4 MB/sec ein.
2. Es kommen keine Watchdog timeouts mehr.
3. gstat sagt die Disks idlen
4. htop/top sagt smbd idled (ca 9% anstatt 30%)
5. Die Kiste swappt nicht.

Was ich auch sehe, wenn ich Daten kopiere und mir mit Thunar parallel die Files auflisten lasse bricht die Rate auch extrem ein.
 
Bin jetzt nicht sicher, ob das ein Problem oder mehrere insgesamt sind, die sich so nur zeigen.

Die Einbrüche klingen irgendwie wieder nach Hitze. Könnte man mal mit einem dicken Ventilator davor gegeprüfen.
Sind die Ports an der Fritzbox zufällig auf Spar/Ecomode? Gibts im BIOS Stromsparmodi einzustellen hinsichtlich der NIC? Da könnte man auch mal schauen und durchprobieren.
 
Zurück
Oben