[Sammelthread] ZFS Stammtisch

[gea]

@Gea: Das paradoxe ist ja: Ich HABE mich ja an die Hardware"standards" für OpenSolaris gehalten und Hardware verbaut, die mir 2 Sun.. eh.. Oracle Mitarbeiter empfohlen haben.

Weiß nicht ob Du meinen Fehlerpaste-Log gesehen hast ([Bash] Nexenta log - Pastebin.com).

Nun eben - nach unglaublichen 6h und 20min hat es Debian Squeeze übrigens endlich geschafft die 5x 1.5TB als RAID5 zu bauen und zu formatieren (ext4). Ein schlechter Scherz wenn ich an ZFS denke, wo das in wenigen Sekunden über die Bühne gegangen ist.

Nochmal @gea: Kannst Du mir ein System wirklich EMPFEHLEN, welches Stabil, NICHT NEXENTA ist und auf dem ich VirtualBox laufen lassen kann?

mit der Stabilität von Virtualbox habe ich gar keine Erfahrung.
Von der Hardware würde ich spontan immer Supermicro X8-...-F nehmen
(mit 3420 oder 5520 Chipsatz + Xeon) und einen Controller mit LSI 1068
oder eventuell LSI 2008 Chipsatz und IT Firmware sagen.

wobei ich bei den vorhandenen Problemen auch auf einen Problem am Mainboard oder
den Platten tippen würde (eine defekte Platte kann auch ein komplettes freeze zur Folge haben)

Gea

 

[ulukay]

Wohl einzigartig ist volle Paritätprüfung über die realen Daten, nicht nur auf Raidcontroller- oder
Plattenebene wie sonst. ZFS weiss also immer, ob die Daten ok sind.

Damit verbunden ist die Möglichkeit, Online-Filetests durchzuführen um stille Dateifehler
zu entdecken und zu reparieren.

oh du hast wohl oben nicht aufmerksam gelesen, hat btrfs genauso

 

[zos]

Installation auf USB wird von Nexenta nicht unterstützt.
Als auf der normalen Bootplatte installieren.

Gea

Ich lese insb. auch Deine Beiträge schon seit längerer Zeit mit und konnte dadurch (wie so viele andere wohl auch) von Deinen ausführlichen Postings viel lernen (auch von mir vielen Dank dafür), aber hier muß ich widersprechen:

Die Installation auf einem USB-Stick klappt, jedoch habe auch ich zunächst die o.a. Fehlermeldung erhalten.

Wenn der USB-Stick jedoch als externes Laufwerk mit einer Partition (d. h. mit angelegter Partitionstabelle, ich habe das mit einer Parted Magic Live-CD gemacht) bereit gestellt wird, funktioniert es.

Grüße,
zOS

 

[xmasman]

Ich lese insb. auch Deine Beiträge schon seit längerer Zeit mit und konnte dadurch (wie so viele andere wohl auch) von Deinen ausführlichen Postings viel lernen (auch von mir vielen Dank dafür), aber hier muß ich widersprechen:

Die Installation auf einem USB-Stick klappt, jedoch habe auch ich zunächst die o.a. Fehlermeldung erhalten.

Wenn der USB-Stick jedoch als externes Laufwerk mit einer Partition (d. h. mit angelegter Partitionstabelle, ich habe das mit einer Parted Magic Live-CD gemacht) bereit gestellt wird, funktioniert es.

Grüße,
zOS

Hallo zOS,

das hört sich interessant an.

Was für eine Partition hattest Du denn auf dem Stick angelegt?
Meiner war halt standardmäßig FAT.

Grüße
xmasman

 

[zos]

Hallo zOS,

das hört sich interessant an.

Was für eine Partition hattest Du denn auf dem Stick angelegt?
Meiner war halt standardmäßig FAT.

Grüße
xmasman

Das einzige, was ich gemacht habe, war einen Partitiontable anzulegen (Bei GParted im Pulldownmenu "Devices" war's glaube ich), ohne dabei irgendeine Partition neu anzulegen.

Da ich ja zunächst denselben Fehler erhielt, den Du weiter oben bereits gepostet hast, bin ich anschließend im ZFS Troubleshooting Guide (ZFS Troubleshooting Guide - Siwiki) auf folgende Stelle gestoßen:

"Disks intended for the root pool must contain a slice and have an SMI label."

Das brachte mich auf den Gedanken den USB-Stick entsprechend "vorzubereiten". Hier steht nur, dass eine Partition (slice) vorhanden sein muß; welcher Art diese ist, spielt offenbar keine Rolle, da die Installation von NCP 3.0.1 im Anschluß geklappt hat.

Grüße,
zOS

 

[hotzen]

oh du hast wohl oben nicht aufmerksam gelesen, hat btrfs genauso

1.) wird btrfs aufgrund der neidischmachenden existenz von zfs mit den selben zielen entwickelt
2.) ist btrfs (noch) nicht einsetzbar:

Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready.

Das ganze ist ein Versuch ein ebensomächtiges Dateisystem/Volumesystem wie ZFS mit einem Linux-Kernel zu bauen. Ist halt kein Streichelzoo, dauert noch

 

[ulukay]

ich kann zfs mangels stabilitaet nicht einsetzen.
so what? btrfs semmelt wenigstens nicht beim mounten ab

und was fuer alten muell postest du da?

BTRFSCK(8)                                                          BTRFSCK(8)

NAME
       btrfsck - check a btrfs filesystem

SYNOPSIS
       btrfsck  device

DESCRIPTION
       btrfsck is used to check a btrfs filesystem.  device is the device file
       where the filesystem is stored.

AVAILABILITY
       btrfsck is part of btrfs-progs. Btrfs is currently under heavy develop‐
       ment, and not suitable for any uses other than benchmarking and review.
       Please refer to the btrfs wiki http://btrfs.wiki.kernel.org for further
       details.

SEE ALSO
       mkfs.btrfs(8) btrfsctl(8)

                                                                    BTRFSCK(8)

 

[hotzen]

Solangs noch im Kernel-Wiki steht, ist es für mich ein Faktum.
https://btrfs.wiki.kernel.org/index.php/Main_Page

Deine Quelle:

... and not suitable for any uses other than benchmarking and review.

So what?

 

[ulukay]

ich finds ja toll einen zfs verfechter hier zu haben. vielleicht kannst du mir ja bei dem goldenen kalb helfen.
solaris 11 express auf x86 64bit. 2 platten im raid1 (fehlerfreie neue), memtest rennt 24h durch, prime95 rennt 24h durch. andere filesysteme rennen tagelang unter volllast durch. ergo hw problem ausgeschlossen.
hier mein ZFS problem

habe einen zpool erstellt mit einem volume namens backup.
das ganze mit encryption=on
hab 100e gb draufgeknallt. snapshots erstellt.
tja und nach ein paar stunden freezt das ganze zfs dann.
im sinne von, ich tippe das ein
ls /zpool/backup
und das kommando haengt stundenlang. keine fehlermeldungen in den logs, in dmesg oder beim kommando selber. solaris 11 kann nichtmal mehr runtergefahren werden.
nach nem hardware reset kann man den zpool zwar starten und mounten, aber jeder zugriff drauf freezt das gesamte system.

denkt man sich man faehrt mit nem fsck drueber. ABER HACH, das tolle ZFS HAT KEIN FSCK ...
(zpool scrub rennt ohne probleme durch )

kannst du mir was dazu raten? nein? dachte ich
was fuern tolles STABLE filesystem das doch ist

 

[hotzen]

Naja, was soll man so pauschal dazu sagen. Dass ZFS kein fschk hat, liegt auf der Hand und muss nicht diskutiert werden oder?

Ohne jede Fehlermeldungen, wie du es beschreibst, würde ich darauf tippen, dass Solaris 11 Express dann doch leider noch Probleme mit ZFS-Encryption hat. Muss auch gestehen, dass ich noch keine Erfahrung mit 100GB über ZFS-Encryption habe, das Feature ist halt noch ewig neu.

Ich würde dediziert bei Oracle nach bugs/tickets suchen, die diesen Fehler beschreiben. Dafür ist Solaris 11 Express ja schließlich da: kostenlos testen, bug-tickets filen, dann das normale non-Express für teuer Support kaufen
Also ernsthaft, mach ein Ticket auf, dafür ist die SE11 Lizenz da...

 

[otto123]

Plan fürs WE

Ok, also am WE ist geplant 4x2 TB WD Green EARS plus eine kleine 2.5 Zoll HDD in den Microserver und da dann nexenta direkt drauf (RaidZ1 mit 4, messen und dann RaidZ1 mit einer hot spare und dann mal eine rausziehen). 2 Ports zu einem Trunk bündeln und dann mal schauen wie das mit 8 GB RAM tut.

Wenn das gut läuft wäre das eine Low Budget, Noise, Energy, Cost... Variante zum Einstieg. In der Hoffnung, dass irgendwann die Verschlüsselung auch bei nexenta kommt.

Die Variante von GEA (all in one) ist für den Xeon geplant. Aber dazu muss ich erstmal alles kapieren...

Gruss,
Otto

 

[hotzen]

Da bin ich ja mal gespannt.
Kannst du mal vor der Nexenta-Installation Solaris 11 Express von Live-CD starten, den ZFS-Pool normal initialisieren und encryption auf nem filesystem aktivieren. So grobe Anhaltspunkte mit dd würden mich schon interessieren... Was da wohl so geht mit der süßen Microserver-CPU?
*thubms up* cool isser ja, der Microserver

---------- Beitrag hinzugefügt um 23:29 ---------- Vorheriger Beitrag war um 23:28 ----------

Für ZFS würde ich auch mal beim hardforum.com vorbeischauen: Data Storage Systems - [H]ard|Forum

Da ist auch GEA mit seinem napp-it sehr aktiv und generell viel ZFS-Wissen versammelt...

 

[otto123]

Da bin ich ja mal gespannt.
Kannst du mal vor der Nexenta-Installation Solaris 11 Express von Live-CD starten, den ZFS-Pool normal initialisieren und encryption auf nem filesystem aktivieren. So grobe Anhaltspunkte mit dd würden mich schon interessieren... Was da wohl so geht mit der süßen Microserver-CPU?
*thubms up* cool isser ja, der Microserver

---------- Beitrag hinzugefügt um 23:29 ---------- Vorheriger Beitrag war um 23:28 ----------

Für ZFS würde ich auch mal beim hardforum.com vorbeischauen: Data Storage Systems - [H]ard|Forum

Da ist auch GEA mit seinem napp-it sehr aktiv und generell viel ZFS-Wissen versammelt...

Hi,

sehe ich das richtig. Bei Oracle muss man sich registrieren? Hmm, ich hasse diesen Sch... Ok, will nicht zu viel versprechen aber das sollte schon gehen.
Aber "und encryption auf nem filesystem aktivieren." das musst Du mir leider erklären. Wo wird das Ding angemacht?

Danke für den Link. Kannte ich noch nicht.
Gruss
Otto

Dessen Leben nun wieder beginnt da um 23:00 der Antrag abgeliefert wurde ;-)

 

[otto123]

Vortrag: Einführung in ZFS on Vimeo

Das fand ich recht erhellend in Bezug auf ZFS.

2 TB EARS kam heute. Dann habe ich nun derer 4. Winkel um Festplatte oben zu montieren leider nicht :-(

Gruss,
Otto

 

[hotzen]

Aber "und encryption auf nem filesystem aktivieren." das musst Du mir leider erklären. Wo wird das Ding angemacht?

Encrypting ZFS File Systems - Oracle Solaris ZFS Administration Guide

hf

 

[ccmonster]

so, dann will ich mich nach laaaanger "Schreibabstinenz" auch mal melden...

@otto123:
Bitte die WD20EARS nicht im raidz betreiben, da du hier definitiv in ein Alignement-Problem läufst! 128k/3 = 42,66k - hier muss also ständig neu aligned werden! 4k-Platten sind unter zfs noch immer problematisch - hier gibt es zwar die Möglichkeit, 'zpool' mit einem manuellen Patch neu zu kompilieren, um den den zpool mit einem angepassten Offset zu erstellen. Allerdings ist hier bisher noch aufgrund mangelnder Langzeiterfahrung nicht bekannt, ob es negative "Begleiterscheinungen" gibt. Weiterhin kann es definitiv passieren, dass du einen derart erstellten Pool nicht ohne gepatchtes 'zpool' importieren kannst, was es für den evtl. Fehlerfall problematisch macht, so dass du im schlimmsten Fall den kompletten Pool verlierst!
Als Empfehlung hat sich hier das Mirror-Set herausgestellt. Dadurch verlierst du zwar effektiv die Hälfte der Kapazität, allerdings erhältst du im Gegenzug die höchsten IOPS-Werte sowie die - relativ betrachtet - höchste Redundanz.
Wenn du unbedingt auf die entsprechende Kapazität nicht verzichten möchtest, dann kann ich dir für raidz zu 3 bzw. 5 bzw. 9 Festplatten raten, da hier dann zumindest das Schreibalignement passt. Oder du nimmst 6 Festplatten und erstellst die einen raidz2-Pool.
Einem Arbeitskollegen habe ich zu den 4k-Platten HD204UI geraten - er betreibt 4 Platten als Mirror-Set und erreicht Schreibwerte bis zu 400MB/s und Lesewerte um die 340MB/s lokal (also nicht über Gbit - geht ja net..)
Möchtest du encrypten, dann rate ich dir definitiv zu Solaris 11 Express - da nur dieses bisher verschlüsseln kann. Ein Import des Pools mit verschlüsseltem zfs-Volume in Nexenta ist nicht möglich, da Nexenta eine veraltetet zfs-Version (inkl. zpool) verwendet und somit nichts damit anfangen kann.

@ulukay:
Hast du wenigsten mal die integrierten Funktionen von Solaris verwendet, um dein "ls" zu debuggen? Ich rede hier mal von vmstat, iostat, fsstat oder dtrace. Zusätzlich kannst du ein "zpool iostat poolname 1" laufen lassen, während du in einer anderen Sitzung dein "ls" loslässt. So hast du eine Live-View, welche die Fehlerursache zeigen kann!!!
Ein derartiges Verhalten bzw. Vorgehen sollte dir eigentlich nahe liegen, wenn du tatsächlich so in der Linux-Welt verankert bist, wie du hier vorgibst.
Empfehlen kann ich dir den Blog des Oracle-Mitarbeiters Constantin Gonzalez. Zu finden ist dieser unter Oracle Solaris, OpenSolaris, ZFS, Home Servers, Technology | Constant Thinking Hier findest du auch einen Beitrag bzw. "Performance Analysis", welchen du auch für Fehlersuche heranziehen kannst.
Aus eigener Erfahrung weiß ich, dass "Primestable" etc. rein GARNICHTS!!! bedeutet. Mein Storage mit C2D E6300 @ 400 war 72h-Primestable, allerdings hat es mir sogar mit 300MHz FSB die Pools zerstört, da der Chipsatz das nicht wollte! FSB runter auf 266 und alles ist tatsächlich rocksolid!!! Kein einzigster Datenfehler mehr - weder auf den SCSI- noch auf den SATA-Platten. Soviel mal dazu!

@allgemein:
Sollten Fragen sein - einfach fragen. Ich will diese gerne beantworten, soweit mein Wissen reicht. Zur not per PM oder mail.
Ach ja, und um irgendwelche "Was bist du eigentlich für einer?"-Fragen gleich abzuwürgen - ich war 'Teamleiter Linux' bei einem Hostingprovider sowie Technischer Leiter bis ich entschieden hab, dass ich mich weiterentwickeln will. Derzeit arbeite ich in einem Datacenter mit zig Petabyte SAN...

so far...

ccmonster

 

[ulukay]

@ulukay:
Hast du wenigsten mal die integrierten Funktionen von Solaris verwendet, um dein "ls" zu debuggen? Ich rede hier mal von vmstat, iostat, fsstat oder dtrace. Zusätzlich kannst du ein "zpool iostat poolname 1" laufen lassen, während du in einer anderen Sitzung dein "ls" loslässt. So hast du eine Live-View, welche die Fehlerursache zeigen kann!!!
Ein derartiges Verhalten bzw. Vorgehen sollte dir eigentlich nahe liegen, wenn du tatsächlich so in der Linux-Welt verankert bist, wie du hier vorgibst.
Empfehlen kann ich dir den Blog des Oracle-Mitarbeiters Constantin Gonzalez. Zu finden ist dieser unter Oracle Solaris, OpenSolaris, ZFS, Home Servers, Technology | Constant Thinking Hier findest du auch einen Beitrag bzw. "Performance Analysis", welchen du auch für Fehlersuche heranziehen kannst.
Aus eigener Erfahrung weiß ich, dass "Primestable" etc. rein GARNICHTS!!! bedeutet. Mein Storage mit C2D E6300 @ 400 war 72h-Primestable, allerdings hat es mir sogar mit 300MHz FSB die Pools zerstört, da der Chipsatz das nicht wollte! FSB runter auf 266 und alles ist tatsächlich rocksolid!!! Kein einzigster Datenfehler mehr - weder auf den SCSI- noch auf den SATA-Platten. Soviel mal dazu!

1. tritts bei standard takt auch auf
2. ist dabei KEIN io auf den platten. da passiert einfach garnichts
3. petabytes und san? hallo herr kollege

wie gesagt, ich kenne zfs von sparc kisten schon relativ lange, aber die x86 implementation in sol11express ist ein absoluter horror. mag sogar sein dass nur das encryption feature verbuggt ist, aber sowas darf man doch nicht auf die allgemeinheit loslassen.

 

[ccmonster]

1. tritts bei standard takt auch auf
2. ist dabei KEIN io auf den platten. da passiert einfach garnichts
3. petabytes und san? hallo herr kollege

wie gesagt, ich kenne zfs von sparc kisten schon relativ lange, aber die x86 implementation in sol11express ist ein absoluter horror. mag sogar sein dass nur das encryption feature verbuggt ist, aber sowas darf man doch nicht auf die allgemeinheit loslassen.

lass doch mal 'vmstat 1' sowie 'zpool iostat poolname 1' laufen, um das verhalten zu sehen. kannst ja posten.
encryption läuft bei mir völlig fehlerfrei, performant und stable! hab da paar GB (paar Hundert) drin. Hatte nie n Problem damit...

mfg ccmonster

 

[otto123]

@ ccmonster: Herzlichen Dank für die Infos! Ich hatte nun nexenta auf drei Platten und nichts gemerkt. Allerdings - wie soll man es auch so leicht merken? Mit den EARS habe ich mich dann wohl sauber ver... Anyway, ich habe nun 4 Stück. Dann mache ich mal heute das Solarisexpress druff auf Microserver als Mirror. Dann die zwei Ports zu einem Trunk machen und dann kann man wenigstens schneller parallel zugreifen.

Schicke Sache am Rande: Der Microserver hat einen E-SATA Ausgang direkt auf's Board gelötet - da sollte man eigentlich schön einen E-Sata USb Stick anhängen können und da das OS drauftun. Leider hat es bisher recht wenige 8 GB E-Sata Sticks.

"'Teamleiter Linux' bei einem Hostingprovider" Das hätte ich natürlich nicht gesagt - reizt geradezu zur Nachfrage ;-)

Gruss

 

[baldi]

@otto123:
Bitte die WD20EARS nicht im raidz betreiben, da du hier definitiv in ein Alignement-Problem läufst! 128k/3 = 42,66k - hier muss also ständig neu aligned werden!

Sollte es nicht so lauten 128k / (Anzahl der Disken - Paritätsdisk)
D.h. bei 3 Platten @ Raidz1 -> 128k/(3-1) = 64 -> OKAY

Oder bezieht sich das allgemein auf Raidz und nicht speziell auf 4k-Platten?

@ ccmonster: Herzlichen Dank für die Infos! Ich hatte nun nexenta auf drei Platten und nichts gemerkt. Allerdings - wie soll man es auch so leicht merken? Mit den EARS habe ich mich dann wohl sauber ver... Anyway, ich habe nun 4 Stück. Dann mache ich mal heute das Solarisexpress druff auf Microserver als Mirror. Dann die zwei Ports zu einem Trunk machen und dann kann man wenigstens schneller parallel zugreifen.

Es kommt drauf an für was du den Server brauchst ... Homeserver?
Dann ist die Performance mMn relativ egal ... Gbit-Leitung kannst du fast immer auslasten.

 

[Sumatrabarbe]

So mein Homeserver ist jetzt auch komplett... verwende 3 x wd ears.. allerdings läuft das ganze unter vmware workstation. Die Platten sind via rdm durchgereicht, Peformance war mir hier erstmal egal, ich wollte nur ne alternative zu nem softraid von Windows. Ich werd die Tage mal schauen wie stabil diese Bastellösung ist und auch mal nen kleinen Performancetest machen.

Was mir gestern bei der Installation von Napp-it aufgefallen ist... nachdem ich das auf Sol 11 Express installiert habe und dann auf's Webinterface wollte (via Firefox) kam immer username or password wrong. Irgendwann habe ichs dann mal mitm IE probiert und ich konnte mich anmelden. Sehr merkwürdig das ganze... nachdem ich dann ein Password vergeben habe ging's auch übern Firefox...


lg

 

[ulukay]

lass doch mal 'vmstat 1' sowie 'zpool iostat poolname 1' laufen, um das verhalten zu sehen. kannst ja posten.
encryption läuft bei mir völlig fehlerfrei, performant und stable! hab da paar GB (paar Hundert) drin. Hatte nie n Problem damit...

mfg ccmonster

das sieht alles recht unspektakulaer aus
vmstat, zpool iostat, fsstat und ein truss des ls -la (beim ls hab ich ne stunde gewartet bevor ich den output kopiert habe )

Spoiler

# vmstat 1
 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr cd s0 -- --   in   sy   cs us sy id
 2 0 0 536712 181736 127 979 0  0  0  0 250 24 -0 0  0  435 4415 1491  7 16 78
 0 0 0 457188 69028  12  54  0  0  0  0  0  0  0  0  0  376  472  314  1  1 98
 0 0 0 457108 68976   0   0  0  0  0  0  0  0  0  0  0  372  436  304  0  1 99
 0 0 0 457108 68984  63 310  0  0  0  0  0  0  0  0  0  378  659  322  1  2 97
 0 0 0 456472 68396   0   1  0  0  0  0  0  0  0  0  0  347  442  172  1 53 46
 0 0 0 456472 68920  22 233  0  0  0  0  0  0  0  0  0  375  653  306  1  2 97
 0 0 0 455996 68536   0   0  0  0  0  0  0  0  0  0  0  385  435  314  0  1 99
 0 0 0 455996 68588   0   0  0  0  0  0  0  0  0  0  0  377  450  305  1  2 97
 1 0 0 455996 68596   0   0  0  0  0  0  0  0  0  0  0  395  556  347  0  1 99
 0 0 0 455996 68604   0   0  0  0  0  0  0  0  0  0  0  411  614  380  0  1 99
 0 0 0 455996 68620   0   0  0  0  0  0  0  0  0  0  0  383  518  325  1  2 97
 0 0 0 455992 68620   0   0  0  0  0  0  0  0  0  0  0  397  524  345  0  3 97
 1 0 0 455992 68628   0   0  0  0  0  0  0  0  0  0  0  384  500  330  1  2 97
 0 0 0 455992 68636 102 610  0  0  0  0  0  0  0  0  0  543 1911  692  2  5 93
 17 0 0 454488 66932  0   0  0  0  0  0  0  0  0  0  0  351  329  209  0 38 62
 0 0 0      0     0   0   0  0  0  0  0  0  0  0  0  0  379  686  302  0  2 98
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  382  433  304  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  380  432  306  1  0 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  383  436  312  0  1 99
 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr cd s0 -- --   in   sy   cs us sy id
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  383  441  306  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  380  478  313  1  1 98
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  380  432  306  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  383  437  304  0  1 99
 1 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  377  433  301  1  1 98
 1 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  383  436  311  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  363  438  185  0 54 46
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  372  426  294  1  1 98
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  383  436  310  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  380  438  309  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  376  432  303  1  2 97
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  390  469  344  0  1 99
 0 0 0 454488 66948   0   0  0  0  0  0  0  0  0  0  0  384  436  330  0  1 99

~# zpool iostat rpool 1
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool       5.21G  4.48G     13     10   525K   152K
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      3      0   257K      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0
rpool       5.21G  4.48G      0      0      0      0

~# fsstat /rpool 1
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
    0     0     0     7     0      7     2     2   812     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      5     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool
    0     0     0     0     0      0     0     0     0     0     0 /rpool

~# truss ls -la /rpool/backup
execve("/usr/gnu/bin/ls", 0x08047E48, 0x08047E58)  argc = 3
sysinfo(SI_MACHINE, "i86pc", 257)               = 6
mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFB0000
sysconfig(_CONFIG_PAGESIZE)                     = 4096
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFA0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF90000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF80000
memcntl(0xFEFB7000, 32064, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0x08050000, 21532, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
resolvepath("/usr/gnu/bin/ls", "/usr/gnu/bin/ls", 1023) = 15
stat64("/usr/gnu/bin/ls", 0x08047A8C)           = 0
open("/var/ld/ld.config", O_RDONLY)             Err#2 ENOENT
stat64("/lib/libsec.so.1", 0x0804723C)          = 0
resolvepath("/lib/libsec.so.1", "/lib/libsec.so.1", 1023) = 16
open("/lib/libsec.so.1", O_RDONLY)              = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEF80A30, 0x080472A8, 0x00000000) = 0
close(3)                                        = 0
memcntl(0xFEF60000, 15192, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF50000
stat64("/lib/libc.so.1", 0x0804723C)            = 0
resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14
open("/lib/libc.so.1", O_RDONLY)                = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEF50080, 0x080472A8, 0x00000000) = 0
close(3)                                        = 0
memcntl(0xFEE00000, 187200, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDF0000
getcontext(0x080478EC)
getrlimit(RLIMIT_STACK, 0x080478E4)             = 0
getpid()                                        = 1750 [1749]
lwp_private(0, 1, 0xFEDF2A40)                   = 0x000001C3
setustack(0xFEDF2AA0)
sysi86(SI86FPSTART, 0xFEF48CD4, 0x0000133F, 0x00001F80) = 0x00000001
sysconfig(_CONFIG_PAGESIZE)                     = 4096
brk(0x08083590)                                 = 0
brk(0x08085590)                                 = 0
stat64("/usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3", 0x08046D00) = 0
resolvepath("/usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3", "/usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3", 1023) = 44
open("/usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3", O_RDONLY) = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEF50E28, 0x08046D6C, 0x00000000) = 0
close(3)                                        = 0
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEDE0000
memcntl(0xFE640000, 6780, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
stat64("/usr/lib/locale/en_US.UTF-8/libc.so.1", 0x08046BE0) Err#2 ENOENT
stat64("/usr/lib/locale/en_US.UTF-8/methods_unicode.so.3", 0x08046BE0) = 0
resolvepath("/usr/lib/locale/en_US.UTF-8/methods_unicode.so.3", "/usr/lib/locale/common/methods_unicode.so.3", 1023) = 43
open("/usr/lib/locale/en_US.UTF-8/methods_unicode.so.3", O_RDONLY) = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEDE0720, 0x08046C4C, 0x00000000) = 0
close(3)                                        = 0
memcntl(0xFE620000, 3576, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
ioctl(1, TCGETA, 0x08047D20)                    = 0
ioctl(1, TIOCGWINSZ, 0x08047D88)                = 0
open("/usr/gnu/share/locale/en_US.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) Err#2 ENOENT
brk(0x08085590)                                 = 0
brk(0x08089590)                                 = 0
lstat64("/rpool/backup", 0x08084888)            = 0
pathconf("/rpool/backup", _PC_ACL_ENABLED)      = 2
acl("/rpool/backup", ACE_GETACLCNT, 0, 0x00000000) = 3
acl("/rpool/backup", ACE_GETACL, 3, 0x08088D48) = 3
getuid()                                        = 0 [0]
getpid()                                        = 1750 [1749]
open("/proc/1750/psinfo", O_RDONLY)             = 3
fstat64(3, 0x08047560)                          = 0
read(3, "\0\0\00201\0\0\0D606\0\0".., 336)      = 336
close(3)                                        = 0
mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDC0000
getuid()                                        = 0 [0]
getuid()                                        = 0 [0]
open64("/var/run/name_service_door", O_RDONLY)  = 3
fstat64(3, 0x080475A0)                          = 0
fcntl(3, F_SETFD, 0x00000001)                   = 0
door_info(3, 0xFEF40E8C)                        = 0
door_call(3, 0x080477F0)                        = 0
brk(0x08089590)                                 = 0
brk(0x0808D590)                                 = 0
mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDA0000
getuid()                                        = 0 [0]
getuid()                                        = 0 [0]
door_info(3, 0x08047770)                        = 0
door_call(3, 0x080477E0)                        = 0
open("/rpool/backup", O_RDONLY|O_NDELAY|O_LARGEFILE) = 4
fstat64(4, 0x08047A10)                          = 0
fcntl(4, F_SETFD, 0x00000001)                   = 0
fstat64(4, 0x08047B10)                          = 0

habs ganze im uebrigen in ner vm neu installiert und relativ schnell denselben fehler erhalten

 

[hotzen]

s@otto123:
Bitte die WD20EARS nicht im raidz betreiben, da du hier definitiv in ein Alignement-Problem läufst! 128k/3 = 42,66k - hier muss also ständig neu aligned werden! 4k-Platten sind unter zfs noch immer problematisch - hier gibt es zwar die Möglichkeit, 'zpool' mit einem manuellen Patch neu zu kompilieren, um den den zpool mit einem angepassten Offset zu erstellen. Allerdings ist hier bisher noch aufgrund mangelnder Langzeiterfahrung nicht bekannt, ob es negative "Begleiterscheinungen" gibt. Weiterhin kann es definitiv passieren, dass du einen derart erstellten Pool nicht ohne gepatchtes 'zpool' importieren kannst, was es für den evtl. Fehlerfall problematisch macht, so dass du im schlimmsten Fall den kompletten Pool verlierst!

So pauschal kann man das nicht sagen, man kriegt auch 4k-override mit ZFSGuru ohne weiteres hin. U.a. hier: 3 or 4 HDDs in RaidZ1? - [H]ard|Forum

 

[ccmonster]

@otto123:
mit den drei Platten kompensierst du das Prob etwas, da du hier wieder aligned schreiben kannst. Bei 4 Platten empfehle ich dir 'mirror disk 1 disk2 mirror disk3 disk4'. Das Problem tritt teilweise nicht sofort, sondern erst nach entsprechender Nutzung auf! Bitte auch in regelmäßigen Abständen einen scrub über den Pool laufen lassen.
Bitte keinen Flash-Stick für den rpool verwenden - wenn dann auf ne esata-ssd oder esata-hdd zurückgreifen, da dir das Logging relativ schnell den Stick killen kann, was Erfahrungen mit cf-Karten zeigen.

@baldi:
Wie du meinem ersten Post eventuell entnehmen kannst, empfehle ich für raidz 3, 5 und 9 Platten. Bei vieren rate ich von raidz ab. Hier hatte ich also schon die "eine" Parität weggerechnet. Hätte ich evtl. erwähnen sollen - bin hier davon ausgegangen, dass es für jedermann verständlich ist, da otto123 nun 4 Platten hat.
Diese Problematik trifft im Besonderen auf 4k-Platten zu, aber im allgemeinen auch auf reguläre 512er Platten.

@hotzen:
Bitte nicht Äpfel mit Birnen vergleichen. zfsguru ist freebsd-basiert, welches hier auf den entsprechenden Offset angepasst wurde! Dies ist wie von mir bereits geschrieben in dieser Form auch mit OpenSolaris, OpenIndiana und Solaris 11 Express möglich.

@ulukay:
Diese Ausgaben geben leider tatsächlich keinen Aufschluss. Da ich sowohl virtuelle als auch physikalische Installationen besitze, hätte mir ein derartiges Verhalten schon auffallen müssen. Dies war bisher noch nicht der Fall.
Du greifst hier auf deinen rpool zu. Ist 'rpool/backup' ein encryptetes Volume oder lediglich ein Folder in /rpool?
Kannst du bitte deine Hardware posten? Ich gehe hier inzwischen eher von einem Hardware-Defekt denn von einem Software-Fehler aus. Bitte ggf. auch mal dein Install-ISO bzw. das gebrannte Medium kontrollieren (md5,sha256). Hier hatte ich mal massive Prob's mit OpenIndiana.
Hast du die Möglichkeit, dir weitere Platten für einen neuen zpool in das System zu hängen? Evtl. sogar sas an einem lsi oder u320 auf z.b. adaptec 39320a. Mir kommt das echt "spanisch" vor.
EDIT: warum swap't dein system? Wieviel RAM ist verbaut bzw. was läuft parallel? Bei mir ist der swap noch NIE genutzt worden! Evtl. mehr RAM stecken...

so far...
ccmonster

 

[hotzen]

mit freebsd kann man mit gnop 4k devices zerwingen und somit zfs überreden ein ashift=12 zu übernehmen. per pool-export und -import kann das dann in solaris übernommen werden. es ist also genau nicht so, dass man im source rumhacken muss um einen 4k compatiblen ashift zu bekommen.

 

[ccmonster]

mit freebsd kann man mit gnop 4k devices zerwingen und somit zfs überreden ein ashift=12 zu übernehmen. per pool-export und -import kann das dann in solaris übernommen werden. es ist also genau nicht so, dass man im source rumhacken muss um einen 4k compatiblen ashift zu bekommen.

Diese Methode ist mir selbstverständlich bekannt, allerdings gibt es - wie bereits erwähnt - noch keine definitiven Aussagen bzgl. Langzeitverhalten. Weiterhin arbeitest du dann mit einem veralteten zpool, so dass hier ein Upgrade nötig ist. Zu dem Verhalten mit einem encrypteten Volume in diesem "Bastard"-Pool kann ich leider garnichts sagen, da mir hier keine Werte vorliegen und mir meine Daten zu wertvoll sind! Sorry wegen dem Bastard - musste sein, also nicht zu ernst nehmen.
Weiterhin werde ich nach wie vor jedermann zu 512er Platten raten, da mir atm keine 4k-Enterprise-Platten bekannt sind. Selbst die 1TB-Constellation.2 haben 512er Sektoren! Und es hat imho einen Grund, weshalb im Enterprise-Sektor noch immer mit 512er Sektoren (okay - SAS und FC mal ausgenommen - hier gibt es auch 520 und 528 ) gearbeitet wird.

MfG ccmonster

 

[hotzen]

Die Hitachis haben auch 512byte Sektoren, allerdings haben diese 512b Platten dann eine (theoretisch) weitaus schlechtere Fehlerkorrektur, da die ecc-checksums nicht so breit sind wie bei 4k-Platten. Was noch gemacht wird, ist die Fehlerrate auf 10^-15 zu stemmen in dem mehr Platters mit geringerer Datendichte benutzt werden aber das will man aufgrund der Lautstärke und Verbrauch im Homeeinsatz und generell eigentlich nicht (Außer man erträgt eine Constellation neben sich und hat das Kleingeld dafür).

Davon abgesehen ist es absoluter Quatsch, einen ashift=12 Pool als bastardös zu bezeichnen, auch wenn es scherzhaft gemeint ist. Es ist nicht so, dass der Pool dadurch "unrein" wird, sondern ZFS wird durch den GNOP-Trick lediglich mitgeteilt, dass die HDD in der Tat 4k Sektoren benutzt, statt die Festplatten mit ihrer falschen 512b Aussage ZFS anlügen zu lassen. ZFS wird also nicht durch die falsche 512b Aussage verwirrt, sondern wählt ohne jegliches Gehacke einen genau passenden ashift=12 Parameter. Wenn, dann sollte es eher Probleme geben mit 4k HDDs, die 512 behaupten, da ZFS darauf angewiesen ist, die HDD Informationen genau zu kennen um performante Zugriffe gewährleisten zu können.

Darüberhinaus sind Pools mit ahift=9 (Pool initialisiert mit 512b Platten) schlicht nicht fähig 4k-Platten aufzunehmen (die dies per Firmware auch so kommunizieren, anstatt 512b), sobald diese demnächst mal released werden. Also schon im Sinne einer Zukunftssicherheit, sollte der Pool so initialisiert werden.

Und SE11 Encryption auf solch einem Pool geht auch. Die erste Meldung, dass encryption generell Probleme macht, ist ein paar Posts vorher aufgetaucht. Das kann ich mir auch durchaus gut vorstellen, hat allerdings herzlich wenig mit der ashift zu tun.

 

[ccmonster]

Mir ist klar dass diese Pools dann insofern korrekt erzeugt sind. Allerdings ist es so, wie du selbst geschrieben hast, dass atm alle 4k-Platten 512er Sektoren "rausgeben". Dass dieses Erstellen funktioniert ist mir klar, jedoch bewegen sich diese Pools außerhalb der vorgegebenen Spezifikationen, welche seitens zfs gesetzt sind.
Mit dieser Methode darf natürlich jeder arbeiten, der dies für richtig erachtet. Ich werde jedoch erst darauf zurückgreifen (4k-Platten), wenn ein entsprechender zpool regulärt released wurde.
Und imho sind Constellation nicht laut - sind reguläre 7,2k-Platten. Selbst meine Velos find ich angenehm... aber das ist wieder Ansichtssache - mein Desktop soll auch möglichst leise sein. Hier geht es aber um Storage...

Und bitte nicht gleich wegen Bastard angegriffen fühlen - war n Scherz - drum auch extra dazugeschrieben!

MfG ccmonster

 

[hotzen]

Ich weiß, ich fühle mich auch nicht angegriffen. Es wird nur nicht wahrer, dass "sich diese Pools außerhalb der vorgegebenen Spezifikationen (bewegen), welche seitens zfs gesetzt sind.", nur dadurch dass du es wiederholst.
Sie bewegen sich genau *innerhalb* der Spezifikation einer 4k Platte und aus ZFS-Sicht ist ashift=12 auch kein Wert außerhalb der Spezifikation: ZFS wählt diesen Wert freiwillig, wenn man ihm nur mitteilen kann, dass die HDD eigtl 4k Sektoren hat...

 

[Sumatrabarbe]

Tja meine Bastellösung hat sich gerade als Schrott erwiesen, nach jedem Neustart der VM waren 2 Platten als defekt gekennzeichnet und der pool im eimer... schade eigentlich... also doch nen windoof raid :-(