FreeNAS Raid Z2 zu wenig verfügbarer Speicher.

[Grinchy]

Hallo zusammen,

ich benutze seit einigen Wochen ein Raid Z2 mit 6x6TB und wollte nun um eine Festplatte erweitern (neuaufbau).

Nun ist mir nur aufgefallen das ich trotz 6TB Festplatte extra, nur 3,5TB mehr Speicher zur Verfügung habe.

Habe es nun etwas getestet und

6x6TB -> Verfügbar: 32,5TB und Nutzbar: 21TB
7x6TB -> Verfügbar: 38TB und Nutzbar: 24,5TB

Der Verfügbare Speicher stimmt., nur der nutzbare ist ja viel zu wenig. Habe ich irgendwas falsch gemacht?

 

[MrToddsFriends]

Poste bitte den Output der folgenden Kommandos (jeweils in CODE Tags bitte), dann kann hoffentlich jemand dazu etwas sagen.

zfs list -o space -d 1
zpool list
zpool status -v

 

[Grinchy]

Code:

PaddyZFS			  24.4T   115G		 0	115G			  0	  1.24M
freenas-boot		  27.1G  1.45G		 0	 64K			  0	  1.45G
freenas-boot/.system  27.1G  12.6M		 0	416K			  0	  12.2M
freenas-boot/ROOT	 27.1G  1.43G		 0	 29K			  0	  1.43G
freenas-boot/grub	 27.1G  6.46M		 0   6.46M			  0		  0

Code:

NAME		   SIZE  ALLOC   FREE  EXPANDSZ   FRAG	CAP  DEDUP  HEALTH  ALTROOT
PaddyZFS		38T   181G  37.8T		 -	 0%	 0%  1.00x  ONLINE  /mnt
freenas-boot  29.5G  1.46G  28.0G		 -	  -	 4%  1.00x  ONLINE  -

Code:

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

		NAME											STATE	 READ WRITE CKSUM
		PaddyZFS										ONLINE	   0	 0	 0
		  raidz2-0									  ONLINE	   0	 0	 0
			gptid/9cc2de1d-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0
			gptid/9db7c088-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0
			gptid/9eb40cd0-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0
			gptid/9fb376c6-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0
			gptid/a067585b-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0
			gptid/a11c5ef5-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0
			gptid/a23cfc11-93d2-11e7-affa-ac1f6b2331c4  ONLINE	   0	 0	 0

errors: No known data errors

  pool: freenas-boot
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Thu Sep  7 03:45:26 2017
config:

		NAME		STATE	 READ WRITE CKSUM
		freenas-boot  ONLINE	   0	 0	 0
		  da0p2	 ONLINE	   0	 0	 0

errors: No known data errors

 

[MrToddsFriends]

O.k., so ist es gut nachvollziehbar, ich kann aber leider auch weder Grund noch Abhilfe nennen.

Einzelne Platte:
6 TB (dezimal, Terabyte) sind 5.457 TiB (binär, Tebibyte)

7 Platten im RaidZ2 (Taschenrechner <-> Bidule0hm RAID calculator)
5.457 TiB * 7 = 38.199 TiB <-> 38.2 TiB "Total RAID space"
5.457 TiB * 7 = 27.285 TiB <-> 27.29 TiB "Total data space"

Demgegenüber sagt die linke Spalte der Outputs von zfs list -o space -d 1 (also der Wert AVAIL) 24.4T, meines Wissens eine binäre Angabe (eigentlich TiB) und damit fehlen knapp 3 TiB.

Es gibt sehr viele Threads hier im Forums, die sich mit diesem oder einem ähnlichen Problem befassen und vermutlich würden sich viele Mitleser über eine knappe und aussagekräftige Aussage dazu freuen.

 

[MrToddsFriends]

Kannst Du bestätigen (oder ausschließen) dass die hier gegebene Erklärung in Deinem Fall zutreffend ist?
https://forums.freenas.org/index.php?threads/missing-5-tib.49561/#post-341102

Bzw. die von SirMaster, die im oben genannten Posting zitiert wird.
https://forums.freenas.org/index.ph...liability-calculator.28191/page-2#post-195915

 

[Grinchy]

Also ich habe mir das mal durch gelesen, aber ich denke eher nicht das das bei mir zutrift. In den meisten Threads die ich finden konnte geht e um Leute die Parity oder Metadaten nicht einberechnet haben.

Bei mir ist das ja Problem ja wirklich, das beim wechsel von 6 auf 7 Festplatten ~2TB Speicher scheinbar grundlos verpuffen. Der Speicher ist auch 100% Korrekt. Habe mal testweise 800GB Daten kopiert, und es stimmt überall vom Speicherverbrauch definitiv überein. Also Ursprungsplatte 800GB, SMB Ordner 800GB und FreeNAS Anzeige 800gb. Es ist also nicht so, dass man 800gb kopiert und nur 700gb verbraucht werden wie es im ersten Link der Fall war.

Für mich ist die Sache jetzt ein Albtraum, weil ich nun ernsthaft darüber nachdenken muss ob ich auf BTRFS ausweichen soll. Ist das letzte was ich möchte, nur mehr als 2TB Overhead (wohlgemerkt, es geht hier nur um den Overhead von einer Platte!) sind schon ziemlich viel. Vor allem da ich den Speicher eigentlich bräuchte.

Ich habe die Platten nun auch einige mal neu formatiert, aber brachte leider nichts. Die "Verfügbarer Speicher" stimmt eigentlich immer. Nur der nutzbare Speicher ist halt nicht wie es sein sollte.

6x6TB Z2 -> 21 Nutzbar
7x6TB Z2 -> 24,5 Nutzbar

6x6TB Z1 -> 25,2 Nutzbar
7x6TB Z1 -> 31 Nutzbar

7x6TB Z3 -> 21 Nutzbar

Witzig ist hier vor allem das beim erstellen eines Z2, dort angezeigt wird das voraussichtlich ~27TB verfügbar sein sollten.

Wäre wirklich klasse wenn mir hier jemand helfen könnte.

 

[MrToddsFriends]

Habe mal testweise 800GB Daten kopiert, und es stimmt überall vom Speicherverbrauch definitiv überein. Also Ursprungsplatte 800GB, SMB Ordner 800GB und FreeNAS Anzeige 800gb. Es ist also nicht so, dass man 800gb kopiert und nur 700gb verbraucht werden wie es im ersten Link der Fall war.

Sprichst Du hier ("FreeNAS Anzeige 800gb") von den Werten, die ein zfs list -o space -d 1 (oder ein anders gestrickter Aufruf von zfs list) in den Spalten AVAIL und USED anzeigt oder von etwas ganz Anderem?

Sorry dass ich nachfrage, aber die Diskussion zu diesem Thema sollte so wenig Mehrdeutigkeiten enthalten wie möglich.

 

[Grinchy]

Also ich habe jetzt noch vieles ausprobiert und es scheint nun doch das selbe Problem wie in https://forums.freenas.org/index.ph...liability-calculator.28191/page-2#post-195915 zu sein. Dachte nicht das ZFS hier so fehleranfällig ist :-(

Sobald ich mit 7x6TB Z2 ein Dataset mit 1024k erstelle und Komprimierung aktiviere und 11GB große Daten kopiere, habe werden in FreeNAS nur 10,3GB angezeigt. Wenn ich das gleiche mit 6x6TB Z2 mache sind es immer 11/11GB. Hier stimmt aber auch der verfügbare Platz.

Wenn das in dem Thread stimmt, dann liegt das daran das der Pool mit ashift=12 erstellt wird und nicht mit ashift=9. Sind nicht ashift=9 eigentlich 4k Sektoren?

Gibt es eine Möglichkeit beim erstellen ashift=9 zu erzwingen? Evtl. über die Konsole?

 

[MrToddsFriends]

Wenn das in dem Thread stimmt, dann liegt das daran das der Pool mit ashift=12 erstellt wird und nicht mit ashift=9. Sind nicht ashift=9 eigentlich 4k Sektoren?

ashift=9 sind 512 (2^9) Bytes, ashift=12 sind 4096 (2^12) Bytes

Gibt es eine Möglichkeit beim erstellen ashift=9 zu erzwingen? Evtl. über die Konsole?

Man kann, ich denke allerdings nicht, dass die Vorteile überwiegen. Wenn's wirklich lediglich ein "Misreporting" des benutzten und verfügbaren Platzes ist ...

Beispiele für ashift=9 und ashift=12 beim Aufruf von zpool create:
http://louwrentius.com/zfs-performance-and-capacity-impact-of-ashift9-on-4k-sector-drives.html

Welcher Wert für ashift aktuell vorliegt:
Bei freenas-boot: zdb | grep ashift
Bei Datenpools: zdb -U /data/zfs/zpool.cache | grep ashift

 

[Grinchy]

Werde heute Abend nochmal überprüfen welchen ashift ich bei 6x6tb und 7x6tb habe.

Das Problem ist halt, das ich ehrlich gesagt nicht vollkommen verstehe wie es zu diesem "Bug" kommt. Finde das schon recht seltsam das es nur bei 7x6tb und nicht bei 6x6tb auftritt. Ich frage mich nur, ob das ein FreeNAS Bug ist, oder ob das an ZFS selbst liegt.

Ein anderes Problem wäre das ich durch 1024k Nachteile bei kleinen Dateien entstehen. Die Komprimierung minimiert zwar den Verlust, aber bei vielen kleinen Dateien hat man effektiv 6% weniger Dateigröße als es sein sollte. Bei großen sind es ungefähr 9%.

 

[IceBoosteR]

Hast du diesen Bug aufgemacht?
https://bugs.freenas.org/issues/25811#change-142953
Dann verlink ich den hier mal im Thead, falls es dort Neuigkeiten gibt.

 

[Grinchy]

Also ich benutze nun halt gezwungenermaßen 1024k in den Datasets und verliere so zumindest nur bei kleinen Dateien etwas Speicher.

Jetzt ist mir nur ein für mich leider gewaltiges Problem aufgefallen. Die Blockgröße ist ja auch die Größe für die Checksummen abgespeichert werden. Das bedeutet statt Standard 128k habe ich nun 1024k per Checksumme. Das ist ja mal eben eine 8 fach höhere Wahrscheinlichkeit das defekte Dateien nicht erkannt werden :-(

Bietet hier 1024k überhaupt noch genug Sicherheit? Es ist ja schließlich für 128k ausgelegt. Benutzt FreeNAS ZFS CRC32 oder Sha1?

 

[MrToddsFriends]

Jetzt ist mir nur ein für mich leider gewaltiges Problem aufgefallen. Die Blockgröße ist ja auch die Größe für die Checksummen abgespeichert werden. Das bedeutet statt Standard 128k habe ich nun 1024k per Checksumme. Das ist ja mal eben eine 8 fach höhere Wahrscheinlichkeit das defekte Dateien nicht erkannt werden :-(

Bietet hier 1024k überhaupt noch genug Sicherheit? Es ist ja schließlich für 128k ausgelegt. Benutzt FreeNAS ZFS CRC32 oder Sha1?

Welchen Checksumming-Algorithmus ZFS per Default verwendet (nennt sich fletcher4) und welche Algorithmen implementiert sind (sha512 und skein kamen mit FreeNAS 11/FreeBSD 11 hinzu), erfährt man z.B. aus der zfs Manpage von FreeBSD. Abschnitt Native Properties, dort unter checksum, eine Doku zu recordsize gibt's dort auch.

Bis jetzt sind mir noch keine Dokumente über den Weg gelaufen, in denen von besonders ungünstigen Kombinationen der ZFS-Properties checksum und recordsize die Rede ist, bzw. das man sich deswegen Sorgen machen müsste. Falls es hier Fallstricke gibt, schieß' los.

Ich muss nochmal nachfragen: Gewinnst Du wirklich Platz durch das Variieren der ZFS Property recordsize oder vermeidest Du damit lediglich, dass die Größen von benutztem und freiem Platz um ein paar Prozent falsch dargestellt werden?

 

[Grinchy]

Also das mit der recordsize habe ich von hier: http://blog.programster.org/zfs-record-size

Es ist definitiv so, dass abgelegte Dateien bei 1024k etwa ~6% weniger Speicher brauchen. Lege ich bei 1024k 1GB große Datei ab, werden nur ~950MB benutzt. Mache ich das selbe mit den Standard 128k werden genau 1GB gebraucht.

Die Komprimierung spielt hier eigentlich keine Rolle, kompensiert aber etwas die 1024k für sehr kleine Dateien.

Bei 6x6TB werden sowohl mit 1024 als auch mit 128k 1GB gebraucht. Es tritt also nur auf, weil bei den 7x6TB durch irgendeinen "Bug" die ~2TB verloren gegangen sind.

Der Fehler tritt auch mit OMV ZFS und Nas4Free aus. Hatte das gestern getestet. Man kann also nur Ashift 9 verwenden, oder eben die recordsize auf 1024 stellen.

Ich habe jetzt halt keine Ahnung was hier besser wäre. Ashift 9 macht die AF Platten halt leider recht langsam. Habe es nicht getestet, aber das wird wohl 50% Leistungsverlust bringen?
Am besten wäre das verwenden von 1024k, nur habe ich hier halt zweifel das die Integrität der Daten durch die 8x weniger Checksummen gefährdet wird. Ob er Checksummen von 128k oder 1024k erstellt ist halt schon ein großer Unterschied. Bin mir unsicher ob Sha256 da noch genug Sicherheit bietet (kenne mich in dem Bereich aber auch nicht so gut aus).