ZFS: neues Dataset nach send/recv größer ??

R

rakso

Well-Known Member
Hallo, ich habe eine Frage zu ZFS.
Warum wird tank/samba-bilderdb mit 13.4T angezeigt, die kopie auf dem neuen tank10TBnas1 aber mit 16.9 ??
(Es wurden natürlich keine Bilder draufkopiert...) das zfs send/recv dauerte nun ein paar Tage.
Die letzte Zeile vom zfs send / recv Befehl ist:
20:54:14 8.57T tank/samba-bilderdb@bildersnap

Dort also wieder eine andere Zahl 8.57 TB - ich dachte, es hängt mit copies oder compression zusammen, doch diee Werte sind gleich.



Alte Datasets:
tank/samba-bilderdb 13.4T 1.29T 13.4T /tank/bilderdb
tank/samba-bilderdb-ingest 466G 1.29T 466G /tank/bilderdb-ingest

neue DS:
tank10TBnas1/samba-bilderdb 16.9T 4.16T 16.9T /data/samba/bilderdb
tank10TBnas1/samba-bilderdb-ingest 956G 4.16T 956G /data/samba/bilderdb-ingest


bilderdb ist also von 13.4 auf 16.9T angewachsen, wie kann das sein?
dedup ist 1..

copies bei beiden 2
compression bei beiden lz4

Code: 
NAME           SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank          27.2T  24.8T  2.46T         -    20%    90%  1.00x  DEGRADED  -
tank10TBnas1  45.2T  36.9T  8.37T         -    25%    81%  1.00x  ONLINE  -
zroot         9.94G  2.99G  6.95G         -    56%    30%  1.00x  ONLINE  -



config:

        NAME                 STATE     READ WRITE CKSUM
        tank                 DEGRADED     0     0     0
          raidz1-0           DEGRADED     0     0     0
            gpt/raid6r1.eli  FAULTED    166   916     0  too many errors
            gpt/raid6r2.eli  ONLINE       0     0     0
            gpt/raid6r3.eli  ONLINE       0     0     0
            gpt/raid6r5.eli  ONLINE       0     0     0
            gpt/raid6r4.eli  ONLINE       0     0     0
        logs
          mirror-1           ONLINE       0     0     0
            gpt/ssdlog0      ONLINE       0     0     0
            gpt/ssdlog1      ONLINE       0     0     0
        cache
          gpt/ssdcache0      ONLINE       0     0     0
          gpt/ssdcache1      ONLINE       0     0     0

errors: No known data errors

  pool: tank10TBnas1
state: ONLINE
  scan: none requested
config:

        NAME                  STATE     READ WRITE CKSUM
        tank10TBnas1          ONLINE       0     0     0
          raidz2-0            ONLINE       0     0     0
            gpt/zfs10TB1.eli  ONLINE       0     0     0
            gpt/zfs10TB2.eli  ONLINE       0     0     0
            gpt/zfs10TB3.eli  ONLINE       0     0     0
            gpt/zfs10TB4.eli  ONLINE       0     0     0
            gpt/zfs10TB5.eli  ONLINE       0     0     0




Beim Umzug bin ich nach diesem Schema vorgegangen

snapshot erstellen
zfs snapshot tank/samba-bilderdb-ingest@snap1

RX/TX:
zfs send -v tank/samba-bilderdb-ingest@snap1 | zfs recv tank10TBnas1/samba-bilderdb-ingestNEU

snapshot clonen:
zfs clone tank10TBnas1/samba-bilderdb-ingestNEU@snap1 tank10TBnas1/samba-bilderdb-ingestCLONED

clone promoten
zfs promote tank10TBnas1/samba-bilderdb-ingestCLONED

rename
zfs rename tank10TBnas1/samba-bilderdb-ingestCLONED tank10TBnas1/samba-bilderdb-ingestNEUfinal

snap löschen
zfs destroy -R tank10TBnas1/samba-bilderdb-ingestNEUfinal@snap1

Mountpoints
umount / data/samba/..
zfs set mountpoint=/data/samba/bilderdb-ingest tank10TBnas1/samba-bilderdb-ingest



Wie passen diese Zahlen zusammen?


Viele Grüße
rakso

Ein Teil der Platten ist onboard (asrock C2750D4I) und andere am controller:
Controller type : SAS2308_2
BIOS version : 7.37.00.00
Firmware version : 20.00.07.00

OS: nas4free, 11.1-RELEASE-p8
 
Zuletzt bearbeitet:
War frueher die Kompression vielleicht mal auf "GZIP" eingestellt (hoehere Kompressionsrate) und wurde dann irgendwann auf lz4 geaendert (was nur neue Daten betreffen wuerde)?

"zpool history" hat vielleicht die Antwort...
 
Hallo! Es handelt sich ausschließlich um bereits kompromierte Daten (JPG Dateien), so dass dies nicht diesen riesen Unterschied von 3,5TB erklärt...
 
Oder viele kleine Dateien bei unterschiedlicher Blocksize? Wobei da mehrere Terabyte schon extrem wären...
 
auch eher ausgeschlossen, die Bilddateien sind meistens zwischen 5 und 50 MB - JPG und RAW ... merkwürdig.
 
Windows-Explorer:

tank10TBnas1: Belegt: 16,9TB , frei: 3,79TB
tank: 13,3TB, frei: 1,28TB


Wie kann ich da (schnell) den Unterschied prüfen? Also eine art diff..Dateinamen / Größe würde reichen.
 
Freefilesync findet auf den smbshares kein unterschied. auch alle anderen datasets sind auf dem neuen pool etwa 24-35% größer.
Wo kommt das her??
 
zfs get all ... sieht ähnlich aus.. compression, scompressradi, compressio, recordsize,refcompressratio...

tank10TBnas1/samba-bilderdb written 16.9T -
tank10TBnas1/samba-bilderdb logicalused 8.55T -
tank10TBnas1/samba-bilderdb logicalreferenced 8.55T
tank10TBnas1/samba-bilderdb referenced 16.9T


tank/samba-bilderdb written 13.4T -
tank/samba-bilderdb logicalused 8.55T -
tank/samba-bilderdb logicalreferenced 8.55T -
tank/samba-bilderdb referenced 13.4T

"written" ist größer beim neuen, die beiden anderen aber gleich. hm.
 
-> Hängen da noch die snapshots irgendwie drin?
Wie kann ich mich denen entledigen?!

referenced
The amount of data that is accessible by this dataset,which may or
may not be shared withother datasets in the pool. When a snapshot or
clone is created, it initiallyreferences the same amount of space as
the file system or snapshot itwas created from, sinceits contents
are identical.

This property can alsobe referred to by its shortenedcolumn name,
refer.

written
The amount of referenced spacewrittento thisdatasetsince the pre-
vious snapshot.

logicalreferenced
The amount of space that is "logically" accessible by this dataset.
See the referenced property. The logical space ignores the effect of
the compression and copies properties,giving a quantity closer to
the amount of data that applications see. However, itdoes include
space consumedby metadata.

This property can alsobe referred to by its shortenedcolumn name,
lrefer.

logicalused
The amount of space that is "logically" consumed by this dataset and
all its descendents. See the used property. The logical space
ignores the effect of the compression and copies properties, giving a
quantity closer to theamount of data that applications see.

This property can alsobe referred to by its shortenedcolumn name,
lused.
 
hehe ja da hätte ich auch drauf kommen können. ich war nur etwas überrascht dass ich mit den nun 10TB HDDs nur so viel wenig mehr an Speicher habe als vorher mit 5x 6TB. Ich habe mal den calc bemüht, es wäre wohl besser gewesen wenn ich noch eine HDD dazu nehmen würde, dann sind es deutlich mehr nutzbarer Speicher. Nun will ich erstmal alles auf den neuen pool umziehen und dann sehen woher die starken Probleme mit den read timeouts usw bei dem anderen Plattensatz kommen. Dann später das nochmals auslagern und den 10TB pool mit einer weiteren HDD neu aufsetzen....

Grüße
 
Angeblich kommt auch mit FreeBSD 12 eine Online-Erweiterung von ZFS RAID-Z. D.h. "einfach eine Platte mehr einbauen für mehr Speicher". Vielleicht so für die Auslagerungspläne, auch wenn ein Backup eh anzuraten wäre :D
 
Das ist das fast schon legendäre "Blockpointer Rewrite"-Projekt. Die erste Hälfte, entfernen von Devices, ist sogar schon in 11.2 gelandet.
 
Die offizielle Ankündigung ist hier: https://www.freebsdfoundation.org/blog/openzfs-raid-z-online-expansion-project-announcement/

Ich hatte damals auch in dem Zusammenhang gelesen, dass ein ZFS Mitarbeiter mal meinte, dass Blockpointer Rewrite das letzte Feature sein wird, was ZFS je bekommen wird. Alles ab dort wird zu kompliziert einzubauen. Na mal schauen ob sich das bewahrheitet.

Weitere Dinge wie Defragmentierung wären in dem Zusammenhang auch schön.
 
Es deutet sich zumindest an, dass das inzwischen ja auch schon wieder fast 15 Jahre alte grundsätzliche Design von ZFS an seine Grenzen zu stoßen beginnt. Irgendwann wird man daher sicherlich über ein inkompatibles ZFS2 nachdenken müssen, was die internen Datenstrukturen sozusagen "modernisiert". Aber so weit sind wir noch nicht. Schön zu haben und realistisch wären noch:
  • Verschlüsselung. Oracle hat Verschlüsselung, ZFS on Linux hat andere Verschlüsselung und für FreeBSD gibt es inzwischen einen Call for Testers: https://lists.freebsd.org/pipermail/freebsd-fs/2018-August/026565.html Es ist aber nach wie vor unsicher, ob sie in FreeBSD gemerged wird. Denn wie in dem Thread auch diskutiert wird, war ZFS nie darauf ausgelegt, dass einzelne Datasets verschlüsselt werden, woraus sich mögliche Angriffsvektoren ergeben.
  • Bessere Deduplication. Die derzeitige Implementierung von Dedup ist eine Katastrophe. Sie ist langsam und benötigt so viel teuren RAM, dass es sich nur selten lohnt sie einzuschalten. Verbesserungen da wurden schon öfter diskutiert, bisher wurden aber andere Features als wichtiger eingestuft.
  • Besseres RAIDZ. Sowohl hinsichtlich Performance zur Laufzeit, als auch beim Rebuild ist RAIDZ suboptimal. Es gibt mit dRAID einen Vorschlag dafür, aber das Design (externe Konfigurationdateien) ist etwas seltsam. Es kommt aus dem weiterem ZFS on Linux Umfeld, ist aber auch da noch nicht gemerged.
  • Defragmentierung. Das sagte @-Nuke- ja schon. Blockpointer Rewrite ist da schon mal ein großer Schritt hin. Mal schauen, ob sich da jemand die Arbeit machen wird.
  • ARC-Performance: Die Performance des ARC, gerade im Zusammenspiel mit Kompression, war lange Zeit wirklich mies. Das ist schon deutlich besser geworden, durch Compressed ARC und durch Scattered Allocations, aber es gibt immer noch Workloads, wo der ARC zum Flaschenhals wird. Da wird nach wie vor dran gearbeitet, allerdings erreicht man inzwischen die grundsätzlichen Grenzen des ARC-Designs.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben