[Sammelthread] ZFS Stammtisch

[Elektromat]

Servus zusammen,

als ich eben mal im Napp-it meine Disks durchgesehen habe, ist mir aufgefallen, das eine meiner MX500 SSDs aus mirror-1 den Zusatz (slow) enthält, was zuvor definitiv nie der Fall war:

SMART ist mit OK angegeben. Die Betroffene SSD hat auch laut Angabe eine höhere Temperatur als die anderen. Zum Zeitpunkt des Screenshots lag kein wirklicher Traffic auf dem Pool an.

Alle 6 SSDs sind in einem Icy Dock wie folgt:

Zufällig jemand einen Tipp? Hoffe mal die eine gibt nicht den Geist auf.

Grüße
Elektromat

 

[Elektromat]

Hat sich geklärt. Nach stoppen aller VMs und ESXI reboot wird das (slow) nicht mehr vorhanden.
Hab es weiter unter Beobachtung.

 

[gea]

Um zu sehen ob es Performanceprobleme gibt, einen Pool > Benchmark laufen lassen und schauen ob read und sync/async write Werte so sind wie zu erwarten. Monitoring und Acceleration (Top-Menü) dabei deaktivieren.

 

[kandamir]

Eine Frage an @gea, aber gerne auch die anderen. Ich habe bislang von meinen Macs über Time Machine Backups auf meinen Napp-it Server gemacht, das hat auch ganz gut geklappt. Nun habe ich ein Macbook von Catalina auf Monterey aktualisiert (was leider auch nur über neu Aufsetzen und anschließend Datenmigration aus dem vorhandenen Time Machine Backup ging). Schon sehr früh kamen dann Fehlermeldungen, dass der Backupverlauf nicht mehr genutzt werden könne und gelöscht werden solle. Ich habe dann auf dem Napp-it Server das Sparsebundle verschoben (ich will mir jja nicht mein Backup löschen lassen...), um dann ein neues Backup zu beginnen. Nicht schön, aber was soll's... Hat leider nicht geklappt. Time Machine bleibt immer hängen beim Anlegen des sparsebundles ("Creating a sparsebundle using Case-sensitive APFS filesystem"). So bleibt das über Stunden, wenn man nicht abbricht. Die Größe des sparsebundels ändert sich auch nicht mehr. Eigenartig... Das Backup Volume ist ein SMB-Share, welches ich über den Finde gemountet habe. Nach einiger Recherche bin ich auf https://napp-it.org/extensions/afp_en.html gestoßen bzw. habe festgestellt, dass bei mir unter Dienste -> Bonjour die Option "Enable Time Machine Support" nicht aktiviert war. Also aktiviert. Siehe da, jetzt wird ein Time Capsul von meinem Napp-it Server announced, das war vorher nicht so.

Fragen, die sich mir ergeben:

• Es wird beim Einbinden des Time Capsul Shares ein Benutzer abgefragt: ich melde mich mit den User/Passwort an, die ich unter Napp-it angelegt habe und mit dem ich sonst per SMB auf Shares zugreife. Klappt nicht. Gibt es einen speziellen User, der zu verwenden ist.
• Welches Dateisystem wird eigentlich bei dem über Bonjour announcten Time Capsul als Backup Ziel verwendet? Ich habe da keine Konfigurationsmöglichkeit gesehen...
• Hat überhaupt jemand erfolgreich Time Machine in Kombination mit Napp-it in Benutzung bei macOS Big Sur oder neuer? Ein anderer Mac hat noch Catalina laufen - Time Machine Backup auf das gleiche SMB-Share läuft problemlos.

Leider gibt sich der Apple Support ziemlich bockig, sobald man sagt, dass das Time Machine Backup auf ein Netzwerk-Laufwerk geht. Not supported, wenden Sie sich an Ihren NAS Hersteller...

Vorab wie immer vielen Dank. Mir ist bei dem Gedanken mulmig, dass meine Mac Backups nicht funktionieren. Okay, ich habe noch das alte Backup des MacBooks (hatte ich ja nur weg geschoben), aber das ist ja keine Dauerlösung.

Am Platz kann's auch nicht liegen - ich habe gerade meinen Data-Pool um effektiv 15TB erweitert, genügend Platz, um einige Macbooks zu sichern...

 

[Elektromat]

Mhh zu früh gefreut, das (slow) ist wieder genau an der gleichen SSD wie zuvor auch.
Was sagen die Erfahrungswerte?

Folgend ein paar mögliche Gedanken:
- mit Druckluft von staub befreien (lüfter blockieren nur während dem ausblasen) / schauen ob ein kontaktierungsproblem vorliegt /reinigen der kontaktflächen (isopropyl und oder wenn erforderlich mit nem feinen Glasfaserstift)?
- Lieber die betroffene SSD tauschen, oder sogar die zwei aus dem Mirror1?
- evtl. die Pools exportieren und die Solaris VM neu machen. - gute Frage ob das was ändert? Das Checkmk Monitoring der VM ist IO (grün) zumindest nichts ungewöhnliches dort sichtbar.

Hab zwar meine VMs gesichert, würde aber gerne verbeiden dass der gesamte Pool hops geht wenn doch zwei ssds aus einem Mirror den Geist aufgeben.

Spoiler: Benchmark readcache=all

Benchmark: Write: filebench_sequential, Read: filebench, date: 06.01.2022

pool: ssdtank

NAME STATE READ WRITE CKSUM
ssdtank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t500XXXXXXXXXXXXXXX ONLINE 0 0 0
c0t500XXXXXXXXXXXXXXX ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t500XXXXXXXXXXXXXXX ONLINE 0 0 0
c0t500XXXXXXXXXXXXXXX ONLINE 0 0 0 (slow)
mirror-3 ONLINE 0 0 0
c0t500XXXXXXXXXXXXXXX ONLINE 0 0 0
c0t500XXXXXXXXXXXXXXX ONLINE 0 0 0
logs
c1t2d0 ONLINE 0 0 0

host solaris
pool ssdtank (recsize=128K, ssb=-, compr=off, readcache=all)
slog Virtual disk 10.7 GB
encryption -
remark


Fb3 sync=always sync=disabled

Fb4 fivestreamwrite.f sync=always sync=disabled
2246 ops 4174 ops
449.172 ops/s 834.760 ops/s
3537us cpu/op 1112us cpu/op
5.2ms latency 5.9ms latency
448.2 MB/s 833.8 MB/s
________________________________________________________________________________________
randomread.f randomrw.f fivestreamrea
pri/sec cache=all 434.1 MB/s 576.6 MB/s 13.5 GB/s
________________________________________________________________________________________

 

[gea]

Zum Thema Timemachine via SMB:
Dazu muss man ein Dateiesytem mit oplock enabled anlegen (Service Properties SMB) und in Services > Bonjour Timemachine aktivieren. Für das Backup meldet man sich mit einem OmniOS Nutzer an.
vgl https://forums.servethehome.com/ind...ine-support-on-napp-it-with-smb-shares.16309/

Aktuell gibt es ein Problem mit SMB unter OSX und Windows 11. Unter OSX klappt der Zugriff nur mit SMB1 und Gehe zu > cifs://ip. Ob Timemachine damit Probleme macht, kann ich aktuell nicht sagen
vgl https://www.illumos.org/issues/14047


Zur SSD
Ich würde die vermutlich tauschen, eventuell mit WD Data lifeguard noch einen intensiv-Test machen,
z.B. via hirens von einem USB Bootstick, https://www.hirensbootcd.org/

 

[Shihatsu]

Ich wußte nicht genau wo hin, daher hier mal gefragt. Es geht ums Thema Backup.
Bisher ist mein Backup wie folgt:
Truenas hat einen Datapool, in diesem Datapool sind diverse vdevs. Ein Teil dieser vdevs (eben das was doof ist wenns weg wäre -> backup) wird per nächtlichem rsync-task auf ein Synology NAS übertragen.

Jetzt ist das natürlich doof wenn meine Hütte brennt -> alles weg. Ich hatte in der Vergangenheit eine Platte (genau genommen 2) am Synology hängen, die ich regelmäßig ausgetauscht habe und die den gesamten Datenbestand der Synology enthielten. Zusammen mit dem Backup AUF die Synology dauert das jetzt aber leider zu lange. Dazu kommt noch das ich gerne ALLE Daten des Datapools ohne Umweg über das Synology machen würde. Also größere Platte direkt ans TrueNAS. Wie mache ich da am schlauesten die backups? Ebenfalls per rsync? Scheint mir ja doof, hab ja tolles ZFS...

 

[tekken321]

Habe ZFS über NappIT bei mir mal über 2 Jahren eingerichtet und dann auch nicht mehr wirklich angefasst. Ich nutze nen SSD-Mirror für die VM und einmal ein RaidZ2 (6x6 TB) für Daten (4K Videos und Backup von PC/Dokumenten etc), also ne Mischung aus kleinen und großen Dateien. Da jetzt zwei der 6 HDD laut Smart-Werte Probleme machen (Scrub/Pool ohne Fehler) möchte ich diese austauschen bzw. in dem Zuge die Kapazität im allgemeinen erhöhen und die "alten" HDD umziehen Richtung Backup. Soviel zur Ausgangslage.
Um die Kapazität zu erhöhen hab ich mir jetzt neue Festplatten gekauft (6x14TB) und könnte diese entweder a) Nacheinander hinzufügen -> jedes Mal resilvern oder da ich noch nen HBA rumliegen habe, diese dort alle anschließen, neuen Pool und dann per zfssend? die Daten auf den neuen Pool kopieren? Sollte dies so funktionieren, würde ich nochmal nen neuen RaidZ2 Pool aus den 6 HDD erstellen und damit komme ich schon zu der ersten Frage:
Im Proxmoxforum lese/stolpere ich über den Begriff Vollblocksize, der von ZFS wohl standartmäßig bei 8k liegt?oder ist das nur bei Proxmox so? Sollte man diesen erhöhen oder so lassen? Hier im Forum hab ich wiederrum gelesen, sofern lz4 Compression eingeschaltet ist, wäre die Blocksize egal? Ist damit etwas anderes gemeint ?
Gibt es ansonsten Einstellungen die man nur beim erstellen des Pools setzen kann, die sinnvoll sind?
Zur Zeit habe ich der Storage-VM 40GB Ram gegeben bei max. 64GB im Server (mehr Ram ist leider nicht möglich ohne die ganze Basis zu erneuern). Man liest ja hier und da dass ZFS 1Gb Ram pro TB Nutzkapazität haben sollte, macht das einen großen Unterschied wenn es nicht der Fall ist?

Vielen Dank schonmal.

 

[andrer250282]

Ich wußte nicht genau wo hin, daher hier mal gefragt. Es geht ums Thema Backup.
Bisher ist mein Backup wie folgt:
Truenas hat einen Datapool, in diesem Datapool sind diverse vdevs. Ein Teil dieser vdevs (eben das was doof ist wenns weg wäre -> backup) wird per nächtlichem rsync-task auf ein Synology NAS übertragen.

Jetzt ist das natürlich doof wenn meine Hütte brennt -> alles weg. Ich hatte in der Vergangenheit eine Platte (genau genommen 2) am Synology hängen, die ich regelmäßig ausgetauscht habe und die den gesamten Datenbestand der Synology enthielten. Zusammen mit dem Backup AUF die Synology dauert das jetzt aber leider zu lange. Dazu kommt noch das ich gerne ALLE Daten des Datapools ohne Umweg über das Synology machen würde. Also größere Platte direkt ans TrueNAS. Wie mache ich da am schlauesten die backups? Ebenfalls per rsync? Scheint mir ja doof, hab ja tolles ZFS...

Also wenn du pool auf Pool synchron halten willst, ich habe sehr gute Erfahrungen mit zrep gemacht

zrep - Cross-platform ZFS based replication and failover system

Nach dem initialisieren werden nur noch die Differenzen zwischen den Snapshots übertragen, das geht blitzschnell. Ich halte damit ein ein 70TB pool über 2 Server im 5min Takt synchron, inkl Failoverfunktionen

 

[asche77]

Um die Kapazität zu erhöhen hab ich mir jetzt neue Festplatten gekauft (6x14TB) und könnte diese entweder a) Nacheinander hinzufügen -> jedes Mal resilvern oder da ich noch nen HBA rumliegen habe, diese dort alle anschließen, neuen Pool und dann per zfssend? die Daten auf den neuen Pool kopieren? Sollte dies

Definitiv Variante 2 -- nacheinander einfügen ist deutlich risikoreicher.

Im Proxmoxforum lese/stolpere ich über den Begriff Vollblocksize, der von ZFS wohl standartmäßig bei 8k liegt?oder ist das nur bei Proxmox so? Sollte man diesen erhöhen oder so lassen? Hier im Forum hab ich wiederrum gelesen, sofern lz4 Compression eingeschaltet ist, wäre die Blocksize egal? Ist damit etwas anderes gemeint ?

Ich vermute, Du musst Dir darum keine Gedanken machen.

Gibt es ansonsten Einstellungen die man nur beim erstellen des Pools setzen kann, die sinnvoll sind?

ashift = 12 oder ashift = 13 ist wohl die wichtigste!

Zur Zeit habe ich der Storage-VM 40GB Ram gegeben bei max. 64GB im Server (mehr Ram ist leider nicht möglich ohne die ganze Basis zu erneuern). Man liest ja hier und da dass ZFS 1Gb Ram pro TB Nutzkapazität haben sollte,

Das ist eher eine urban myth. 1GB RAM pro TB braucht man allenfalls für deduplication. mit 40GB RAM für die Storage VM bist Du schon sehr gut aufgestellt -- bringt das maximum an Schreibcache (lower of 10% RAM or 4GB).

 

[gea]

.. . Also größere Platte direkt ans TrueNAS. Wie mache ich da am schlauesten die backups? Ebenfalls per rsync? Scheint mir ja doof, hab ja tolles ZFS...

Via zfs Replikation.
Basiert auf Snaps (nimmt auch offene Dateien mit) und überträgt beim Sync nur geänderte Datenblöcke. Damit kann man selbst zwei Hochlast Petabyte Systeme mit einer Minute Verzögerung syncron halten.

 

[besterino]

…und das mit dem 1GB RAM pro 1TB Speicherplatz bei Dedup ist dann bisweilen sogar noch (deutlich) zu wenig:

ZFS: To Dedupe or Not to Dedupe…

…that is the question. Ever since the introduction of deduplication into ZFS, users have been divided into two camps: One side enthusiastically adopted deduplication as a way to save storage space, while the other remained skeptical, pointing out that dedupe has a cost, and that it may not be...

constantin.glez.de

Er rechnet mit ca. 5GB (avg. blocksize 64k) mal 4 = 20GB RAM pro TB Pool-Storage, wenn man wegen der 1/4 ARC Beschränkung wirklich die ganze dedup table im RAM halten will…

So auch hier:

Aaron Toponce : ZFS Administration, Part XI- Compression and Deduplication

pthree.org

Keine Ahnung ob das im
Jahr 2022 noch stimmt, müsste man glatt mal ausprobieren…und ich müsste wieder Rdimms shoppen oder mich mit der Meta-arc-tunable beschäftigen…

ZFS Deduplication requirements and performance

I have search though and there seems to be various formula throw up for the amount of ram required for deduplication. Is the ram requirement based on the actual size (block) of the pool or the amount of data (block) used in that pool. I.e. if my pool is 2T and 50% utilized, is it based on 2T or...

hardforum.com

EDIT & NACHTRAG: bei Solaris 11.4 (glaub schon seit 11/11.1?) ist das tatsächlich anders. Standardmäßig reserviert das System keinen RAM für was anderes: entsprechende Parameter sind standardmäßig so gesetzt, dass der ARC bis zur physischen Grenze (minus 1GB) gehen kann:

Oracle Solaris 11.4 Tunable Parameters Reference Manual

docs.oracle.com

Oracle Solaris 11.4 Tunable Parameters Reference Manual

docs.oracle.com

Kann mich also wieder hin- und den Geldbeutel weglegen…

 

[gea]

Die früheren Kriterien gelten so nicht mehr. Oracle Solaris hat seit Pool v.40 Dedup2 das wohl eine deutliche Verbesserung brachte, https://docs.oracle.com/cd/E37838_01/html/E61017/gjxle.html.

Unter Open-ZFS würde ich einen special vdev mirror statt RAM für die dedup table einsetzen

 

[tekken321]

Definitiv Variante 2 -- nacheinander einfügen ist deutlich risikoreicher.

Übernimmt der Befehl zfssend dann auch die Ordnerstruktur innerhalb des Pools? Also z.B. Pool "data" die einzelnen Unterordner "media" etc.? Klar SMB Freigabe und sowas vermutlich wieder neu aber der Rest?

Ich vermute, Du musst Dir darum keine Gedanken machen.

Die Vermutung könnte richtig sein ^^. Mir geht es eher darum, dass dies wohl die allgemeine Speicherkapazität erhöht? Ich glaube ich aktiviere einfach die Compression, dann müsste es ja auch passen.

ashift = 12 oder ashift = 13 ist wohl die wichtigste!

ashift=12 habe ich bereits, wird glaub auch so von gea empfohlen?

Das ist eher eine urban myth. 1GB RAM pro TB braucht man allenfalls für deduplication. mit 40GB RAM für die Storage VM bist Du schon sehr gut aufgestellt -- bringt das maximum an Schreibcache (lower of 10% RAM or 4GB).

Dann passt das ja, danke.

 

[Trambahner]

Dedup ist fürs Homelab sowieso eher uninteressant. Wer hat da schon Riesenmengen an völlig identischen Datenblöcken in seinen Datasets und Vols.
Leere Blöcke von VM-Diskimages z.B, frühstückt die Komprimierung gut genug ab. LZ4 an und man ist "good to go" in den allermeisten Fällen.

 

[Shihatsu]

Via zfs Replikation.
Basiert auf Snaps (nimmt auch offene Dateien mit) und überträgt beim Sync nur geänderte Datenblöcke. Damit kann man selbst zwei Hochlast Petabyte Systeme mit einer Minute Verzögerung syncron halten.

Kann ich die Replikation auf die externe Platte auch verschlüsseln?

 

[besterino]

@Trambahner: bei mehreren VMs auf gleicher OS- bzw. Distri-Basis könnte das schon noch was bringen. Ich will das vor allem unbedingt mal mit zentralisierten Steam-/Epic-/Origin-/etc.-Game-Libraries von mehreren Rechnern auf iSCSI-Basis ausprobieren. Da könnte ich teilweise definitiv auf einen dedup-Faktor von mehr als 3-4 kommen.

Aber bevor es damit wirklich losgehen kann, muss ich dazu leider noch ein paar Themen vorbereiten/umsetzen...

 

[Happy Hepo]

@gea: für meine Kingston DC500R wird in der SMART-Übersicht von Nappit das falsche Attribut ausgelesen.

Ausgelesen wird:
231 Temperature_Celsius 0x0000 098 098 000 Old_age Offline - 98
Laut Doku (https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf) ist das SSD LifeRemaining
Korrekt wäre:
194 Temperature_Celsius 0x0022 063 054 000 Old_age Always - 37 (Min/Max 21/46)

Ist das ein Problem von smartmontools, oder ein Bug in Nappit?

 

[gea]

Übernimmt der Befehl zfssend dann auch die Ordnerstruktur innerhalb des Pools? Also z.B. Pool "data" die einzelnen Unterordner "media" etc.? Klar SMB Freigabe und sowas vermutlich wieder neu aber der Rest?

Man muss zwischen einfachen Ordnern und geschachtelten ZFS Dateisystemen unterscheiden. Sehen zwar beim Auflisten der Dateien gleich aus, werden aber unterschiedlich gehandhabt. Einfache Unterordner werden immer mit übertragen, geschachtelte Dateisysteme nur bei recursivem zfs send.

SMB Freigabe ist (zumindest bei Solaris/Illumos basiertem ZFS) eine feste Eigenschaft eines ZFS Dateisytems die mit übertragen wird. In napp-it kann man Freigaben in der Replikation aber deaktivieren.

Die Vermutung könnte richtig sein ^^. Mir geht es eher darum, dass dies wohl die allgemeine Speicherkapazität erhöht? Ich glaube ich aktiviere einfach die Compression, dann müsste es ja auch passen.

Kompression und dedup wirken nicht auf vorhandene sondern nur auf neu hinzugefügte Daten.

ashift=12 habe ich bereits, wird glaub auch so von gea empfohlen?

Ashift=12 bedeutet 4k Datenblöcke. Ist also perfekt für aktuelle Festplatten mit 4k physical sectorsize. Auch bei alten 512b Platten würde ich ashift 12 nehmen. Damit kann man die später problemlos mit neueren Platten ersetzen. Auch sind remove Aktionen z.B. bei special vdev nur möglich wenn alle vdev (ashift ist per vdev) gleich sind. Abweichen von ashift=12 würde ich daher nur in sehr begründeten Sonderfällen.

Dann passt das ja, danke.

Beitrag automatisch zusammengeführt: 03.06.2022

Kann ich die Replikation auf die externe Platte auch verschlüsseln?

Bei Open-ZFS kann man unverschlüsselte Dateisysteme unterhalb eines verschlüsselten Ziels senden. Es wird dann mit dessen Schlüssel verschlüsselt. Man kann auch ein bereits verschlüsseltes Dateisystem "raw" senden. Der Schlüssel bleibt dabei erhalten. Diese raw Option gibt es nicht bei Solaris und Original ZFS. In zentralisierten Strukturen ist das auch problematisch da man dann sehr viele Schlüssel verwalten muss.

Beitrag automatisch zusammengeführt: 03.06.2022

@gea: für meine Kingston DC500R wird in der SMART-Übersicht von Nappit das falsche Attribut ausgelesen.

Ausgelesen wird:
231 Temperature_Celsius 0x0000 098 098 000 Old_age Offline - 98
Laut Doku (https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf) ist das SSD LifeRemaining
Korrekt wäre:
194 Temperature_Celsius 0x0022 063 054 000 Old_age Always - 37 (Min/Max 21/46)

Ist das ein Problem von smartmontools, oder ein Bug in Nappit?

Smartmontools liefert Rohdaten. Napp-it wird hier wohl durch den String "Temperature" bei 231 irritiert.

 

[MisterY]

Hat jemand von euch einen Marvell SATA Controller in Benutzung? Ich habe mein zfspool in einen anderen Server importiert mit eben solchen. Und die beiden Disks, die am Marvell hängen, werfen Fehler aus. Die Disks an der Intel Southbridge, HP H240 und Dell H310 laufen ohne Probleme.

 

[gea]

@gea: für meine Kingston DC500R wird in der SMART-Übersicht von Nappit das falsche Attribut ausgelesen.

Ausgelesen wird:
231 Temperature_Celsius 0x0000 098 098 000 Old_age Offline - 98
Laut Doku (https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf) ist das SSD LifeRemaining
Korrekt wäre:
194 Temperature_Celsius 0x0022 063 054 000 Old_age Always - 37 (Min/Max 21/46)

Ist das ein Problem von smartmontools, oder ein Bug in Nappit?

Update
Die Attributnummer gibt es nur bei Sata Platten. Bei SAS ist das komplizierter.
Ich unterscheide das jetzt in napp-it ab 21.06. Die Temperatur sollte jetzt korrekt angezeigt werden. Bitte überprüfen.

 

[Happy Hepo]

Update
Die Attributnummer gibt es nur bei Sata Platten. Bei SAS ist das komplizierter.
Ich unterscheide das jetzt in napp-it ab 21.06. Die Temperatur sollte jetzt korrekt angezeigt werden. Bitte überprüfen.

Jetzt wird die Temperatur korrekt angezeigt, danke für die schnelle Anpassung!

 

[tekken321]

Man muss zwischen einfachen Ordnern und geschachtelten ZFS Dateisystemen unterscheiden. Sehen zwar beim Auflisten der Dateien gleich aus, werden aber unterschiedlich gehandhabt. Einfache Unterordner werden immer mit übertragen, geschachtelte Dateisysteme nur bei recursivem zfs send.

Also wenn ich unter ZFS Filesystem schaue, dann sehe ich meine erstellten Dateisysteme mit z.b. data/media/movies usw., dann gehe ich mal davon aus es handelt sich hierbei um geschachtelte Dateisysteme. Das heisst ich kann die dann nur mit recursivem zfs send auf den neuen Pool kopieren? Kann ich bei meinem vorhaben einen neuen Pool mit dem gleichen Namen wie dem ersten erstellen? Ich würde dann einen neuen Pool erzeugen mit dem Namen "data" und vom "alten data" (den 6x6 TB) auf den neuen per recursivem zfs alles rüberkopieren, und den alten dann anschliessend löschen bzw. kann man den dann auch einfach umbenennen?

 

[Bzzz]

Er rechnet mit ca. [...] 20TB RAM pro TB Pool-Storage, wenn man wegen der 1/4 ARC Beschränkung wirklich die ganze dedup table im RAM halten will…

Würde dann zur RAM-Disk raten, mit nur 1/20 = 5% Mehraufwand ist man alle disk-seitigen Performanceprobleme für alle Ewigkeit los und kann seine Daten hintendran auch wieder auf Tape halten

 

[besterino]

Sorry hab mich auch um nen tausender vertan. GB mein ich natürlich..

 

[gea]

Also wenn ich unter ZFS Filesystem schaue, dann sehe ich meine erstellten Dateisysteme mit z.b. data/media/movies usw., dann gehe ich mal davon aus es handelt sich hierbei um geschachtelte Dateisysteme. Das heisst ich kann die dann nur mit recursivem zfs send auf den neuen Pool kopieren?

ja
Man muss nur beachten dass die Replikationen unterhalb eines Zieldateisystems angelegt werden, z.B.
pool/media/* -> pool2/media recursive ergibt pool2/media/media/*

Will man das nicht, dann einzeln replizieren z.B.
pool/media -> pool2 ergibt pool2/media

Kann ich bei meinem vorhaben einen neuen Pool mit dem gleichen Namen wie dem ersten erstellen?

nein, man müsste den alten Pool zuerst umbenennen

Ich würde dann einen neuen Pool erzeugen mit dem Namen "data" und vom "alten data" (den 6x6 TB) auf den neuen per recursivem zfs alles rüberkopieren, und den alten dann anschliessend löschen bzw. kann man den dann auch einfach umbenennen?

Umbenennen eines Pools:
- pool export
- pool import mit anderem Namen

 

[tekken321]

Kompression und dedup wirken nicht auf vorhandene sondern nur auf neu hinzugefügte Daten.

Bezüglich diesem Punkt hätte ich noch eine Frage. Auf dem "alten" Pool hab ich keine Kompression aktiviert, auf dem neuen würde ich es machen. Wenn ich die Dateien per zfs send recursive vom alten auf den neuen Pool kopiere würden die dann als "neu hinzugefügt" gelten und somit wäre die Kompression auch für diese Dateien aktiv oder müsste ich dann z.B. beide Pools über SMB o.ä. auf einer in meinem Falle Win10-VM verbinden und dann kopieren? Ich hoffe es ist verständlich wie ich das meine.

 

[kandamir]

Zum Thema Timemachine via SMB:
Dazu muss man ein Dateiesytem mit oplock enabled anlegen (Service Properties SMB) und in Services > Bonjour Timemachine aktivieren. Für das Backup meldet man sich mit einem OmniOS Nutzer an.
vgl https://forums.servethehome.com/ind...ine-support-on-napp-it-with-smb-shares.16309/

Erst einmal vielen Dank für die Rückmeldung, bin erst heute dazu gekommen, mich wieder damit auseinanderzusetzen...

Das mit "Dateisystem mit oplock enabled" anlegen ist mir nicht ganz klar. In den SMB Properties ist das enabled. Aber pro Filesystem?

Hier die Einstellungen für SMB:

Bonjour müsste für mein Verständnis auch korrekt eingestellt sein:

In welches Filesystem wird denn für das hier konfigurierte Time Capsul verwendet?

Aktuell gibt es ein Problem mit SMB unter OSX und Windows 11. Unter OSX klappt der Zugriff nur mit SMB1 und Gehe zu > cifs://ip. Ob Timemachine damit Probleme macht, kann ich aktuell nicht sagen
vgl https://www.illumos.org/issues/14047

Mit dem verlinkten Thread kann ich jetzt nicht so viel mit anfangen. Aber per cifs kann ich das Share zwar mounten, in Time Machine steht es dann jedoch nicht als Backupziel zur Auswahl (Volume not offered as a Time Machine destination because it does not have the correct capabilities.). Wenn ich es per SMB mounte, wird es angeboten und kann auch das Backup starten, aber über das Anlegen des Sparsebundles hinaus kommt er nicht. Log anbei, etwas anonymisiert:

2022-06-07 19:47:07.263650+0200 0x2e89     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/System/Volumes/Data/home' not offered as a Time Machine destination because it does not allow read, write, or append access.
2022-06-07 19:47:07.263730+0200 0x2e8a     Error       0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share1/', error: Inappropriate ioctl for device
2022-06-07 19:47:07.263782+0200 0x2d50     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/' not offered as a backup destination because it is the root volume
2022-06-07 19:47:07.263845+0200 0x2e8c     Error       0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share2/', error: Inappropriate ioctl for device
2022-06-07 19:47:07.263902+0200 0x2e89     Error       0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share1/', error: Inappropriate ioctl for device
2022-06-07 19:47:07.263964+0200 0x2e89     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/Volumes/Share1' not offered as a Time Machine destination because it does not have the correct capabilities.
2022-06-07 19:47:07.264017+0200 0x2e8d     Error       0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share2/', error: Inappropriate ioctl for device
2022-06-07 19:47:07.264083+0200 0x2e8b     Error       0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share3/', error: Inappropriate ioctl for device
2022-06-07 19:47:07.264135+0200 0x2e8a     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/Volumes/Share1' not offered as a Time Machine destination because it does not have the correct capabilities.
2022-06-07 19:47:07.264197+0200 0x2e8e     Error       0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share3/', error: Inappropriate ioctl for device
2022-06-07 19:47:07.264290+0200 0x2e8c     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/Volumes/Share2' not offered as a Time Machine destination because it does not have the correct capabilities.
2022-06-07 19:47:07.264428+0200 0x2b92     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/dev' not offered as a backup destination because it is not browsable
2022-06-07 19:47:07.264471+0200 0x2e8d     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/Volumes/Share2' not offered as a Time Machine destination because it does not have the correct capabilities.
2022-06-07 19:47:07.264559+0200 0x2e8b     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/Volumes/Share3' not offered as a Time Machine destination because it does not have the correct capabilities.
2022-06-07 19:47:07.264655+0200 0x2e8e     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/Volumes/Share3' not offered as a Time Machine destination because it does not have the correct capabilities.
2022-06-07 19:47:07.264768+0200 0x2e88     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/System/Volumes/Data' not offered as a backup destination because it is not browsable
2022-06-07 19:47:07.264877+0200 0x2e85     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/System/Volumes/VM' not offered as a backup destination because it is not browsable
2022-06-07 19:47:07.264936+0200 0x2e86     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/System/Volumes/Preboot' not offered as a backup destination because it is not browsable
2022-06-07 19:47:07.265089+0200 0x2e87     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] '/System/Volumes/Update' not offered as a backup destination because it is not browsable
2022-06-07 19:47:34.139043+0200 0x118e     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Initial network volume parameters for 'Backup-1' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 0, QoS: 0x0, attributes: 0x1C}
2022-06-07 19:47:34.277170+0200 0x118e     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Configured network volume parameters for 'Backup-1' {disablePrimaryReconnect: 1, disableSecondaryReconnect: 0, reconnectTimeOut: 60, QoS: 0x20, attributes: 0x1C}
2022-06-07 19:47:34.384343+0200 0x118e     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:DiskImages] Did not match sparsebundle 'Anderer_Mac_1.backupbundle' with host UUID 'UUID_Anderer_Mac_1' and MAC address '(null)'
2022-06-07 19:47:34.406645+0200 0x118e     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:DiskImages] Did not match sparsebundle 'Anderer_Mac_2.backupbundle' with host UUID 'UUID_Anderer_Mac_2' and MAC address '(null)'
2022-06-07 19:47:34.412690+0200 0x118e     Info        0x0                  669    0    com.apple.prefs.backup.remoteservice: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/Backup-1' is still valid
2022-06-07 19:47:34.449551+0200 0x2a98     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:Cancellation] Requested backup cancellation or termination before 2022-06-07 17:48:34 +0000
2022-06-07 19:49:34.101434+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:BackupScheduling] Not prioritizing backups with priority errors. lockState=0
2022-06-07 19:49:34.101684+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Starting manual backup
2022-06-07 19:49:34.102097+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:Cancellation] Cleared pending cancellation request
2022-06-07 19:49:34.103911+0200 0x33d5     Error       0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share1/', error: Inappropriate ioctl for device
2022-06-07 19:49:34.104079+0200 0x33d5     Error       0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share3/', error: Inappropriate ioctl for device
2022-06-07 19:49:34.104194+0200 0x33d5     Error       0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share2/', error: Inappropriate ioctl for device
2022-06-07 19:49:34.104272+0200 0x33d5     Error       0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share2/', error: Inappropriate ioctl for device
2022-06-07 19:49:34.104523+0200 0x33d5     Error       0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share1/', error: Inappropriate ioctl for device
2022-06-07 19:49:34.104681+0200 0x33d5     Error       0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Failed to read capabilities for 'file:///Volumes/Share3/', error: Inappropriate ioctl for device
2022-06-07 19:49:34.130661+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:Mounting] Rejecting candidate mount point: /Volumes/Backup, not owned by root
2022-06-07 19:49:34.133877+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:Mounting] Attempting to mount 'smb://USER@san._smb._tcp.local/Backup'
2022-06-07 19:49:34.764527+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:Mounting] Mounted 'smb://USER@san._smb._tcp.local/Backup' at '/Volumes/.timemachine/san._smb._tcp.local/UUID_Zu_sichernder_Mac/Backup' (16,49 TB of 20 TB available)
2022-06-07 19:49:34.764864+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Initial network volume parameters for 'Backup' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 0, QoS: 0x0, attributes: 0x1C}
2022-06-07 19:49:34.968341+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Configured network volume parameters for 'Backup' {disablePrimaryReconnect: 0, disableSecondaryReconnect: 0, reconnectTimeOut: 30, QoS: 0x20, attributes: 0x1C}
2022-06-07 19:49:35.238086+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/san._smb._tcp.local/UUID_Zu_sichernder_Mac/Backup' is still valid
2022-06-07 19:49:35.250955+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:General] Mountpoint '/Volumes/.timemachine/san._smb._tcp.local/UUID_Zu_sichernder_Mac/Backup' is still valid
2022-06-07 19:49:35.255484+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:DiskImages] Using a band size of 256 MB (max bands set to 16384, image size 19 TB)
2022-06-07 19:49:35.258421+0200 0x33d5     Info        0x0                  275    0    backupd: (TimeMachine) [com.apple.TimeMachine:DiskImages] Creating a sparsebundle using Case-sensitive APFS filesystem

Laut Berechtigungen in Napp-it sind die Share-ACL auf full_set. Die Folder ACL sind auf Special gesetzt, da hat der Nutzer, mit dem ich mich per SMB anmelde aber Schreibrechte

 

[gea]

zu op

Erst einmal vielen Dank für die Rückmeldung, bin erst heute dazu gekommen, mich wieder damit auseinanderzusetzen...

Das mit "Dateisystem mit oplock enabled" anlegen ist mir nicht ganz klar. In den SMB Properties ist das enabled. Aber pro Filesystem?

Hier die Einstellungen für SMB:

Korrekt, oplock ist keine ZFS Eigenschaft sondern eine globale Einstellung eines SMB Servers

Bonjour müsste für mein Verständnis auch korrekt eingestellt sein:
Anhang anzeigen 766190

Anhang anzeigen 766191

In welches Filesystem wird denn für das hier konfigurierte Time Capsul verwendet?

Die Einstellungen sind nicht ganz aktuell
Folgendes ist aktuell default:

#!/usr/bin/bash
/usr/bin/dns-sd -R "nas" _smb._tcp local 445 &
/usr/bin/dns-sd -R "nas" _device-info._tcp local 445 model=Xserve &
/usr/bin/dns-sd -R "nas" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=timecapsule,adVF=0x82' &

In diesem Fallwird der SMB Server als Xserve dargestellt und ein Share namens "timecapsule" für Timemachine bekanntgegeben. Das diesem Share zugrunde liegende Dateisystem wird benutzt.

Mit dem verlinkten Thread kann ich jetzt nicht so viel mit anfangen. Aber per cifs kann ich das Share zwar mounten, in Time Machine steht es dann jedoch nicht als Backupziel zur Auswahl (Volume not offered as a Time Machine destination because it does not have the correct capabilities.). Wenn ich es per SMB mounte, wird es angeboten und kann auch das Backup starten, aber über das Anlegen des Sparsebundles hinaus kommt er nicht. Log anbei, etwas anonymisiert:

Im Prinzip bedeutet das,
Mit cifs://serverip vom Mac aus wird SMB v1 benutzt. Mit smb://serverip wird SMB3 benutzt. SMB 3 funktioniert aktuell unter Windows 11 nur mit den bisherigen 128bit Cipher und OSX v12 garnicht. Als Workaround unter OSX muss man momentan für normalen Serverzugriff cifs benutzen. Timemachine will aber SMB3 und diverse Apple Spezielitäten. Ich vermute mal für Timemachine muss man warten bis OmniOS einen bugfix bereitstellt.

Beitrag automatisch zusammengeführt: 07.06.2022

Bezüglich diesem Punkt hätte ich noch eine Frage. Auf dem "alten" Pool hab ich keine Kompression aktiviert, auf dem neuen würde ich es machen. Wenn ich die Dateien per zfs send recursive vom alten auf den neuen Pool kopiere würden die dann als "neu hinzugefügt" gelten und somit wäre die Kompression auch für diese Dateien aktiv oder müsste ich dann z.B. beide Pools über SMB o.ä. auf einer in meinem Falle Win10-VM verbinden und dann kopieren? Ich hoffe es ist verständlich wie ich das meine.

ZFS send schreibt alls Daten neu. Mit aktiviertem lz4 auf dem Ziel (im parent Dateisystem, Einstellung wird dann vererbt) werden die daher dann komprimiert.

 

[kandamir]

Die Einstellungen sind nicht ganz aktuell
Folgendes ist aktuell default:

#!/usr/bin/bash
/usr/bin/dns-sd -R "nas" _smb._tcp local 445 &
/usr/bin/dns-sd -R "nas" _device-info._tcp local 445 model=Xserve &
/usr/bin/dns-sd -R "nas" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=timecapsule,adVF=0x82' &

Habe ich angepasst und auch den Namen des Share statt "timecapsule" eingetragen. Das führt dazu, dass man das so announcte Timecapsule verbinden kann (vorher hatte das ja mit der Authentisierung nciht geklappt). Im Endergebnis blieb das Backup aber auch hier beim Anlegen des Sparsebundles hängen...

Im Prinzip bedeutet das,
Mit cifs://serverip vom Mac aus wird SMB v1 benutzt. Mit smb://serverip wird SMB3 benutzt. SMB 3 funktioniert aktuell unter Windows 11 nur mit den bisherigen 128bit Cipher und OSX v12 garnicht. Als Workaround unter OSX muss man momentan für normalen Serverzugriff cifs benutzen. Timemachine will aber SMB3 und diverse Apple Spezielitäten. Ich vermute mal für Timemachine muss man warten bis OmniOS einen bugfix bereitstellt.

CIFS kann ich im FInder zwar mounten, aber Timemachine juckt das nicht. Das Share wird in dem Fall nicht als für Timemachine nutzbares Share angezeigt...

Hmm, kein Backup, bis ggf. irgendwann mal dieser Bug gefixt wird (der ja wohl auch nicht erst sein gestern bekannt ist) - klingt nicht sehr attraktiv... Wäre echt eine Überlegung wert, wieder das alte Backup einzuspielen und Monterey erst einmal beiseite zu legen...