Samba47 und Datei mit 360GB

C

c303

Member
Hallo Community,

da ich in letzer Zeit FreeBSD wieder ziemlich spannend und cool finde habe ich mir einen Backup-Server aus alter Hardware zusammen gebaut. Nichts besonderes, aber für ein zusätzliches Backup für mich genau richtig:

- AMD Athlon(tm) Dual Core Processor 4850e
- 4GB RAM (erstmal)
- 4x 2,5 TB Platten als RAIDZ-1

Ich Synce von einem Windows Rechner per SyncBackFree Ordner und Dateien auf die Freigabe vom FreeBSD die per Samba zur Verfügung gestellt wird. Das funktioniert hier seit Jahren auf andere Geräte ohne Probleme.

Alles funktioniert soweit ganz gut und ich bekomme das Gigabit LAN auch mit >110 MB/s voll. Bis auf eine Datei die 360GB groß ist. Diese wird zwar zunächst komplett kopiert, jedoch bekomme ich am Ende eine Fehlermeldung.

Bevor ich jetzt in den Samba Logfiles(?) nachsehen muss ...

Hat jemand eine Idee an welchen Stellrädchen ich drehen muss?

Ich danke.
 
Der Fehler kommt übrigens auch wenn ich per Windows-Explorer die Datei kopiere. Es ist also erstmal egal wie ich das Kopiere ...
 
c303 schrieb:
Es ist also erstmal egal wie ich das Kopiere
Zum Vergrößern anklicken....

Das sehe ich nicht so. DeltaCopy auf Windows erfordert rsync auf z. B. einem FreeBSD Server. Ein CIFS-Share wäre auf z. B. FreeBSD nicht erforderlich, weil das rsync-Protokoll genutzt wird.

Mache ich seit Jahren mit so mit meinen Backup Server basierend auf FreeNAS, wobei ich allerdings damit nur Daten aus Linux sichere. Für Windows verwende ich AOMEI Backupper.
 
Naja, ich hab ja rsync auf dem FreeBSD nicht an, weil ich ja eben per samba die Daten kopiere. Das funktioniert ja auch, nur eben nicht mit der 360GB großen Datei. Das ist die einzige die einen Fehler wirft.

Hier ist übrigens mal das Logfile vom samba während er abbricht ...

Code: 
[2018/02/11 12:41:26.469051,  3] ../source3/smbd/smb2_server.c:3139(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[5] status[STATUS_NO_MORE_FILES] || at ../source3/smbd/smb2_query_directory.c:155
[2018/02/11 12:41:26.471423,  2] ../source3/smbd/close.c:789(close_normal_file)
  root closed file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2017-12-13T040021.vbk (numopen=1) NT_STATUS_OK
[2018/02/11 12:41:26.477565,  3] ../source3/smbd/service.c:1120(close_cnum)
  pc (ipv4:192.168.1.6:60725) closed connection to service IPC$
[2018/02/11 12:41:26.477722,  2] ../source3/smbd/service.c:1120(close_cnum)
  pc (ipv4:192.168.1.6:60725) closed connection to service backup
[2018/02/11 12:41:26.499310,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1001
[2018/02/11 12:41:26.499558,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1005
[2018/02/11 12:41:26.500772,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1007
[2018/02/11 12:41:26.501067,  3] ../source3/lib/sysquotas.c:488(sys_get_quota)
  sys_get_vfs_quota() failed for mntpath[BACKUP - VeeamBackup/Backup Job PC] bdev[(null)] qtype[1] id[-1]: Operation not supported
[2018/02/11 12:41:26.501147,  3] ../source3/lib/sysquotas.c:488(sys_get_quota)
  sys_get_vfs_quota() failed for mntpath[BACKUP - VeeamBackup/Backup Job PC] bdev[(null)] qtype[3] id[-1]: Operation not supported
[2018/02/11 12:41:30.054838,  3] ../source3/smbd/server_exit.c:248(exit_server_common)
  Server exit (NT_STATUS_IO_TIMEOUT)

Hast du eine Anleitung für rsync für mich? Ich teste das gerne mal ...

Für Windows verwende ich Veeam Agent for Microsoft Windows FREE.
 
Also rsync läuft nun auch. Ich komme mit DeltaCopy allerdings nur auf 25 MB/s. Per SMB sind es 115 MB/s (auf die gleiche Kiste). Keine Ahnung woran das gerade liegt.

Ich kann mir nicht vorstellen das es ein Bug ist. Also die Tatsache das ich keine Datei mit 360 GB auf ein Samba Share bekomme, was auf einem FreeBSD 11.1 läuft ... Allerdings konnte ich bisher aber auch keine Lösung finden.

rsync hat halt den großartigen Vorteil das nur die Änderungen übertragen werden. Das SyncBack stellt nur eine Änderung fest und überträgt die ganze Datei dann eben nochmals.
 
Bitte mal bei Samba das Debug (Log Level) einschalten und bitte die komplette smb.conf hier hochladen. Sonst wird es echt schwierig, etwas zu sagen. Ich habe hier bei mir Files mit ca. 450 GB daher sollte das grundsätzlich klappen.
 
Hier das Logfile. Es handelt sich dabei um die Datei "Backup Job PC2018-02-12T040025.vib". Der kopiert ja auch schön, bis er irgendwann mit den Fehlern abbricht. Manchmal eher, manchmal später:
Code: 
[...]
[2018/02/12 10:30:55.696818,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.707442,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.716705,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.725058,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.734070,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.742474,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.753516,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.761553,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=1048576 offset=0 wrote=1048576
[2018/02/12 10:30:55.768139,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=913408 offset=0 wrote=913408
[2018/02/12 10:30:55.769254,  3] ../source3/smbd/trans2.c:8430(smbd_do_setfilepathinfo)
  smbd_do_setfilepathinfo: BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib (fnum 2425125638) info_level=1004 totdata=40
[2018/02/12 10:30:55.769959,  3] ../source3/smbd/smb2_server.c:3139(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_getinfo.c:154
[2018/02/12 10:30:55.771168,  3] ../source3/smbd/smb2_read.c:418(smb2_read_complete)
  smbd_smb2_read: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=32768 offset=0 read=32768
[2018/02/12 10:30:55.772137,  3] ../source3/smbd/smb2_read.c:418(smb2_read_complete)
  smbd_smb2_read: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=32768 offset=1379758080 read=32768
[2018/02/12 10:30:55.773581,  3] ../source3/smbd/smb2_read.c:418(smb2_read_complete)
  smbd_smb2_read: fnum 2425125638, file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib, length=32768 offset=61440 read=32768
[2018/02/12 10:30:55.779115,  2] ../source3/smbd/close.c:789(close_normal_file)
  root closed file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib (numopen=0) NT_STATUS_OK
[2018/02/12 10:30:55.780593,  2] ../source3/smbd/open.c:1404(open_file)
  root opened file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib read=No write=No (numopen=1)
[2018/02/12 10:30:55.781173,  3] ../source3/smbd/trans2.c:8430(smbd_do_setfilepathinfo)
  smbd_do_setfilepathinfo: BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib (fnum 4266451097) info_level=1004 totdata=40
[2018/02/12 10:30:55.782124,  2] ../source3/smbd/close.c:789(close_normal_file)
  root closed file BACKUP - VeeamBackup/Backup Job PC/Backup Job PC2018-02-12T040025.vib (numopen=0) NT_STATUS_OK

Hier die smb4.conf, die recht unspektakulär sein sollte:
Code: 
[global]
workgroup = HEIMNETZ
server string = Samba Server Version %v
netbios name = bsd
wins support = Yes
security = user
passdb backend = tdbsam

# Debug logging information
log level = 3
log file = /var/log/samba4/samba.log.%m
max log size = 50
debug timestamp = yes

# share /backup accessible only to 'root' user
[backup]
path = /backup
valid users = root
writable  = yes
browsable = yes
read only = no
guest ok = no
public = no
create mask = 0666
directory mask = 0755

Hier auch nochmal während er kopiert:
Code: 
top
28 processes:  2 running, 26 sleeping
CPU:  5.9% user,  0.0% nice, 70.6% system, 23.5% interrupt,  0.0% idle
Mem: 160M Active, 10M Inact, 2851M Wired, 401M Free
ARC: 2402M Total, 314K MFU, 2341M MRU, 55M Anon, 4509K Header, 1970K Other
     2353M Compressed, 2394M Uncompressed, 1.02:1 Ratio
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
1371 root          1  87    0   391M   102M RUN     0   1:59  42.96% smbd
1391 root          1  20    0 20164K  3400K CPU1    1   0:00   1.21% top
  820 root          1  20    0 85232K  7232K select  0   0:00   0.26% sshd
  670 root          1  20    0   273M 53496K select  1   0:01   0.00% nmbd
  676 root          1  20    0   385M    99M select  0   0:01   0.00% smbd
  658 root          1  20    0 20568K 12476K select  0   0:00   0.00% ntpd
  823 root          1  20    0 19664K  4236K pause   0   0:00   0.00% csh
  601 root          1  20    0 10504K  1884K select  1   0:00   0.00% syslogd
  756 root          1  20    0 20640K  6248K select  1   0:00   0.00% sendmail
  751 root          1  20    0   385M    99M select  0   0:00   0.00% smbd
  763 root          1  20    0 12596K  2464K nanslp  0   0:00   0.00% cron
  749 root          1  20    0   381M 98176K select  0   0:00   0.00% smbd
  750 root          1  20    0   381M 98228K select  0   0:00   0.00% smbd
  812 root          1  52    0 10484K  2204K ttyin   0   0:00   0.00% getty
  753 root          1  20    0 57816K  6560K select  1   0:00   0.00% sshd
  814 root          1  52    0 10484K  2204K ttyin   1   0:00   0.00% getty
  813 root          1  52    0 10484K  2204K ttyin   0   0:00   0.00% getty
  818 root          1  52    0 10484K  2204K ttyin   1   0:00   0.00% getty
  819 root          1  52    0 10484K  2204K ttyin   1   0:00   0.00% getty
  817 root          1  52    0 10484K  2204K ttyin   0   0:00   0.00% getty
  815 root          1  52    0 10484K  2204K ttyin   1   0:00   0.00% getty
  816 root          1  52    0 10484K  2204K ttyin   0   0:00   0.00% getty
  759 smmsp         1  52    0 20640K  5988K pause   0   0:00   0.00% sendmail
  397 root          1  52    0 10628K  1784K select  0   0:00   0.00% dhclient
  718 root          1  52    0 11860K  2508K select  0   0:00   0.00% rsync
  672 root          1  52    0   232M 11720K piperd  0   0:00   0.00% nmbd
  457 root          1  20    0  9564K  4816K select  1   0:00   0.00% devd
  456 _dhcp         1  20    0 10628K  1920K select  0   0:00   0.00% dhclient

Code: 
zpool iostat 1
backup      5.68T  3.39T      0  1.09K  3.99K   123M
zroot       1.56G   143G      1     43  7.98K   806K
----------  -----  -----  -----  -----  -----  -----
backup      5.68T  3.39T      2  1.02K  11.1K   101M
zroot       1.56G   143G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----
backup      5.68T  3.39T      0  1.37K  3.79K   126M
zroot       1.56G   143G      1      0  7.58K      0
----------  -----  -----  -----  -----  -----  -----
 

Anhänge

c303 schrieb:
Also rsync läuft nun auch. Ich komme mit DeltaCopy allerdings nur auf 25 MB/s.
Zum Vergrößern anklicken....

Das ist in der Tat merkwürdig. :confused:

Von meinem Linux-System zu FreeNAS (Version 11.1-U1) bekommen ich die volle Bandbreite mit rsync geliefert wenn ich nicht den verschlüsselten Pool nutze. Okay, es gibt auch mal gelegentlich Einbrüche, welche aber nicht dramatisch sind.
 
Ich würde einfach "samba47" über PKG löschen und danach das Paket "samba44" installieren. Die smb4.conf ist ja die gleiche und muss vermutlich nicht angepasst werden. Wenn du ein "pkg search samba" machst, sollten eine Liste mit allen Samba Paketen erscheinen. Warum 4.4? Ich habe bei mir Samba 4.4 laufen. Ist nur eine Idee keine Ahnung, ob es klappt.
 
Also ich hab mit pkg remove samba 47 und mit pkg install samba44 das mal eben getestet. Leider kein Erfolg ... er biricht wieder irgendwo ab. Einen Hardwareschaden schließe ich eigentlich aus, weil ich mit Memtest86+ den Speicher mal die ganze Nacht getestet habe und weil bei zpool status auch alles okey ist.

Hat noch jemand Ideen für mich?
 
Versuche doch mal, während des Kopierens der großen Datei, ktrace auf den Samba-Prozess zu aktivieren:

Code: 
# ps aux|grep smbd
<pid> ... smbd
# ktrace -p <pid>
Datei kopieren - bei Abbruch sofort:
# ktrace -c <pid>

Dann hast du ein warscheinlich riesiges ktrace.out im Arbeitsverzeichnis liegen, mittels kdump kann es lesbar gemacht werden.

Um das einzuengen, kannst du eventuell abschätzen, wann der Transfer abbricht und das ktrace erst kurz vorher starten.

Rob
 
Zuletzt bearbeitet:
Also ich befinde mich in /tmp und mache ein
# service samba_server status
nmbd is running as pid 684.
smbd is running as pid 690.

Dann ein:
# ktrace -p 690

Aber die ktrace.out wird nicht größer als 0 Bytes. Öhm ...
 
Bei dem Versuch das File zu erzeugen hat es dann natürlich spontan geklappt mit dem Übertragen der Datei. Allerdings fiel mir immer wieder auf das die Netzwerkkarte auf 100 Mbit zurückfiel, was natürlich in dem Augenblick das Kopieren zum Abbruch brachte. Nur fiel es mir zuerst wohl nicht auf.

Was ich probiert habe:
- FreeNAS statt FreeBSD (den Pool habe ich in FreeNAS importiert)
- andere Kabel (CAT5e, CAT6)
- andere Netzwerkkarte: Eine Intel Gigabit CT Desktop anstatt der onboard Realtek 8111C (Board ist ein GA-MA78GM-S2H)
- Kabel von der Fritzbox 6490 weg und an den Gigabit Switch DGS-1008D direkt ran

Nur der Kabelwechsel von der Fritzbox weg brachte den Erfolg. Ich hab Port 2 und 3 der Fritzbox getestet, dabei war natürlich die Option "Power Mode" auf 1GBit/s. Anscheinend handelt die Fritzbox keine richtige 1000 Mbit Verbindung aus.

Ich hab jetzt FreeNAS statt FreeBSD laufen. Ich denke das sollte keinen großen Unterschied machen.
Bin nur am Überlegen ob ich die Intel Netzwerkkarte oder die Realtek nehmen soll. Laufen tun sie beide gleich gut. ~110 MB/s beim kopieren.
 
FreeNAS ist ja quasi FreeBSD :) Ich nutze FreeNAS sehr häufig und genieße die einfache Administration bei bestmöglicher Offenheit.
In einem Umfeld mit hohen Datenraten und dauerhafter Übertragung würde ich immer zu der Intelkarte tendieren.
Wobei auch RT halbwegs brauchbare Chips hergestellt hat, aber auch unfassbar viel Mist.
Der DGS ist in Ordnung. hat sich bisher komplett unauffällig Verhalten.
 
Hab grad geschaut ... ich hab den 2010 gekauft. Seither war der keine 5 Minuten aus.

Nur mal nebenbei, weil es gerade passt: Wie ist das eigentlich mit der Gesamtbandbreite von so einem kleinen Switch? Habe ich tatsächlich gleichzeitig 1GB/s auf allen 8 Ports? Grad mal getestet: Ich kann gleichzeitig von Rechner A auf B, und von Rechner C auf D mit vollen ~112 MB/s kopieren. Alle vier hängen an dem Switch.
 
Robocopy kopiert die Datei komplett neu, anstatt nur die Änderung wie bei rsync, oder? Wobei das dann auch egal ist wenn der Sync Nachts läuft.
 
Uhm - da muss ich passen... is schon Jahre her, seit ich das verwendet hatte.
Ich mein, das konnte auch Delta, kann aber auch irren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben