Verlauf der Änderungen der Seite ManagingZFS
Hinzugefügt:
((2)) Rename only
Keine Verschiebung zwischen Pools, sondern lediglich Namensänderung innerhalb eines Pools:
##zfs rename pool/path/oldname pool/path/newname##
oder (inkl. Pfadänderung!)
##zfs rename pool/oldpath/datasetname pool/newpath/datasetname##
Keine Verschiebung zwischen Pools, sondern lediglich Namensänderung innerhalb eines Pools:
##zfs rename pool/path/oldname pool/path/newname##
oder (inkl. Pfadänderung!)
##zfs rename pool/oldpath/datasetname pool/newpath/datasetname##
Hinzugefügt:
# ACHTUNG: Darstellung oben ist etwas zu einfach - man sollte besser die Datenträger "by-id"
# nehmen - der Befehl würde dann eher so ausschauen:
zpool add storage mirror /dev/disk/by-id/ata-WDC_langeID1 /dev/disk/by-id/ata-WDC_langeID2
# nehmen - der Befehl würde dann eher so ausschauen:
zpool add storage mirror /dev/disk/by-id/ata-WDC_langeID1 /dev/disk/by-id/ata-WDC_langeID2
Hinzugefügt:
# create datasets
zfs create pool/home
zfs set mountpoint=/export/home pool/home
zfs create pool/home
zfs set mountpoint=/export/home pool/home
Hinzugefügt:
((1)) ZFS Befehle unter FreeBSD (FreeNAS / TrueNAS)
##pool##s, ##dataset##s und der Umgang mit ihnen
Eines der wesentlichen Bestandteile von FreeNAS ist das Dateisystem ZFS. Mit den unten genannten Befehlen können wichtige Funktionen dieses fortschrittlichen Systems genutzt werden.
((2)) Scrubs und Snapshots
Einige Befehle zum Anlegen und Verwalten von Snapshots:
((3)) Anzeige von Parametern
Anzeigen von Speicherplatz, der von einem Snapshot belegt ist in der Konsole:
##zfs list -t snapshot##
((3)) Eigenschaften eines ##dataset##
##zfs get all pfad/zum/dataset##
((2)) Moving datasets (and complete pools)
Siehe hier: https://www.ixsystems.com/community/threads/copy-move-dataset.28876/#post-190178
Im Einzelnen geht dies so:
1. Create final source snapshot:
##zfs snapshot -r Datasource/Storage@copy##
2. Copy the data:
##zfs send -Rv Datasource/Storage@copy | zfs receive -F Datatarget/Storage##
an ein anderes System per ssh:
##zfs send -Rv Datasource/Storage@copy | **ssh host2** zfs receive -F Datatarget/Storage##
3. Delete created snapshots:
##zfs destroy -r Datatarget/Storage@copy ; zfs destroy -r Datasource/Storage@copy##
Vgl. dazu auch ein komplettes Backup-Konzept mit ZFS-Platten hier:
https://esc-now.de/_/zfs-offsite-backup-auf-eine-externe-festplatte/?lang=en
Sowie andere Infos:
https://www.kirgus.net/cms_homepage8/zfs-datasetzvol-auf-anderen-pool-umziehen
((2)) Encryption / Verschlüsselung (nativ on ZFS)
Wenn man nachträglich verschlüsseln möchte (zum Beispiel ein dataset) ist dies nicht so einfach möglich. Wenn man Daten nicht auf dateiebene in ein verschlüsseltes Verzeichnis kopieren will, kann man mit den datasets so arbeiten:
(siehe auch [[https://nocin.eu/zfs-send-unencrypted-dataset-to-encrypted-pool/ folgende Seite mit ausführlicher Beschreibung]])
Zielsetzung: snapshots beibehalten... Möglich ist es wie folgt:
((3)) Das älteste snapshot senden
##zfs send -v pool/dataset@snapshot-01-05-2020 | zfs recv -x encryption pool2/dataset##
((3)) Neuere snapshots incrementell senden
##zfs send -v -I pool/dataset@snapshot-01-05-2020 pool/dataset/@snapshot-01-10-2020 | zfs recv -F -x encryption pool2/dataset##
((3)) Testen, ob alle snapshots gesendet wurden
##zfs list -t snapshot | grep pool2/dataset##
((2)) Probleme mit SMR-Festplatten
SMR-Festplatten sind problematisch für xNAS. Einige Hinweise, wie man dem Problem (wenn man die Dinger nicht austauschen kann) begegnen kann, sind [[https://www.truenas.com/community/threads/update-wd-red-smr-drive-compatibility-with-zfs.88413/ hier zu finden]].
In Kürze sind die Lösungsansätze wie folgt zusammenzufassen:
- disable TRIM on pools with the DM-SMR drives,
- kleinere VDEVs nutzen => am besten mirror, raidz mit weniger als 4 Laufwerken sind besser,
- große ZFS dataset record size / ZVOL block size nutzen:
- auf jeden Fall sollte auf jede HDD größer als 64K geschrieben werden, also
- RaidZ VDEV <5 => 256K oder größer,
- RaidZ VDEV >5 => 512K oder größer.
**ABER**: am besten die SMR-Dinger meiden!
((1)) SLOG etc.
An sich wird empfohlen, dass SLOG-Laufwerke dediziert und jeweils für nur eine Aufgabe zugewiesen werden. Intel Optane Laufwerke sind aber so gut, dass sie sogar partitioniert werden und so als SLOG dienen können. Denn ein SLOG benötigt nur eine recht kleine Größe...
Vgl. dazu folgende Diskussion mit Hinweisen:
=> https://www.truenas.com/community/threads/sharing-slog-devices-striped-ssds-partitioned-for-two-pools.62787/
Wie Partitionen als SLOG eingerichtet werden können kann in Kürze so beschrieben werden:
((2)) die betroffenen Laufwerke partitionieren
Am Beispiel von 2 Laufwerken die als mirror für zwei Pools eingesetzt werden:
##
gpart create -s GPT nvdX
gpart create -s GPT nvdY
gpart add -t freebsd-zfs -a 1m -l slogA -s 16G nvdX
gpart add -t freebsd-zfs -a 1m -l slogA -s 16G nvdY
gpart add -t freebsd-zfs -a 1m -l slogB -s 16G nvdX
gpart add -t freebsd-zfs -a 1m -l slogB -s 16G nvdY##
((2)) SLOGs einrichten
##
zpool add A-pool log mirror nvdXp1 nvdYp1
zpool add B-pool log mirror nvdXp2 nvdYp2##
((2)) Kontrollieren
Ob die Mirror in der Auflistung erscheinen (im Web-GUI aber auch sichtbar, unter Status).
##zpool status##
##pool##s, ##dataset##s und der Umgang mit ihnen
Eines der wesentlichen Bestandteile von FreeNAS ist das Dateisystem ZFS. Mit den unten genannten Befehlen können wichtige Funktionen dieses fortschrittlichen Systems genutzt werden.
((2)) Scrubs und Snapshots
Einige Befehle zum Anlegen und Verwalten von Snapshots:
((3)) Anzeige von Parametern
Anzeigen von Speicherplatz, der von einem Snapshot belegt ist in der Konsole:
##zfs list -t snapshot##
((3)) Eigenschaften eines ##dataset##
##zfs get all pfad/zum/dataset##
((2)) Moving datasets (and complete pools)
Siehe hier: https://www.ixsystems.com/community/threads/copy-move-dataset.28876/#post-190178
Im Einzelnen geht dies so:
1. Create final source snapshot:
##zfs snapshot -r Datasource/Storage@copy##
2. Copy the data:
##zfs send -Rv Datasource/Storage@copy | zfs receive -F Datatarget/Storage##
an ein anderes System per ssh:
##zfs send -Rv Datasource/Storage@copy | **ssh host2** zfs receive -F Datatarget/Storage##
3. Delete created snapshots:
##zfs destroy -r Datatarget/Storage@copy ; zfs destroy -r Datasource/Storage@copy##
Vgl. dazu auch ein komplettes Backup-Konzept mit ZFS-Platten hier:
https://esc-now.de/_/zfs-offsite-backup-auf-eine-externe-festplatte/?lang=en
Sowie andere Infos:
https://www.kirgus.net/cms_homepage8/zfs-datasetzvol-auf-anderen-pool-umziehen
((2)) Encryption / Verschlüsselung (nativ on ZFS)
Wenn man nachträglich verschlüsseln möchte (zum Beispiel ein dataset) ist dies nicht so einfach möglich. Wenn man Daten nicht auf dateiebene in ein verschlüsseltes Verzeichnis kopieren will, kann man mit den datasets so arbeiten:
(siehe auch [[https://nocin.eu/zfs-send-unencrypted-dataset-to-encrypted-pool/ folgende Seite mit ausführlicher Beschreibung]])
Zielsetzung: snapshots beibehalten... Möglich ist es wie folgt:
((3)) Das älteste snapshot senden
##zfs send -v pool/dataset@snapshot-01-05-2020 | zfs recv -x encryption pool2/dataset##
((3)) Neuere snapshots incrementell senden
##zfs send -v -I pool/dataset@snapshot-01-05-2020 pool/dataset/@snapshot-01-10-2020 | zfs recv -F -x encryption pool2/dataset##
((3)) Testen, ob alle snapshots gesendet wurden
##zfs list -t snapshot | grep pool2/dataset##
((2)) Probleme mit SMR-Festplatten
SMR-Festplatten sind problematisch für xNAS. Einige Hinweise, wie man dem Problem (wenn man die Dinger nicht austauschen kann) begegnen kann, sind [[https://www.truenas.com/community/threads/update-wd-red-smr-drive-compatibility-with-zfs.88413/ hier zu finden]].
In Kürze sind die Lösungsansätze wie folgt zusammenzufassen:
- disable TRIM on pools with the DM-SMR drives,
- kleinere VDEVs nutzen => am besten mirror, raidz mit weniger als 4 Laufwerken sind besser,
- große ZFS dataset record size / ZVOL block size nutzen:
- auf jeden Fall sollte auf jede HDD größer als 64K geschrieben werden, also
- RaidZ VDEV <5 => 256K oder größer,
- RaidZ VDEV >5 => 512K oder größer.
**ABER**: am besten die SMR-Dinger meiden!
((1)) SLOG etc.
An sich wird empfohlen, dass SLOG-Laufwerke dediziert und jeweils für nur eine Aufgabe zugewiesen werden. Intel Optane Laufwerke sind aber so gut, dass sie sogar partitioniert werden und so als SLOG dienen können. Denn ein SLOG benötigt nur eine recht kleine Größe...
Vgl. dazu folgende Diskussion mit Hinweisen:
=> https://www.truenas.com/community/threads/sharing-slog-devices-striped-ssds-partitioned-for-two-pools.62787/
Wie Partitionen als SLOG eingerichtet werden können kann in Kürze so beschrieben werden:
((2)) die betroffenen Laufwerke partitionieren
Am Beispiel von 2 Laufwerken die als mirror für zwei Pools eingesetzt werden:
##
gpart create -s GPT nvdX
gpart create -s GPT nvdY
gpart add -t freebsd-zfs -a 1m -l slogA -s 16G nvdX
gpart add -t freebsd-zfs -a 1m -l slogA -s 16G nvdY
gpart add -t freebsd-zfs -a 1m -l slogB -s 16G nvdX
gpart add -t freebsd-zfs -a 1m -l slogB -s 16G nvdY##
((2)) SLOGs einrichten
##
zpool add A-pool log mirror nvdXp1 nvdYp1
zpool add B-pool log mirror nvdXp2 nvdYp2##
((2)) Kontrollieren
Ob die Mirror in der Auflistung erscheinen (im Web-GUI aber auch sichtbar, unter Status).
##zpool status##
