1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Samba47 und Datei mit 360GB

Dieses Thema im Forum "FreeBSD - Netzwerk" wurde erstellt von c303, 11 Februar 2018.

  1. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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.
     
  2. Freigeist

    Freigeist Member

    Registriert seit:
    21 Mai 2017
    Beiträge:
    239
    Nie was von SyncBack gehört. Ist das Teil brauchbar? Hat es Vorteile gegenüber DeltaCopy?
     
  3. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    Der Fehler kommt übrigens auch wenn ich per Windows-Explorer die Datei kopiere. Es ist also erstmal egal wie ich das Kopiere ...
     
  4. Freigeist

    Freigeist Member

    Registriert seit:
    21 Mai 2017
    Beiträge:
    239
    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.
     
  5. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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.
     
  6. Freigeist

    Freigeist Member

    Registriert seit:
    21 Mai 2017
    Beiträge:
    239
    Für den Anfang sollte das hier genügen.

    Im Netz wirst du sicher was zur Konfiguration ausser "man rsync" finden.
     
  7. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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.
     
  8. foxit

    foxit Moderator Mitarbeiter

    Registriert seit:
    4 Juli 2012
    Beiträge:
    1.484
    Ort:
    /home
    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.
     
  9. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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:

  10. Freigeist

    Freigeist Member

    Registriert seit:
    21 Mai 2017
    Beiträge:
    239
    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.
     
  11. foxit

    foxit Moderator Mitarbeiter

    Registriert seit:
    4 Juli 2012
    Beiträge:
    1.484
    Ort:
    /home
    Ich hab leider keine Idee. Kannst du mal Samba 4.4 testen?
     
  12. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    Puh, wie mache ich am besten ein downgrade? Und warum 4.4?
     
  13. foxit

    foxit Moderator Mitarbeiter

    Registriert seit:
    4 Juli 2012
    Beiträge:
    1.484
    Ort:
    /home
    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.
     
  14. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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?
     
  15. KobRheTilla

    KobRheTilla used register

    Registriert seit:
    20 Januar 2011
    Beiträge:
    1.265
    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: 13 Februar 2018
  16. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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 ...
     
  17. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    Korrektur: Die Datei füllt sich gerade ... :-)
     
  18. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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.
     
    foxit gefällt das.
  19. marzl

    marzl Active Member

    Registriert seit:
    4 April 2003
    Beiträge:
    2.517
    Ort:
    //germany/nrw
    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.
     
  20. c303

    c303 New Member

    Registriert seit:
    31 März 2008
    Beiträge:
    18
    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.
     
  21. marzl

    marzl Active Member

    Registriert seit:
    4 April 2003
    Beiträge:
    2.517
    Ort:
    //germany/nrw
    Das ist die Backplane, und die hat laut Doku: 16Gb/s