Versuche mit DeDup ZFS/BTRFS (Slow Performance)

[coolblue81]

Die ersten Posts waren Fehleranalyse an der falschen Stelle.. springt direkt zu

#post-468954


Hi,

ich habe hier eine reine Backup NAS konfiguriert mit folgenden Eigenschaften:
- Supermicro X11SSL-CF (SAS mit IT-Mode on Board)
- Intel(R) Xeon(R) CPU E3-1220 v6 @ 3.00GHz
- 32 GB ECC RAM
- 6x 8TB Seagate IronWolf HDD im RAIDZ2
- FreeNAS-11.1-U4

Ein Windows 2008 R2 Server (HP) soll mit Veeam 9.5 U3 darauf sichern. Dazwischen sind zwei HP 1820-24G (Server auf Switch1, NAS auf Switch2) geschaltet. Server nutzt LACP, NAS nutzt LACP.. habs aber auch schonmal deaktiviert und nur Single-Port angebunden.

Wenn ich auf die NAS sichere meldet mich Veeam immer den Fehler:
"20.05.2018 03:40:41 :: Processing Ubuntusrv Error: Der angegebene Netzwerkname ist nicht mehr verfügbar
Failed to flush file buffers. File: [\\172.17.37.233\Backup\Veeam\Inaktive VMs\Inaktive VMsD2018-05-19T220250.vbk].
Failed to backup text locally. Backup: [VBK: 'veeamfs:0:04246786-dd1b-4c88-bc2d-7a999412dc5b (5)\summary.xml@\\172.17.37.233\Backup\Veeam\Inaktive VMs\Inaktive VMsD2018-05-19T220250.vbk'].
Agent failed to process method {DataTransfer.BackupText}.
Agent failed to process method {DataTransfer.BackupText}."

Das passiert meistens so nach 20-30GB Datentransfer (manchmal aber auch erst sehr viel später oder gar nicht oder sofort bei Beginn des Backups) dann ist die Verbindung weg und kurze Zeit später wieder da.

Ein Dauerping zeigt nichts an.. NAS bleibt erreichbar.
Ein parallel geöffnetes Windows Explorer Fenster in den Backup Ordner der NAS zeigt während des Verbinungsabbruch, dass der Explorer keinen Inhalt mehr darstellt. Refresh mit F5 gibt entweder eine Zugriffsfehlermeldung oder einige Sekunden später wieder den normalen Ordnerinhalt. Die Unterbrechung ist also nicht lang, es reicht aber das Veeam nicht weiter macht und der Explorer auf leeren Inhalt umschaltet (automatisch).

Auf der NAS werden im SMB Log keine Errors geloggt auch in anderen Logs finde ich nichts. DMESG ist ebenfalls unauffällig (kein Netzwerkabbruch).

Bevor ich Veeam konfiguriert habe, habe ich mit dem Windows Explorer mehrere TBs an Backupdaten darauf kopiert. Ich habe den Prozess zwar nich beobachtet, er lief über Nacht aber ohne Probleme durch.

Einer eine Ahnung was das sein könnte oder wie ich das am effektivsten debugge?

Danke!

 

[MrToddsFriends]

Einer eine Ahnung was das sein könnte oder wie ich das am effektivsten debugge?

Gibt es Auffälligkeiten beim Speicherbedarf von Samba und/oder Anzeichen für spontane Neustarts des Samba Service?

Mit dem für 28.05. geplanten FreeNAS 11.1-U5 kommen Samba Fixes zumindest für Speicherlecks. Ich kann allerdings nicht sagen, ob das von Dir berichtete Verhalten ins Fehlerbild passt.
https://redmine.ixsystems.com/issues/28585

 

[coolblue81]

Hi,

also ich habe nichts feststellen können bezüglich Speicher auch in den Logs sehe ich keine Samba Neustarts.

Ich habe das Backup nun auf eine QNAP verschoben, damits erstmal läuft. Weiterhin habe ich den Pool und die Freigabe auf FreeNAS komplett neu eingerichtet.

Die paar Tage bis zur U5 warte ich jetzt ab.. in der Zwischenzeit nutze ich den "frischen" Pool um ein paar DeDup Tests zu machen um heraus zu finden was die besten Veeam Einstellungen sind. Dabei kann ich dann auch mal schauen ob die Abbrüche immer noch sind und wenn ja ob ich Samba einfach mal in Debug schalte, um mehr über die Logs evtl. zu erfahren.

Ggf. ein Tipp dazu welcher Debug Parameter bei Samba da am geeignesten wäre?

 

[coolblue81]

Hilft alles nichts....

U5 Update bringt keine Verbesserung. Es gibt immernoch einen Verbindungsabbruch der SMB Verbindung auf die NAS beim Veeam Backup.

Ich habe jetzt seit mehrere Wochen parallel Backups auf die QNAP und auf die FreeNAS laufen. Die QNAP macht ihren Job erste Sahne. Die FreeNAS Box unterbricht ständig die SMB Verbindung insbesondere bei größeren Datenmengen. Heißt Inkrementielle Backups laufen zumeist ohne Probleme, während Vollständige Backups abbrechen.

Ich versteh das nicht. Das ist doch mit Supermicro Top Hardware, dass sollte doch normal laufen....

Beide NAS hängen am gleichen Switch.

 

[coolblue81]

So habe in der smb. conf mal log level 3 eingetragen und das Log während des Backups beobachtet.. Veeam schaffte ca. 60gb bis er dann abbrach. Während des Abbruchs wurde folgendes geloggt:

Code:

[2018/07/07 11:20:42.326343,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2843473916, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk, length=65536 offset=0 wrote=65536
[2018/07/07 11:20:42.326901,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2843473916, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk, length=65536 offset=0 wrote=65536
[2018/07/07 11:20:42.327499,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2843473916, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk, length=65536 offset=0 wrote=65536
[2018/07/07 11:21:45.263543,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2843473916, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk, length=65536 offset=0 wrote=65536
[2018/07/07 11:21:45.263726,  2] ../source3/smbd/close.c:789(close_normal_file)
  veeam closed file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk (numopen=0) NT_STATUS_OK
[2018/07/07 11:21:45.263778,  2] ../source3/smbd/service.c:1120(close_cnum)
  srvdc1 (ipv4:172.17.37.3:56181) closed connection to service Backup
[2018/07/07 11:21:45.267099,  3] ../source3/smbd/server_exit.c:248(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_DISCONNECTED)
[2018/07/07 11:21:54.453688,  3] ../source3/smbd/oplock.c:1329(init_oplocks)
  init_oplocks: initializing messages.
[2018/07/07 11:21:54.453737,  3] ../source3/smbd/process.c:1959(process_smb)
  Transaction 0 of length 108 (0 toread)
[2018/07/07 11:21:54.454012,  3] ../source3/smbd/smb2_negprot.c:290(smbd_smb2_request_process_negprot)
  Selected protocol SMB2_10
[2018/07/07 11:21:54.454612,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'gssapi_spnego' registered
[2018/07/07 11:21:54.454622,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'gssapi_krb5' registered
[2018/07/07 11:21:54.454629,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'gssapi_krb5_sasl' registered
[2018/07/07 11:21:54.454635,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'spnego' registered
[2018/07/07 11:21:54.454642,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'schannel' registered
[2018/07/07 11:21:54.454648,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'naclrpc_as_system' registered
[2018/07/07 11:21:54.454655,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'sasl-EXTERNAL' registered
[2018/07/07 11:21:54.454665,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'ntlmssp' registered
[2018/07/07 11:21:54.454672,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'ntlmssp_resume_ccache' registered
[2018/07/07 11:21:54.454680,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'http_basic' registered
[2018/07/07 11:21:54.454686,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'http_ntlm' registered
[2018/07/07 11:21:54.454693,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'krb5' registered
[2018/07/07 11:21:54.454701,  3] ../auth/gensec/gensec_start.c:977(gensec_register)
  GENSEC backend 'fake_gssapi_krb5' registered
[2018/07/07 11:21:54.455791,  3] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0xe2088297
[2018/07/07 11:21:54.456478,  3] ../auth/ntlmssp/ntlmssp_server.c:454(ntlmssp_server_preauth)
  Got user=[veeam] domain=[FWTT] workstation=[SRVDC1] len1=24 len2=324
[2018/07/07 11:21:54.456513,  3] ../source3/param/loadparm.c:3856(lp_load_ex)
  lp_load_ex: refreshing parameters
[2018/07/07 11:21:54.456564,  3] ../source3/param/loadparm.c:543(init_globals)
  Initialising global parameters
[2018/07/07 11:21:54.456651,  3] ../source3/param/loadparm.c:2770(lp_do_section)
  Processing section "[global]"
[2018/07/07 11:21:54.457237,  2] ../source3/param/loadparm.c:2787(lp_do_section)
  Processing section "[Backup]"
[2018/07/07 11:21:54.457464,  3] ../source3/param/loadparm.c:1598(lp_add_ipc)
  adding IPC service
[2018/07/07 11:21:54.457480,  3] ../source3/auth/auth.c:189(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [FWTT]\[veeam]@[SRVDC1] with the new password interface
[2018/07/07 11:21:54.457487,  3] ../source3/auth/auth.c:192(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [FWTT]\[veeam]@[SRVDC1]
[2018/07/07 11:21:54.458043,  3] ../source3/passdb/lookup_sid.c:1680(get_primary_group_sid)
  Forcing Primary Group to 'Domain Users' for veeam
[2018/07/07 11:21:54.458267,  3] ../source3/auth/auth.c:256(auth_check_ntlm_password)
  auth_check_ntlm_password: sam_ignoredomain authentication for user [veeam] succeeded
[2018/07/07 11:21:54.460860,  3] ../auth/auth_log.c:760(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [FWTT]\[veeam] at [Sat, 07 Jul 2018 11:21:54.460847 CEST] with [NTLMv2] status [NT_STATUS_OK] workstation [SRVDC1] remote host [ipv4:172.17.37.3:63052] became [FWWKBACKUPZFS]\[veeam] [S-1-5-21-3982563097-2396922467-1248689714-3000]. local host [ipv4:172.17.37.233:445]
[2018/07/07 11:21:54.460879,  3] ../auth/auth_log.c:591(log_no_json)
  log_no_json: JSON auth logs not available unless compiled with jansson
[2018/07/07 11:21:54.460885,  2] ../source3/auth/auth.c:314(auth_check_ntlm_password)
  check_ntlm_password:  authentication for user [veeam] -> [veeam] -> [veeam] succeeded
[2018/07/07 11:21:54.461036,  3] ../source3/auth/token_util.c:559(finalize_local_nt_token)
  Failed to fetch domain sid for FWTT
[2018/07/07 11:21:54.461061,  3] ../source3/auth/token_util.c:591(finalize_local_nt_token)
  Failed to fetch domain sid for FWTT
[2018/07/07 11:21:54.479762,  3] ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset)
  NTLMSSP Sign/Seal - Initialising with flags:
[2018/07/07 11:21:54.479772,  3] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0xe2088215
[2018/07/07 11:21:54.479801,  3] ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset)
  NTLMSSP Sign/Seal - Initialising with flags:
[2018/07/07 11:21:54.479806,  3] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0xe2088215
[2018/07/07 11:21:54.479990,  3] ../source3/auth/token_util.c:559(finalize_local_nt_token)
  Failed to fetch domain sid for FWTT
[2018/07/07 11:21:54.480014,  3] ../source3/auth/token_util.c:591(finalize_local_nt_token)
  Failed to fetch domain sid for FWTT
[2018/07/07 11:21:54.480117,  3] ../source3/smbd/password.c:144(register_homes_share)
  Adding homes service for user 'veeam' using home directory: '/nonexistent'
[2018/07/07 11:21:54.483103,  3] ../lib/util/access.c:361(allow_access)
  Allowed connection from srvdc1.fwtt.local (172.17.37.3)
[2018/07/07 11:21:54.483154,  3] ../source3/smbd/service.c:595(make_connection_snum)
  Connect path is '/tmp' for service [IPC$]
[2018/07/07 11:21:54.483175,  3] ../source3/smbd/vfs.c:113(vfs_init_default)
  Initialising default vfs hooks
[2018/07/07 11:21:54.483186,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [/[Default VFS]/]
[2018/07/07 11:21:54.483290,  3] ../source3/smbd/service.c:841(make_connection_snum)
  srvdc1 (ipv4:172.17.37.3:63052) connect to service IPC$ initially as user veeam (uid=1000, gid=1000) (pid 90876)
[2018/07/07 11:21:54.483936,  3] ../source3/smbd/msdfs.c:1008(get_referred_path)
  get_referred_path: |Backup| in dfs path \172.17.37.233\Backup is not a dfs root.
[2018/07/07 11:21:54.483949,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NOT_FOUND] || at ../source3/smbd/smb2_ioctl.c:309
[2018/07/07 11:21:54.484568,  3] ../lib/util/access.c:361(allow_access)
  Allowed connection from srvdc1.fwtt.local (172.17.37.3)
[2018/07/07 11:21:54.484605,  3] ../source3/smbd/service.c:595(make_connection_snum)
  Connect path is '/mnt/PoolFWWK/BackupFWWK' for service [Backup]
[2018/07/07 11:21:54.484625,  3] ../source3/smbd/vfs.c:113(vfs_init_default)
  Initialising default vfs hooks
[2018/07/07 11:21:54.484631,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [/[Default VFS]/]
[2018/07/07 11:21:54.484640,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [streams_xattr]
[2018/07/07 11:21:54.484857,  3] ../lib/util/modules.c:167(load_module_absolute_path)
  load_module_absolute_path: Module '/usr/local/lib/shared-modules/vfs/streams_xattr.so' loaded
[2018/07/07 11:21:54.484871,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [zfsacl]
[2018/07/07 11:21:54.485157,  3] ../lib/util/modules.c:167(load_module_absolute_path)
  load_module_absolute_path: Module '/usr/local/lib/shared-modules/vfs/zfsacl.so' loaded
[2018/07/07 11:21:54.485170,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [zfs_space]
[2018/07/07 11:21:54.493624,  3] ../lib/util/modules.c:167(load_module_absolute_path)
  load_module_absolute_path: Module '/usr/local/lib/shared-modules/vfs/zfs_space.so' loaded
[2018/07/07 11:21:54.493762,  2] ../source3/smbd/service.c:841(make_connection_snum)
  srvdc1 (ipv4:172.17.37.3:63052) connect to service Backup initially as user veeam (uid=1000, gid=1000) (pid 90876)
[2018/07/07 11:21:54.495179,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam, expect_close = 0
[2018/07/07 11:21:54.495233,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/. fname=. (.)
[2018/07/07 11:21:54.495324,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/.. fname=.. (..)
[2018/07/07 11:21:54.495385,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/VeeamRecoveryMedia_SRVFS2.iso fname=VeeamRecoveryMedia_SRVFS2.iso (VeeamRecoveryMedia_SRVFS2.iso)
[2018/07/07 11:21:54.495452,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/Aktive VMs Linux fname=Aktive VMs Linux (Aktive VMs Linux)
[2018/07/07 11:21:54.495517,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/Aktive VMs fname=Aktive VMs (Aktive VMs)
[2018/07/07 11:21:54.495578,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/Inaktive VMs fname=Inaktive VMs (Inaktive VMs)
[2018/07/07 11:21:54.495667,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent fname=FWTT_veeamagent (FWTT_veeamagent)
[2018/07/07 11:21:54.495730,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/VeeamRecoveryMedia_SRVDC1.iso fname=VeeamRecoveryMedia_SRVDC1.iso (VeeamRecoveryMedia_SRVDC1.iso)
[2018/07/07 11:21:54.495782,  3] ../source3/smbd/smb2_server.c:3115(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/07/07 11:21:54.497428,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1001
[2018/07/07 11:21:54.497455,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1005
[2018/07/07 11:21:54.497595,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1007
[2018/07/07 11:21:54.498013,  3] ../source3/lib/sysquotas.c:488(sys_get_quota)
  sys_get_vfs_quota() failed for mntpath[Veeam/FWTT_veeamagent] bdev[(null)] qtype[1] id[-1]: Operation not supported
[2018/07/07 11:21:54.498026,  3] ../source3/lib/sysquotas.c:488(sys_get_quota)
  sys_get_vfs_quota() failed for mntpath[Veeam/FWTT_veeamagent] bdev[(null)] qtype[3] id[-1]: Operation not supported
[2018/07/07 11:21:54.499410,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam/FWTT_veeamagent, expect_close = 0
[2018/07/07 11:21:54.499456,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/. fname=. (.)
[2018/07/07 11:21:54.499507,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/.. fname=.. (..)
[2018/07/07 11:21:54.499578,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2 fname=Backup_Job_SRVFS2 (Backup_Job_SRVFS2)
[2018/07/07 11:21:54.529565,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVDC1 fname=Backup_Job_SRVDC1 (Backup_Job_SRVDC1)
[2018/07/07 11:21:54.529648,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[9] status[STATUS_NO_MORE_FILES] || at ../source3/smbd/smb2_query_directory.c:155
[2018/07/07 11:21:54.531117,  3] ../source3/smbd/trans2.c:3456(smbd_do_qfsinfo)
  smbd_do_qfsinfo: level = 1007
[2018/07/07 11:21:54.531472,  3] ../source3/lib/sysquotas.c:488(sys_get_quota)
  sys_get_vfs_quota() failed for mntpath[Veeam/FWTT_veeamagent] bdev[(null)] qtype[1] id[-1]: Operation not supported
[2018/07/07 11:21:54.531485,  3] ../source3/lib/sysquotas.c:488(sys_get_quota)
  sys_get_vfs_quota() failed for mntpath[Veeam/FWTT_veeamagent] bdev[(null)] qtype[3] id[-1]: Operation not supported
[2018/07/07 11:21:57.975048,  2] ../source3/smbd/open.c:1404(open_file)
  veeam opened file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp read=No write=Yes (numopen=1)
[2018/07/07 11:21:57.976698,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[STATUS_NOTIFY_ENUM_DIR] || at ../source3/smbd/smb2_notify.c:123
[2018/07/07 11:21:57.978261,  3] ../source3/smbd/smb2_notify.c:250(smbd_smb2_notify_send)
  smbd_smb2_notify_send: notify change called on Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, filter = FILE_NAME|DIR_NAME, recursive = 1
[2018/07/07 11:21:57.978277,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 4107690722, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp, length=26510 offset=0 wrote=26510
[2018/07/07 11:21:57.978670,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[STATUS_NOTIFY_ENUM_DIR] || at ../source3/smbd/smb2_notify.c:123
[2018/07/07 11:21:57.978693,  2] ../source3/smbd/close.c:789(close_normal_file)
  veeam closed file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp (numopen=0) NT_STATUS_OK
[2018/07/07 11:21:57.980892,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, expect_close = 0
[2018/07/07 11:21:57.980947,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/. fname=. (.)
[2018/07/07 11:21:57.981024,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/.. fname=.. (..)
[2018/07/07 11:21:57.981108,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk fname=Backup Job SRVFS22018-07-07T100908.vbk (Backup Job SRVFS22018-07-07T100908.vbk)
[2018/07/07 11:21:57.981186,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm fname=Backup Job SRVFS2.vbm (Backup Job SRVFS2.vbm)
[2018/07/07 11:21:57.981256,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp fname=Backup Job SRVFS2.vbm_106_tmp (Backup Job SRVFS2.vbm_106_tmp)
[2018/07/07 11:21:57.981314,  3] ../source3/smbd/smb2_server.c:3115(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/07/07 11:21:57.983092,  2] ../source3/smbd/open.c:1404(open_file)
  veeam opened file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm read=No write=No (numopen=1)
[2018/07/07 11:21:57.983481,  3] ../source3/smbd/trans2.c:8430(smbd_do_setfilepathinfo)
  smbd_do_setfilepathinfo: Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm (fnum 3777892918) info_level=1013 totdata=1
[2018/07/07 11:21:57.983966,  2] ../source3/smbd/close.c:789(close_normal_file)
  veeam closed file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm (numopen=0) NT_STATUS_OK
[2018/07/07 11:21:57.985106,  2] ../source3/smbd/open.c:1404(open_file)
  veeam opened file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp read=No write=No (numopen=1)
[2018/07/07 11:21:57.985550,  3] ../source3/smbd/trans2.c:8430(smbd_do_setfilepathinfo)
  smbd_do_setfilepathinfo: Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp (fnum 3265471589) info_level=65290 totdata=146
[2018/07/07 11:21:57.985799,  3] ../source3/smbd/reply.c:6866(rename_internals_fsp)
  rename_internals_fsp: succeeded doing rename on Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm_106_tmp -> Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm
[2018/07/07 11:21:57.986208,  2] ../source3/smbd/close.c:789(close_normal_file)
  veeam closed file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm (numopen=0) NT_STATUS_OK
[2018/07/07 11:21:57.987821,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, expect_close = 0
[2018/07/07 11:21:57.987876,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/. fname=. (.)
[2018/07/07 11:21:57.987956,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/.. fname=.. (..)
[2018/07/07 11:21:57.988027,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk fname=Backup Job SRVFS22018-07-07T100908.vbk (Backup Job SRVFS22018-07-07T100908.vbk)
[2018/07/07 11:21:57.988096,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm fname=Backup Job SRVFS2.vbm (Backup Job SRVFS2.vbm)
[2018/07/07 11:21:57.988145,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[9] status[STATUS_NO_MORE_FILES] || at ../source3/smbd/smb2_query_directory.c:155
[2018/07/07 11:21:58.986362,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_CANCELLED] || at ../source3/smbd/smb2_notify.c:123
[2018/07/07 11:21:58.986576,  3] ../lib/util/access.c:361(allow_access)
  Allowed connection from srvfs2.fwtt.local (172.17.37.21)
[2018/07/07 11:21:58.986657,  3] ../source3/smbd/service.c:595(make_connection_snum)
  Connect path is '/tmp' for service [IPC$]
[2018/07/07 11:21:58.986687,  3] ../source3/smbd/vfs.c:113(vfs_init_default)
  Initialising default vfs hooks
[2018/07/07 11:21:58.986700,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [/[Default VFS]/]
[2018/07/07 11:21:58.986820,  3] ../source3/smbd/service.c:841(make_connection_snum)
  srvfs2 (ipv4:172.17.37.21:65215) connect to service IPC$ initially as user veeam (uid=1000, gid=1000) (pid 81175)
[2018/07/07 11:21:58.988583,  3] ../source3/smbd/msdfs.c:1008(get_referred_path)
  get_referred_path: |Backup| in dfs path \172.17.37.233\Backup is not a dfs root.
[2018/07/07 11:21:58.988602,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NOT_FOUND] || at ../source3/smbd/smb2_ioctl.c:309
[2018/07/07 11:21:58.990773,  3] ../source3/smbd/smb2_notify.c:250(smbd_smb2_notify_send)
  smbd_smb2_notify_send: notify change called on Veeam/FWTT_veeamagent, filter = FILE_NAME|DIR_NAME|ATTRIBUTES|LAST_WRITE, recursive = 0
[2018/07/07 11:21:58.990863,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, expect_close = 0
[2018/07/07 11:21:58.990924,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/. fname=. (.)
[2018/07/07 11:21:58.991006,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/.. fname=.. (..)
[2018/07/07 11:21:58.991086,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk fname=Backup Job SRVFS22018-07-07T100908.vbk (Backup Job SRVFS22018-07-07T100908.vbk)
[2018/07/07 11:21:58.991175,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm fname=Backup Job SRVFS2.vbm (Backup Job SRVFS2.vbm)
[2018/07/07 11:21:58.991231,  3] ../source3/smbd/smb2_server.c:3115(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/07/07 11:21:59.008956,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_FS_DRIVER_REQUIRED] || at ../source3/smbd/smb2_ioctl.c:309
[2018/07/07 11:21:59.978347,  3] ../source3/smbd/smb2_notify.c:250(smbd_smb2_notify_send)
  smbd_smb2_notify_send: notify change called on Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, filter = FILE_NAME|DIR_NAME, recursive = 1
[2018/07/07 11:21:59.978380,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[STATUS_NOTIFY_ENUM_DIR] || at ../source3/smbd/smb2_notify.c:123
[2018/07/07 11:22:00.983215,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_CANCELLED] || at ../source3/smbd/smb2_notify.c:123
[2018/07/07 11:22:00.985391,  3] ../source3/smbd/smb2_notify.c:250(smbd_smb2_notify_send)
  smbd_smb2_notify_send: notify change called on Veeam/FWTT_veeamagent, filter = FILE_NAME|DIR_NAME|ATTRIBUTES|LAST_WRITE, recursive = 0
[2018/07/07 11:22:00.986176,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, expect_close = 0
[2018/07/07 11:22:00.986221,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/. fname=. (.)
[2018/07/07 11:22:00.986309,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/.. fname=.. (..)
[2018/07/07 11:22:00.986382,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk fname=Backup Job SRVFS22018-07-07T100908.vbk (Backup Job SRVFS22018-07-07T100908.vbk)
[2018/07/07 11:22:00.986468,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS2.vbm fname=Backup Job SRVFS2.vbm (Backup Job SRVFS2.vbm)
[2018/07/07 11:22:00.986515,  3] ../source3/smbd/smb2_server.c:3115(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/07/07 11:22:00.994537,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_FS_DRIVER_REQUIRED] || at ../source3/smbd/smb2_ioctl.c:309
[2018/07/07 11:22:01.978613,  3] ../source3/smbd/smb2_notify.c:250(smbd_smb2_notify_send)
  smbd_smb2_notify_send: notify change called on Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, filter = FILE_NAME|DIR_NAME, recursive = 1
[2018/07/07 11:22:02.984535,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_CANCELLED] || at ../source3/smbd/smb2_notify.c:123
[2018/07/07 11:22:02.987647,  3] ../source3/smbd/smb2_notify.c:250(smbd_smb2_notify_send)
  smbd_smb2_notify_send: notify change called on Veeam/FWTT_veeamagent, filter = FILE_NAME|DIR_NAME|ATTRIBUTES|LAST_WRITE, recursive = 0
[2018/07/07 11:22:03.005042,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_FS_DRIVER_REQUIRED] || at ../source3/smbd/smb2_ioctl.c:309
[2018/07/07 11:22:07.308240,  3] ../source3/smbd/service.c:1120(close_cnum)
  srvdc1 (ipv4:172.17.37.3:63052) closed connection to service IPC$
[2018/07/07 11:22:10.070053,  2] ../source3/smbd/server.c:803(remove_child_pid)
  Could not find child 91113 -- ignoring
[2018/07/07 11:22:13.314244,  2] ../source3/smbd/service.c:1120(close_cnum)
  srvdc1 (ipv4:172.17.37.3:63052) closed connection to service Backup
[2018/07/07 11:22:13.316491,  3] ../source3/smbd/server_exit.c:248(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)
[2018/07/07 11:22:15.455963,  3] ../source3/smbd/service.c:1120(close_cnum)
  srvfs2 (ipv4:172.17.37.21:65215) closed connection to service IPC$
[2018/07/07 10:36:22.759700,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2843473916, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk, length=65536 offset=0 wrote=65536
[2018/07/07 10:36:22.760089,  3] ../source3/smbd/smb2_write.c:212(smb2_write_complete_internal)
  smb2: fnum 2843473916, file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk, length=61440 offset=0 wrote=61440
[2018/07/07 10:37:12.169781,  3] ../lib/util/access.c:361(allow_access)
  Allowed connection from srvfs2.fwtt.local (172.17.37.21)
[2018/07/07 10:37:12.169852,  3] ../source3/smbd/service.c:595(make_connection_snum)
  Connect path is '/tmp' for service [IPC$]
[2018/07/07 10:37:12.169878,  3] ../source3/smbd/vfs.c:113(vfs_init_default)
  Initialising default vfs hooks
[2018/07/07 10:37:12.169883,  3] ../source3/smbd/vfs.c:139(vfs_init_custom)
  Initialising custom vfs hooks from [/[Default VFS]/]
[2018/07/07 10:37:12.169990,  3] ../source3/smbd/service.c:841(make_connection_snum)
  srvfs2 (ipv4:172.17.37.21:65215) connect to service IPC$ initially as user veeam (uid=1000, gid=1000) (pid 81175)
[2018/07/07 10:37:12.170341,  3] ../source3/smbd/msdfs.c:1008(get_referred_path)
  get_referred_path: |Backup| in dfs path \172.17.37.233\Backup is not a dfs root.
[2018/07/07 10:37:12.170355,  3] ../source3/smbd/smb2_server.c:3115(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NOT_FOUND] || at ../source3/smbd/smb2_ioctl.c:309
[2018/07/07 10:37:12.185749,  3] ../source3/smbd/dir.c:657(dptr_create)
  creating new dirptr 0 for path Veeam/FWTT_veeamagent/Backup_Job_SRVFS2, expect_close = 0
[2018/07/07 10:37:12.185827,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/. fname=. (.)
[2018/07/07 10:37:12.205951,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/.. fname=.. (..)
[2018/07/07 10:37:12.232964,  3] ../source3/smbd/dir.c:1228(smbd_dirptr_get_entry)
  smbd_dirptr_get_entry mask=[*] found Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk fname=Backup Job SRVFS22018-07-07T100908.vbk (Backup Job SRVFS22018-07-07T100908.vbk)

Einen direkten Fehler der das Verhalten erklären könnte erkenne ich daraus nicht. Die anderen Fehlermeldungen sind glaube ich anderer natur oder? entstehen jedenfalls immer nur beim wiederverbinden des Windows Servers auf die NAS.

Code:

[2018/07/07 11:21:45.263726,  2] ../source3/smbd/close.c:789(close_normal_file)
  veeam closed file Veeam/FWTT_veeamagent/Backup_Job_SRVFS2/Backup Job SRVFS22018-07-07T100908.vbk (numopen=0) NT_STATUS_OK

Diese Stelle versteh ich nicht. Warum sollte Veeam die Datei closen?

 

[coolblue81]

Folgendes sagt Windows:

Code:

Veeam Agent 'Backup Job SRVFS2' finished with Failed.
Job details: Error: Der angegebene Netzwerkname ist nicht mehr verfügbar
Failed to write data to the file [\\172.17.37.233\Backup\Veeam\FWTT_veeamagent\Backup_Job_SRVFS2\Backup Job SRVFS22018-07-07T100908.vbk].
Failed to download disk.
Reconnectable protocol device was closed.
Failed to upload disk.
Agent failed to process method {DataTransfer.SyncDisk}.

 

[coolblue81]

Fehler gefunden! ZFS ist schuld!

Also was genau soll das heißen. Ganz einfach. Ich habe DeDup aktiviert und mit zunehmender Datenmenge wurde die Festplatten Performance immer schlechter. Laut iostat wurden nur noch 5mbit/s über 6 Platten umgesetzt, wobei diese 5 mbit/s nur durch ZFS interne Verwaltung verwendet wurden.

Samba stand die ganze Zeit auf I/O Wait und irgendwann sagt Windows natürlich "Timeout" und beendet die Verbindung. Das erklärt auch das fehlen von (error-)Logs bzw. die Meldung Connection Closed.

Ich habe es am WE in den Kopf gekriegt und kurzerhand FreeNAS heruntergeworfen und Ubuntu 18.04 LTS installiert. Dort habe ich den ZFS Pool wieder importiert und freigegeben.
Da ich mit Linux wesentlich besser klar komme als mit BSD konnte ich hier mit einigen Tools das Verhalten im System besser überwachen und analysieren, nachdem ich erschreckender Weise festgestellt habe, dass auch unter Ubuntu die Abbrüche stand fanden.

Nach Recherche im Internet ist es wohl so, dass DeDup bei hoch fragmentierten und länger benutzen Systemen, so dermaßen langsam wird, dass die Schreibrate auf bis zu 1mb/s abfallen kann. Schaltet man Dedup aus, hat man schlagartig wieder 100mbit/s übers Netzwerk.

So richtig den Grund konnte ich nicht herausfinden oder passend recherchieren. Die ZFS Doku sagt, dass die DDT im ARC gehalten wird und damit schneller Zugriff ermöglicht werden sollte.
Ein anderer Artikel im Netz sagt, dass die DDT zu den Metadaten gehört und die Metadaten die gleiche Priorität haben wie der Cache im ARC. Wenn also der Cache mit etwas neuem gefüllt wird, kann es auch passieren das DDT Daten gekickt werden.

Rechnerisch hätte es kein Performance Downgrade geben dürfen. Laut zdb -DD ist meine Tabelle 5 GB groß. 25% von 32GB sind 8 GB, heißt die Metadaten Grenze für die DDT war noch längst nicht erreicht. Ich habe auch über den ZFS Parameter die Metadata Tabelle auf 25 GB erhöht. Dies zeigte absoltut keinen Unterschied.

Wie verhält es sich meistens?
Der Kopierprozess beginnt. Es werden gute 100-110mb/s über das 1 GB Netzwerk übertragen. Laut iostat gehen (wegen Kompression) gute 60-80mb/s auf das RAIDZ2.

Dann nach guten 20-30 Sekunden laufzeit bricht alles ein und es geht runter auf 5Mbit/s.

Veeam (Windows) bricht ab und beendet die Verbindung.

Ab diesem Moment, wird immernoch mit 5mbit/s aufs RAIDZ2 gelesen und geschrieben über weitere 20-30 Sekunden. Danach kommt ein Burst mit bis zu 200mb/s für ca. 3-5 Sekunden und danach ist der Schreibprozess vorbei und die Festplatten idlen.

Meine Erfahrung damit sind mit diesem Beitrag ziemlich Deckungsgleich:
http://christopher-technicalmusings.blogspot.com/2011/07/zfs-dedup-performance-real-world.html

Ein weiterer Beitrag den ich gefunden habe, sagt, dass DeDup extrem I/O lastig sei und es nur sinn macht, dies auf SSD Volumes und nur mit mirror vdevs geeignet sei, weil die ja nun mal am besten bei I/O intensiven Lasten arbeiten.

Eigentlich ist die Aussage unlogisch, denn die DDT kann ja vollständig im ARC / L2ARC gehalten werden. Jedoch macht sie Sinn wen man obigen Beitrag mitbeachtet und bedenkt, dass Teile der DDT zwischendurch aus dem ARC entfernt werden können.


Wie sind eure Erfahrungen mit Dedup für Backup Prozesse?

So wie es aktuell aussieht ist DeDup so unbenutzbar.

Ich überlege grade ob ich die aus dem Artikel verwendete Semi-"Offline Deduplizierung" via Script löse. Erstmal den Backupprozess alles drauf schreiben (dedup=off) lassen und danach über Script die Daten deduplizieren (dedup=on) lassen in dem man sie einmal mit cp kopiert.

 

[MrToddsFriends]

So wie es aktuell aussieht ist DeDup so unbenutzbar.

Besten Dank für Deine Ausführungen.

Kannst Du eine ungefähre Angabe darüber machen, welche Ersparnis an Plattenplatz durch die Verwendung von Deduplication bei Deinem Anwendungsfall ermöglicht wird? Sowie darüber, was tatsächlich gesichert wird, z.B. wie viele Clients mit (untereinander) ähnlichen Betriebssystem-Installationen?

Abgesehen von Deinen Beobachtungen mittels zdb und evtl. weiteren Tools wäre ich nicht auf die Idee gekommen, mit 32 GB RAM auf einer FreeNAS (bzw. ZFS) Maschine Deduplication einzusetzen. Die Faustregel "5 GB of RAM per terabyte of deduplicated storage" aus dem FreeNAS Handbuch legt nahe, dass 32 GB RAM nicht weit reichen.

 

[coolblue81]

Hallo MrToddsFriends,

zu deinen Fragen kann ich nur Schätzungen an Hand meiner anfänglichen Tests (auf leerem ZFS Store) abgeben.

Gesichert werden verschiedenste Windows Server 2008 R2 / 2008 / 2016 Systeme und dadrin sind auch noch 2-3 XP Maschinen als VM.

Wenn ich NUR diese Maschinen sichere plus die 20 Tage Increments dazu zähle sagte mir ZFS eine DeDup Rate von 1:1.15. Das ist nicht viel und es war auch kein Ziel hier etwas besseres zu erreichen.

Wofür ich das nutzen wollte, war relativ einfach. Ich wollte das GFS Backupschema anwenden. Ein Backup pro Woche, Pro Monat, Pro Quartal Pro Jahr. Hier sichert Veeam immer Full-Backups von ca. 3,5 TB.

Identische Backups (2x den Full Backup Job von Veeam ausgeführt, auf _aktive_ VMs) ergab stehts eine DeDup Rate von 1:1.8 - 1:2.0.

Rechnet man die Langzeit Backups hinzu, zieht pie-mal-daumen die täglichen Änderungen ab, rechnet Dedup-bare Blöcke über VMs hinweg (s. o. 1:1.15) hinzu, müsste man theoretisch auf eine DeDup Rate von 1:20 kommen.

Durch das GFS Schema entstehen nach 1 Jahr insg. 22 Full-Backups mit nahezu indentischem Inhalt, welche zusammen nur 4-6 TB belegen dürften.

Hinzu kommen die 14 Tage aktives Backup aus der 1. Stage, was die DeDup Rate minimal wieder verschlechtert. Die 1. Stage und die GFS Stage sind scheinbar nicht block-kompatibel.. hatte ich eine DeDup Rate im Test 1:1.0. Obwohl es exakt die gleichen Daten sind und Veeam bereits das Block-Alignment aktiviert hatte.

Dies ist jetzt echt eine absolute reine Schätzung aber ich denke 1:18 wären machbar gewesen.

Hardware:
Ich habe das System für einen Kunden gekauft, mit der Intention seinen Geldbeutel zu schonen und mir eine praxistaugliche Testplattform für DeDup zu ermöglichen.
Es ist/war geplant dies auf 64 GB zu erweitern und eine L2ARC SSD dazu zu setzen. Laut Handbuch sei das ja problem los möglich. Für Backupzwecke wäre eine SSD für die DDT mehr als schnell genug. Ich kann eh nur max. 100mb/s übers LAN liefern. Selbst bei 50mb/s wäre ich noch zu frieden.

Ich habe während meinen Versuchen penibel die DDT Größe beobachtet um sicher zu gehen, dass das alles passt. Ich hatte zuletzt 3 TB Daten auf dem vol und einen DDT mit 5 GB Größe. Ich denke das ist passabel für ein Testszenario.

Sollte sich der Test als Fehlschlag rausstellen (32/64GB/L2ARC zu klein/zu langsam) hätte ich zukünftigere DeDup Kisten großzügiger geplant.

Aber mit dem jetzigen Ergebnis bringts auch nix da 1 TB RAM reinzusetzen.. spätestens wenn der ARC mit 1 TB vollgeschrieben wurde, ist die DDT futsch und muss von den Platten neu gelesen werden. Ok bei 1 TB wärs vill noch grade so möglich das ein Veeam Script 1 TB nicht übersteigt.

Ein interessanter Praxis Test wäre vill ein System mit 10k SAS 1,2-1,8TB HDDs zu bauen im vdev mirror um die I/O zyklen fürs lesen der DDT zu liefern. Aber ob sich das alles finanziell wieder lohnt glaub ich eher nicht. Sind ja mittlerweile bei 12 TB HDDs, das ist billiger als SAS+viel RAM für DDT.

Preislich praxistauglich wäre halt SATA 7.2 (von mir aus im vdev mirror, das bisschen an "mehr" Geld wäre noch ok) + eine 500 GB SSD als L2ARC. Das wäre ein schönes System auch für kleine Kunden gewesen.

Evtl. muss ich mich bezüglich offline-dedup mal mit BTRFS beschäftigen.

 

[coolblue81]

Soo liebe Freunde von ZFS...

ein zweites Kundensystem wurde mir geliefert. Gleiche Ausstattung wie oben, jedoch mit 480 GB Intel SATA SSD.

Die Bestellung war schon raus, bevor ich wie oben bemerkt habe, das DeDup zu langsam ist und Probleme mit dem Backup verursacht.

Also dachte ich mir... ja komm probier's mal mit L2ARC und DeDup ;-)


Dabei kamen höchst interessante Ergebnisse heraus. Leider alle nicht positiv, so viel schonmal vor weg.

Test 1)
RAIDz2 (erst ohne später mit) L2ARC SSD

Code:

												capacity	 operations	 bandwidth
pool										  alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool										   495G  43,0T	  0  25,7K	  0   332M
  raidz2									   495G  43,0T	  0  25,7K	  0   332M
	ata-ST8000VN0022-2EL112_ZA1BMSBF			  -	  -	  0  4,29K	  0  55,4M
	ata-ST8000VN0022-2EL112_ZA1BMSCM			  -	  -	  0  4,28K	  0  55,4M
	ata-ST8000VN0022-2EL112_ZA1BMSFT			  -	  -	  0  4,28K	  0  55,5M
	ata-ST8000VN0022-2EL112_ZA1BMSM2			  -	  -	  0  4,26K	  0  55,4M
	ata-ST8000VN0022-2EL112_ZA1BMST4			  -	  -	  0  4,33K	  0  55,4M
	ata-ST8000VN0022-2EL112_ZA1C0NX5			  -	  -	  0  4,27K	  0  55,3M
cache											 -	  -	  -	  -	  -	  -
  ata-INTEL_SSDSC2BB480G7_BTDV726006PW480BGN  2,53G   445G	  0	  0	  0	  0
--------------------------------------------  -----  -----  -----  -----  -----  -----

(Bild zeigt nur eine Momentaufnahme)

Pool leer... angefangen mit /dev/urandom zu füllen.
Es beginnt mit einer Schreibrate von 130mb/s laut "dd" und einer Bandbreite des Pools von 330M (siehe oben).
Ab und zu sinkt die Rate auf 20mb/s ein.. und steigt dann wieder auf 130mb/s.

Nachdem so ungefähr 100 GB geschrieben wurden, wurds langsaaaaamer.. Im Schnitt nahm das Array so um die 15-35mb/s auf. Ab und zu sakte es auf 6mb/s ab und dann gabs Peaks von 2-3 Sekunden mit 130mb/s.

Als die 32GB RAM mit DDT Metadaten voll waren, konnte man in der Statistik sehen, wie er anfing "Reads" auf den Platten auszuführen.. also war mir klar. Aha! RAM voll nun wird ausgelagert!

Transferrate sank auf 2mb/s ab! konstant!

Ensprechend brach in den Kopiervorgang ab.. es dauerte gute 10 Minuten bis das Array sich erholte und endlich alle Daten geschrieben hatte.

Ich fügte nun die L2ARC SSD hinzu und begann wieder zu schreiben.
Gut die L2ARC war leer. Logisch.

Also blieb es bei 2-5mb/s (ja ab und zu wars mit L2ARC schneller) und man sah wie sich die SSD langsam füllte (alloc).

Die DDT Tabellte hatte laut zdb -DD pool mittlerweile 13 GB RAM belegt.

Es hat über 2 Stunden gedauert bis durch schreiben von (mehr) Daten die L2ARC endlich auf 13 bzw. mittlerweile 14 GB angewachsen war.
Jedoch hören die Read Operationen auf der HDDs nicht auf.. das fand ich merkwürdig.

Ungeduldig wie ich war und mit dem wissen das DDTs viel I/O verbraten, hab ich den Pool gekillt und ein neuen Pool mit Mirror Devs und sofort mit L2ARC erstellt.

Test 2)
Mirror vDevs mit L2ARC SSD

Code:

										capacity	 operations	 bandwidth
pool								  alloc   free   read  write   read  write
------------------------------------  -----  -----  -----  -----  -----  -----
pool								   401G  21,4T  1,93K	  0  7,72M	  0
  mirror							   134G  7,12T	656	  0  2,57M	  0
	ata-ST8000VN0022-2EL112_ZA1BMSCM	  -	  -	328	  0  1,28M	  0
	ata-ST8000VN0022-2EL112_ZA1BMSBF	  -	  -	328	  0  1,28M	  0
  mirror							   134G  7,12T	666	  0  2,61M	  0
	ata-ST8000VN0022-2EL112_ZA1BMSM2	  -	  -	337	  0  1,32M	  0
	ata-ST8000VN0022-2EL112_ZA1BMST4	  -	  -	329	  0  1,29M	  0
  mirror							   134G  7,12T	652	  0  2,55M	  0
	ata-ST8000VN0022-2EL112_ZA1C0NX5	  -	  -	328	  0  1,29M	  0
	ata-ST8000VN0022-2EL112_ZA1BMSFT	  -	  -	324	  0  1,27M	  0
cache									 -	  -	  -	  -	  -	  -
  sdh								 8,11G   439G  1,24K	154  4,96M  17,5M
------------------------------------  -----  -----  -----  -----  -----  -----

(Statistik beim löschen einer 330GB großen Datei, während die DDT noch nicht vollständig im RAM war)

Ich dachte mir so kann ich das viel besser überwachen und habe deutlich mehr I/O Kapazität, für den Fall der Fälle.

Pool ist leer.. wieder mit /dev/urandom beschrieben.
Nach 100 GB wieder der besagte Einbruch auf um die 30mb/s.

Ich habe ihn weiter schreiben lassen. Die L2ARC füllte sich parallel mit, es wurde von ihr aber nicht gelesen auch nicht von den Disks.

Als wir uns der 8 GB DDT Grenze näherten, sprich die 32 GB RAM waren (ZoL) ausgereizt, da unter Linux per Default nur 50% reserviert sind fürs ARC, fing die L2ARC an auch Leseoperationen auszuführen.
Zuerst dachte ich "cool".. läuft.

ABER: Gleichzeitig hatten auch alle anderen Festplatten wieder Leseoperationen und die Schreibrate viel auf 5mb/s ein.

Fazit: Sobald also der ARC voll ist, hilft die L2ARC zwar beim lesen der DDT jedoch nicht vollständig. Teile der DDT werden von den HDDs gelesen! Die Schreibrate ist ab dann konstant langsam.

Fazit2: RAID10 (mirror vdevs) hat etwas gebracht, aber nicht viel. Langsame SATA Platten bleiben langsame SATA Platten.

Fazit3: Es hilft nur eins! Mehr RAM! Mehr RAM mehr RAM!
Aber... nein auch das hilft allein nicht... Warum?


Ich habe spasseshalber den Pool exportiert und wieder importiert. Danach ist der ARC und die L2ARC SSD ja leer. Genauso wie beim Neustart des Systems, was gelegentlich ja mal sein muss.

Der Zugriff auf den Pool (lesen/löschen/schreiben) ist unterirdisch!
Um eine 330 GB große Datei zu löschen, war das System gute 2 Stunden beschäftigt. In den 2 Stunden hat er millionen von I/Os auf die HDDs ausgeführt um die 13GB DDT zu lesen.

Nein die DDT wird nicht beim Import in den RAM geladen.. der RAM bleibt frei. Mein Linux hatte 300mb RAM belegt nach dem Import und kurz vor Beendigung des Löschvorgangs gute 12 GB belegt.

Der lädt die DDT ausschließlich nur bei Bedarf und auch nur Block für Block (nach Bedarf).

Damit komme ich zu

Fazit4) DeDup macht nur auf SSDs im Mirror Vdev Sinn! Damit die DDT ohne Seektime sofort adhoc gelesen werden kann.
Ein L2ARC bringt keinerlei Vorteile und macht in einem SSD-only System sowieso keinen Sinn.


Sehr ernüchternde Ergebnisse. Schade das in der OpenZFS/FreeNAS Doku das nicht genau erklärt wird...

Was bringt mir genug RAM, wenn beim Neustart das System erstmal lahm gelegt ist?
Was bingt mir L2ARC Caching, wenn trotzdem die DDT von den Disks gelesen wird?

Was mir noch auffiehl.. je größer die DDT, desto länger dauerte es diese auf den Disks zu aktualisieren. Obwohl ich noch nicht an der RAM Grenze war, kam es immer häufiger vor das die Datenrate für eine Weile auf 2-4mbit/s sank, weil ZFS mit dem Reorg seiner Metadaten/DDT beschäftigt ist.


Testeinstellungen:

Code:

NAME  PROPERTY			  VALUE				 SOURCE
pool  recordsize			4K					local
pool  compression		   off				   default
pool  atime				 off				   local
pool  primarycache		  metadata			  local
pool  secondarycache		metadata			  local
pool  dedup				 on					local

Warum 4k? So wird die DDT Tabelle schneller im Test größer.. aber auch in der Praxis ist die DeDup Rate beim Backup viel besser als bei 128k Blöcken.

 

[coolblue81]

So aus Langewei... äh Neugierde habe ich ZFS ausgetauscht gegen BTRFS, falls es jemanden interessiert. Hier die Ergebnisse des Offline DeDup mit dem Tool "duperemove".

Code:

root@dgwl-backupnas01:/pool# btrfs fi us /pool
Overall:
	Device size:		 43.66TiB
	Device allocated:		 36.01GiB
	Device unallocated:		 43.63TiB
	Device missing:			0.00B
	Used:			 29.30GiB
	Free (estimated):		 21.81TiB   (min: 21.81TiB)
	Data ratio:				 2.00
	Metadata ratio:			 2.00
	Global reserve:		 16.00MiB   (used: 0.00B)

Data,RAID10: Size:15.00GiB, Used:14.64GiB
   /dev/sda	  2.50GiB
   /dev/sdb	  2.50GiB
   /dev/sdc	  2.50GiB
   /dev/sdd	  2.50GiB
   /dev/sde	  2.50GiB
   /dev/sdf	  2.50GiB

Metadata,RAID10: Size:3.00GiB, Used:15.20MiB
   /dev/sda	512.00MiB
   /dev/sdb	512.00MiB
   /dev/sdc	512.00MiB
   /dev/sdd	512.00MiB
   /dev/sde	512.00MiB
   /dev/sdf	512.00MiB

System,RAID10: Size:7.88MiB, Used:16.00KiB
   /dev/sda	  1.31MiB
   /dev/sdb	  1.31MiB
   /dev/sdc	  1.31MiB
   /dev/sdd	  1.31MiB
   /dev/sde	  1.31MiB
   /dev/sdf	  1.31MiB

Unallocated:
   /dev/sda	  7.27TiB
   /dev/sdb	  7.27TiB
   /dev/sdc	  7.27TiB
   /dev/sdd	  7.27TiB
   /dev/sde	  7.27TiB
   /dev/sdf	  7.27TiB

root@dgwl-backupnas01:/pool# time duperemove -rdhv /pool/
Using 128K blocks
Using hash: murmur3
Gathering file list...
Using 4 threads for file hashing phase
[1/3] (33.33%) csum: /pool/file1
[2/3] (66.67%) csum: /pool/file2
[3/3] (100.00%) csum: /pool/file3
Total files:  3
Total hashes: 119870
Loading only duplicated hashes from hashfile.
Using 4 threads for dedupe phase

<snip>..... viel log output </snip>

Kernel processed data (excludes target files): 14.6G
Comparison of extent info shows a net change in shared extents of: 7.3G

real   68m22,508s
user   0m5,966s
sys   99m8,357s

root@dgwl-backupnas01:/pool# btrfs fi us /pool
Overall:
	Device size:		 43.66TiB
	Device allocated:		 24.01GiB
	Device unallocated:		 43.64TiB
	Device missing:			0.00B
	Used:			 14.67GiB
	Free (estimated):		 21.82TiB   (min: 21.82TiB)
	Data ratio:				 2.00
	Metadata ratio:			 2.00
	Global reserve:		 16.00MiB   (used: 0.00B)

Data,RAID10: Size:9.00GiB, Used:7.32GiB
   /dev/sda	  1.50GiB
   /dev/sdb	  1.50GiB
   /dev/sdc	  1.50GiB
   /dev/sdd	  1.50GiB
   /dev/sde	  1.50GiB
   /dev/sdf	  1.50GiB

Metadata,RAID10: Size:3.00GiB, Used:18.30MiB
   /dev/sda	512.00MiB
   /dev/sdb	512.00MiB
   /dev/sdc	512.00MiB
   /dev/sdd	512.00MiB
   /dev/sde	512.00MiB
   /dev/sdf	512.00MiB

System,RAID10: Size:7.88MiB, Used:16.00KiB
   /dev/sda	  1.31MiB
   /dev/sdb	  1.31MiB
   /dev/sdc	  1.31MiB
   /dev/sdd	  1.31MiB
   /dev/sde	  1.31MiB
   /dev/sdf	  1.31MiB

Unallocated:
   /dev/sda	  7.28TiB
   /dev/sdb	  7.28TiB
   /dev/sdc	  7.28TiB
   /dev/sdd	  7.28TiB
   /dev/sde	  7.28TiB
   /dev/sdf	  7.28TiB

root@dgwl-backupnas01:/pool# l -h
total 15G
-rw-r--r-- 1 root root 6,3G Jul 25 17:21 file1
-rw-r--r-- 1 root root 1,1G Jul 25 17:21 file2
-rw-r--r-- 1 root root 7,4G Jul 25 17:22 file3
root@dgwl-backupnas01:/pool#

Es hat 70 Minuten gedauert um aus 15 TB > 7 TB zu machen.
Zur Info file1 und file2 sind in file3 drin. (cat file1 file2 > file3). File 1 und 2 wurden mit urandom erstellt.

Ich hatte es erst mit 600 GB * 2 versucht und nach 48 Stunden dann entnervt abgebrochen.

So ein wöchentliches Backupfile hat so um die 3,5TB bei uns. Es würde also um die 270 Stunden dauern, diese Datei zu dedupen. Also 11,25 Tage. Jede Woche (also 7 Tage!) kommt die Menge dazu + die täglichen increments.

Das ist ja mal eine derart schlechte Performance.. das sich das ebenfalls überhaupt nicht lohnt.

Übrigens ist dedupe ein CPU intensiver prozess. I/Os werden nur am Anfang gebraucht wenn ein Hash über die Daten gebildet wird, was sehr sehr schnell geht. Wenn aber die 128k Blöcke an den Kernel zum dedupen übergeben werden, dauert dieser Vorgang aufgrund der vielen kleinen Blöcke sehr sehr lange.


Sehr schade.. da es derzeit die einzige Methode bei BTRFS ist zu dedupen, lohnt ein wechsel von ZFS auf BTRFS aus diesem Grunde überhaupt nicht.

 

[gerry_the_hat]

Veeam macht von Hause aus auch Dedup und Komprimierung, doppelt gemoppelt wird's nicht besser. ZFS kann auch mit LZ4 Komprimierung laufen, das reicht und tut nicht weh.

Siehe
https://helpcenter.veeam.com/docs/backup/vsphere/compression_deduplication.html?ver=95
https://bp.veeam.expert/architecture-overview/backup-repository/deduplication-appliances
https://bp.veeam.expert/operational-guidelines/deduplication-and-compression

 

[coolblue81]

Veeam macht von Hause aus auch Dedup und Komprimierung, doppelt gemoppelt wird's nicht besser. ZFS kann auch mit LZ4 Komprimierung laufen, das reicht und tut nicht weh

Das ist so nicht korrekt Gary. Veeam deduped nur innerhalb des Backprozesses aber nicht übergreifend.
Hinzu kommt das beim Long Term GFS Backup vollständige Fullbackups pro Intervall abgelegt werden.
Diese sind zwar in sich selbst deduped aber nicht untereinander. Entsprechend belegen sie massenweise Terrabytes identischer Daten.

Veeams DeDup kann ruhig aktiv bleiben. Dies spart Datenmengen auf dem Transportweg, denn DeDup erfolgt auf der Source Seite.
Ebenso kann für den Transport Kompression verwendet werden.
Beim Speichern ins Repository muss es aber wieder entkomprimiert werden, damit die DeDup Mechanismen des Dateisystem greifen können.

Ich habe mittlerweile eine funktionierende Lösung gefunden. Sobald ich Zeit habe werde ich davon berichten.
ZFS + OpenDeDup (SDFS) läuft richtig gut in den Tests. Praxisbetrieb steht noch aus. Kommt aber in den nächsten Wochen.
Konstante Schreibgeschwindigkeit von 80mb/s von unique Daten. Genial!

 

[gerry_the_hat]

Ja cool, schreib mal darüber.

Darf ich nochwas dazu loswerden? Sind eher philosophische Überlegungen:

Hört sich an, als würdest du das nicht für privat machen, sprichst von Kunden. Kalkuliert man den Aufwand mal Stundenlohn frage ich mich, ob sich das überhaupt lohnt, schließlich kosten Platten nicht viel.
Ich bevorzuge simple Speicher als Backupziele. Mit dem SDFS ziehst du noch eine Schicht ein, die gewartet werden muss und damit laufende Kosten produziert. Die Komplexität steigt.

Keep it simple und nie nicht die Backups gefährden - ergibt das Sinn oder bin ich nicht mehr zeitgemäß?

 

[lopr]

sehr interessant. danke für die Einsichten.
Ich verwende ZFS dedup für meine live VMs/jails im kleinen Rahmen (250GB SSD mirror) und habe noch nie Einbußen erleben müssen. hoffe das bleibt so, werde wohl demnächst auf 1TB SSDs umsteigen, wenn die Preise weiter so fallen.
Für grosse offsite Backup Deduplikation testen wir gerade borg backup.
Alle mittleren backup tasks direkt mit zfs-send -receive oder über sanoid/syncoid

 

[Ericloewe]

Sehr schade.. da es derzeit die einzige Methode bei BTRFS ist zu dedupen, lohnt ein wechsel von ZFS auf BTRFS aus diesem Grunde überhaupt nicht.

Es lohnt sich nie. Btrfs ist ein Witz, sogar im Wiki gibt es Perlen wie:

• Degraded Mount: mostly OK - applies to raid levels with redundancy: needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present.

Na super, das klingt toll. "Can get stuck ... irreversible"? Anders gesagt, haben die gar keine Ahnung was passiert.

• RAID56: Unstable - write hole still exists

Write hole? In 2018? Das hat niemand wirklich durchdacht... Und es ist schon viel besser als am Anfang des Jahres, weil inzwischen scrub als "mostly OK" markiert wurde, statt "The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes." Das ist jetzt nur auf der RAID56 Seite zu finden: https://btrfs.wiki.kernel.org/index.php/RAID56

Und letztes Jahr war es offiziell noch schlimmer:

• "Auto repair and compression may crash"
• Scrub + RAID5/6: "will verify but not repair"
• Device replace: "gets stuck on devices with bad sectors" (Isn't that the whole point of a disk replacement!?)
• RAID1: "Needs at least two available devices always. Can get stuck in irreversible read-only mode if only one device is present." (Irreversible!?)
• RAID0: OK (Great! You're almost at Intel fakeRAID levels of utility!)
• RAID5/6: "Write hole still exists" (What do you mean "still"? It should never have been there!), parity not checksummed (WTF????!?!!?!??!!??)
• Quotas, qgroups: mostly OK (WTF? It's not rocket science!)
• Free space tree: Too much to copy, but it boils down to "this thing is as fragile as a data structure can be, and our repair tools only make it worse".

I hadn't actually been following btrfs closely and this is much worse than I expected.

Oh, and it doesn't actually "work" on big-endian systems, which I'm guessing is the default mode of operation for Linux on ARM.

Die ganze Geschichte ist absoluter Unsinn. "Ach ja, wir können alles, leider funktioniert halt nichts." Und das ist die optimistische Version...

 

[coolblue81]

Hey alle zusammen,

ich schulde euch noch eine Antwort zu OpenDeDup (SDFS).

Ich konnte meine Tests abschließen, leider hatte ich danach beruflich anderweitig so viel zu tun, dass kaum noch zeit blieb hier was (sinnvolles) zu schreiben und ggf. andere Tests zu machen.

Gehen wir erstmal auf die positiven Seiten von SDFS ein:
1) SDFS ist speziell für DeDup entwickelt. Das merkt man auch daran, dass eine variable Datenerkennung (Alignment & Blocksize) verwendet wird, zur Erkennung von Duplikaten.

Bei meinen Test mit Veeam auf ZFS DeDup ist mir aufgefallen, dass der gleiche (Backup-)Block NICHT dedupliziert wird, wenn das Alignment nicht stimmt. Sprich der Block wurde aufgeteilt in zwei neue Blöcke. Sie sind zwar zusammenhängend, aber ZFS dedupliziert nur EIN Block mit einem ANDEREN Block. Im Veeam war eingestellt, dass er aufs Alignment achten sollte. Trotzdem hatte ich Faktor 2 Datennutzung vom Fullbackup + der Kopie, obwohl die Daten 1:1 gleich waren. Nicht ein Block wurde deduped.

SDFS hingegen macht eine Datenanalyse und vergleicht Blocks mit verschiedenen Größen und dedupliziert diese. Dadurch erkennt SDFS auch identisch Blocks die um ein paar Bits verschoben sind oder sogar deutlich abweichen.

Das funktioniert unglaublich effizient! Ich habe ein Veeam Backup geschrieben.. danach (bei veränderten Aktivdaten) wiederholt noch ein Fullbackup und noch ein Fullbackup. Danach mehrere Veeam-Copys dieser Daten ausgeführt.

Ich hatte auf dem SDFS Volumen wirklich nur 105-110% an Daten belegt. Die 5-10% sind halt neue Daten, Änderungen vorhandener Daten und ggf. etwas Overhead.

Ein Jahresbackup eines typischen Servers im KMU Bereich hätte mich vermutlich maximal Faktor 2 Platz gekostet und gespeichert werden durch Veeam über GFS insg 15 Kopien (Fullbackups) + increments.

2) SDFS hat einen speziellen Backup Modus.
Man kann in SDFS viele Parameter justieren um die Performance und Effizienz anzupassen. Man kann z.b. sagen wie breit er suchen soll um identische Blocks zu finden. Das kostet natürlich Zeit.

Für Backup Zwecke gibts einen speziellen Modus, der alles so tuned, dass eine hohe Streamgeschwindigkeit mit hoher Effizienz gepaart werden.

Bei meinen Tests war ich auch hier schwer begeistert. Ich hatte Backupraten von 70-100mb/s.. also etwas langsamer als direkt auf ZFS. CPU Zeit wurde nicht allzuviel verbraten.

3) Caching und Datenbank
SDFS benötigt für seine DeDup Datebank deutlich weniger RAM als ZFS. Oberflächlich verstanden habe ich das so, dass die DeDup Datenbank in Dateien auf der Festplatte gespeichert sind und von dieser Datenbank es Indizes gibt und nur diese Indizes sind im RAM.

Ich hab hier die Vorteile von ZFS und SDFS kombiniert. 50% des RAMs bekam ZFS um effizient zu arbeiten und um die Datenbank von SDFS zu cachen und SDFS bekam die andere Häfte um vernünftig arbeiten zu können.

Ob das sinnvoll ist, weiß ich nicht, mangels langzeit Test. In der kurzen Zeit liefs jedenfalls performant.

4) Funktionsweise
SDFS ist ein Java Programm, das als Prozess unter Linux läuft. Alle Daten, also die Datenbank, Indizes und die eigentlich Nutzdaten werden wie unter Linux gewohnt wiederum als Dateien abgespeiert. Diese Dateien können auf den üblichen Dateisystemen ext4, xfs, zfs gespeichert und verwaltet werden.

Es wird also im Userspace gemounted. Tut der Performance von 1Gb/s (Netzwerkbandbreite) aber nicht weh.


Was gefiehl mir an SDFS nicht so gut bzw. was war der Grund weswegen ich es nicht nutze!

1) Dokumentation
Die Dokumentation des Projekts ist beschissen. Alles musste ich mir via Google zusammen suchen weil es nicht ordentlich beschrieben und erklärt wurde. Es gab aber ein-zwei findige Leute im Internet die HowTos angefertig haben.

Die offzielle Dokumentation passte nicht zur aktuellen Version. Einige Sachen hatten sich bereits grundlegend geändert, weswegen ich erstmal mit der Stirn gerunzelt habe.
Ich fand das aber nicht soo schlimm, da ich alles was ich gemacht habe, in einem Wiki für weitere Installationen dokumentiert habe.

2) Software Version
Man kann bei dem Projekt grundsätzlich und ausschließlich NUR die neuste Version herunterladen. Selbst nach längerer Recherche und "tricks" wie URL manipulation beim Download halfen nicht, um ältere Versionen zu bekommen.

Wozu benötigte ich das? Einfach aus dem Grund weil die neuste Version defekt war und damit kommen wir zu Punkt 3.

3) Software Qualität
Die haben zuletzt mehrere Minor Versionen rausgebracht, die einfach überhaupt nicht funktionierten. Man konnte ein SDFS Filesystem anlegen und Daten darauf speichern. Jedoch konnte man die Daten nicht mehr lesen!. Java Exception in der Logdatei und das wars. Ich dachte erst ich sei zu blöd, aber das Forum war voll mit Leute die das gleiche Problem hatte und dann auf die letzte Major Version zurück gerudert sind.

Ergo habe auch ich die alte Version suchen müssen und ein anderer User hat sie via Google Drive zur Verfügung gestellt. Mit der Version habe ich dann auch alle Tests gemacht.

4) Datenverlust.....
Beim experimentieren, sponn mein Linux System aus irgendwelchen Gründen.. Hatte Netzwerkprobleme wenn ich mich recht erinnere. Ich habe das Problem gesucht aber anfangs nicht gefunden, also hab ich ganz einfach den Reset Button gedrückt, aus ungeduld. Auf dem System befanden sich schließlich keine Produktivdaten.

Linux bootete ganz normal.. keine probleme, keine Fehler.
SDFS mit mittlerweile 10 TB Testdaten ließ sich nicht mehr mounten. Irgendwas sei kaputt. Gut ich bin natürlich schuld daran, wegen dem Reboot. Aber mal ganz ehrlich.... solche Banalitäten muss ein Dateisystem abfangen können. Dann fehlt eben die letzte Backupdatei.. who cares.. aber doch nicht das ganze Volumen??

Recherche.. Andere User haben das gleiche Problem. "SDFS Filesystem corruption" heißt es. Lösung: Neu machen Backup zurückspielen.

SDFS bietet keinerlei offline Tools oder Mount-parameter um ein Dateisystem zu analysieren. Wirft Java eine Exception weil irgendwas nicht passt, ists einfach vorbei.


Fazit:
Auch wenn ich gerne bereit bin etwas zu experimentieren um neue Lösungen zu schafften, war das Erlebnis einfach too much. Natürlich sind das Backup Daten, dem bin ich mir bewusst. Und ja eine stabile Lösung ist wichtig. Bei dem Kunden wäre es aber so gewesen, dass die Daten nochmal an einen anderen Standort repliziert werden und lokal nochmal eine Wechsel HDD mit einer weiteren Kopie bespielt worden wäre. (Beide Varianten ohne dedup auf Standard Hardware)

Dort sind aber nur die aktuellen Daten der letzten 30 Tage. Auf dem SDFS hätte ich gern das Jahresbackup verwaltet.

Nur so wie es da abgelaufen ist, mit der Code Qualität und dem nicht vorhandenen Support. Nein Danke!


Fazit 2:
OpenDeDup ist Open Source. Das Projekt hat potenzial. Ich kann also nur jedem hier empfehlen zu mindest ein Auge darauf zu werfen und es zu beobachten und ggf. mal selber Erfahrungen zu einem späteren Zeitpunkt zu sammeln.

Weiterhin können sich die ZFS Entwickler am DeDup Erkennungsalghorithmus eine große Scheibe abschneiden. Würde ZFS das so implementieren wie SDFS, wäre SDFS schlagartig überflüssig und ZFS eine Generation weiter.

Hinzu kommt natürlich noch der geringe RAM Verbrauch für die DeDup Tabellen. Schon cool. Aber Datensicherheit geht nun mal vor.

 

[coolblue81]

Hört sich an, als würdest du das nicht für privat machen, sprichst von Kunden. Kalkuliert man den Aufwand mal Stundenlohn frage ich mich, ob sich das überhaupt lohnt, schließlich kosten Platten nicht viel.
Ich bevorzuge simple Speicher als Backupziele. Mit dem SDFS ziehst du noch eine Schicht ein, die gewartet werden muss und damit laufende Kosten produziert. Die Komplexität steigt.

Alles richtig. Wenn ich in sowas Zeit stecke, dann weil ich eine Lösung für viele Kunden erarbeite, welche dann hinreichend dokumentiert wird. Praxis Erfahrungen bei Probleme werden entsprechend auch dokumentiert und kommen dann allen Kunden zugute. Die Lösung wird natürlich auch etwas teuer verkauft.