ZFS Problem 9.2 > 10.x stable

F

fred123

Well-Known Member
Hallo,
.
ich habe hier eine Daten-Platte per Post bekommen.
.
Eingerichtet auf Freebsd 9.2 ZFS/gpt/4K Sektoren. Die kann ich nicht einbinden:-(( Die Daten brauch ich aber.
.
####
root@XXX] ~# zpool import
pool: XXX-media
id: 6057280739025491841
state: UNAVAIL
status: The pool uses the following feature(s) not supported on this
sytem: com.delphix:hole_birth
action: The pool cannot be imported. Access the pool on a system that
supports the required feature(s), or recreate the pool from backup.
config: XXX-media UNAVAIL unsupported feature(s)
gpt/PumaHub ONLINE
[root@XXX] ~#
#####

Hier läuft eine Standard 10 Installation "out of the box" mit mehreren ZFS-Pools ohne schnick schnack.

####
[root@XXX] ~# uname -a
FreeBSD GRAB 10.0-RELEASE-p17.....
#####
.
Im Netz fand ich nichts "wirklich" Informatives darüber. Das Problem scheint aber bekannt zu sein:-((
.
Hat jemand einen TIP, oder muss ich ein 9.2 aufsetzen um die Platte lesen zu können?
.
Gruss
Fred
 
Jau, ist die sicher aus einem späten 9.2-STABLE kurz vor der Umbenennung in 9.3. Wie Foxit sagt, sollte ein 9.3 oder 10.1 sie lesen können.
 
Yamagi schrieb:
Jau, ist die sicher aus einem späten 9.2-STABLE kurz vor der Umbenennung in 9.3. Wie Foxit sagt, sollte ein 9.3 oder 10.1 sie lesen können.
Zum Vergrößern anklicken....
.
Danke! Problem gelöst! (RTFM hatte ich nicht auf dem Schirm:-()
.
Fred
.
Ps. Wobei mir diese "Kurve" im ZFS bei den Versionssprüngen NICHT ganz verständlich ist?????
 
Das Problem ist wohl, dass es keine Kurve gibt. :) Solange Sun ZFS entwickelte, war die Welt einfach. Nur Sun entschied, welche Änderungen einflossen und welche draußen blieben. Mit jeder inkompatiblen Änderung konnten sie die Versionsnummer erhöhen und ältere Implementierungen wussten Bescheid, dass sie den Pool nicht lesen können. Bei OpenZFS stehen allerdings viele Entwickler aus verschiedensten Interessengruppen dahinter, die sich nicht unbedingt gut koordinieren können. Daher wurden die "Feature Flags" eingeführt. Die Basisversion ist ZFS v28, die um Feature Flags erweitert zu ZFS v5000 wurde. Jede Implementierung von OpenZFS kann ZFS v28 und ZFS v5000 für sich genommen problemlos lesen.
Wenn man nun etwas an ZFS ändert, was in die Datenstrukturen auf der Festplatte eingreift, definiert man ein Feature. Wenn der Nutzer diese neue Funktion nutzen will, aktiviert er das Feature und es wird im Pool vermerkt. Die Implementierung schaut dann beim Import, welche Features auf dem Pool aktiviert sind und welche von ihr unterstützt werden. Daran entscheidet sie, ob der Pool komplett, nur lesbar oder gar nicht importiert werden kann. Feature Flags sorgen also eigentlich nur dafür, dass die parallelen Entwicklungen OpenZFS nicht in diverse, komplett inkompatible Zweige zerfallen lassen, wie es bei UFS der Fall war.
Normalerweise landen Features früher oder später in OpenZFS. Schon daher, weil die Entwickler sich das Leben nicht durch einen divergierten Zweig deutlich erschweren wollen. FreeBSD folgt OpenZFS mit wenigen Tagen Abstand, zumindest das aktuelle -CURRENT unterstützt daher eigentlich immer alle Features. Die -STABLEs können natürlich ein wenig hinterher hinken.
 
Prof. Yamagi schrieb:
Viele erleuchtende Hintergründe !
Zum Vergrößern anklicken....
.
Danke für die "Vorlesung" , aber warum 9.2 ohne, 9.3 mit, 10.0 OHNE, 10.1 wieder mit?
.
Ok, da laufen wohl 2 Produktionsrelase parallel, aber das dadurch abwärts Dateisysteminkompabilitäten entstehen, kommt mir bei BSD zu 1.Mal unter. Gab mal im 5.x so was mit HFS, (schwach erinner??), da hatte der Entwickler keine Lust mehr, das fiel dann raus..... na ja.
.
Danke
Fred
 
Ja, weil es tatsächlich zwei parallel laufende Zweige sind. Die zeitliche Abfolge war: 9.2 -> 10.0 -> 9.3 -> 10.1. Dadurch hat 9.3 trotz niedriger Versionsnummer ein neueres ZFS als 10.0.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben