komisch bei uns läuft Grossrechner seit 15 Jahren störungsfrei und ohne Datenverlust oder Auszeit. Da muss jemand die Fehler aber wirklich gut in der Hardware versteckt haben, wenn die sich so lange nicht melden..
Von Jörg W Mittag am Di, 8. August 2006 um 17:41 #
Festplatten haben Blockprüfsummen, die beim Lesen geprüft werden. Das bringt beim Schreiben also schon mal genau gar nichts. Blockprüfsummen bringen außerdem nichts, wenn der falsche Block gelesen wird (sog. RRP-Fehler (read wrong place) z.B. durch overpowered seeks) oder wenn beim Schreiben die Datenträgeroberfläche nicht richtig magnetisiert wird (sog. DNW-Fehler (did not write) z.B. durch high-flying writes). Und natürlich schützen sie nicht gegen Fehler in den Prüfsummenroutinen der Festplatte, gegen Übertragungsfehler zwischen Festplatte und Hostadapter, zwischen Hostadapter und Speicher, zwischen Speicher und Prozessor sowie gegen umgekippte Bits im Speicher.
Von Victor V. Terber am Di, 8. August 2006 um 10:23 #
Heißt das jetzt Zettabyte oder Zetabyte?
Wenn man ausschließlich auf Suns Webseiten googelt, bekommt man dutzendhaft Belege für beide Schreibweisen, manchmal gar im selben Dokument. Auch ob "Zetabyte" ein "echtes" Wort ist, scheint bei Sun umstritten. Mehrere Quellen geben naheliegenderweise an, dies beziehe sich auf die Einheit Zetabyte (gleich 10 hoch 21 Bytes). Der "Sun Engineering Community Manager" Jim Grisanzio zitiert auf seiner Webseite gar einen Bericht der (abstruserweise?) behauptet, "a zetabyte being 128 bits". Wieder andere meinen, dies sei ein Kunstwort.
Kann das jemand aufklären, vorzugsweise von Sun selbst? Zetta oder Zeta?
"Das »Zettabyte File System« bricht mit einigen Paradigmen der Unix-Welt radikal und bringt die modernsten Konzepte von Dateisystemen und Volume-Managern zusammen."
Hätten sich ein paar Wichtigtuer nicht so sehr an der irreführenden Benennung der Reiser4-Module (Plugins) aufgeregt und nciht verlangt, dass alle Reiser4-Features allen anderen Dateisystemen zugänglich gemacht werden sollten (verlagerung in das VFS), dann wäre das ZFS nur das zweitmodernste Dateisystem der Welt.
Schade.
Aber immerhin haben es ja manche Distributionen dabei, so dass sich der interessierte Entwickler selbst ein Bild davon machen kann.
Beim Wort modern sträuben sich mir sowieso immer die Nackenhaare ... nur weil viele etwas tun, muß das nicht gut oder gar besser sein, als altbewährtes (der Umkehrschluß stimmt sicherlich auch!).
Oder um es mit Otto Rehakles Worten in Bezug auf seine antiquirte Spielphilosophie zu sagen: "Modern ist, wer gewinnt!"
Mich interessiert nicht, welches FS wie modern ist, sondern ob die Konzepte dahinter funktionieren! Bei Modernitätsranglisten läge M$ in vielen Kategorien vorne - und wir alle wissen, daß man damit in Sachen Qualität nur selten gewinnt!
> Modern < ... ist relativ. Ein wirklich modernes Filesydtem, das aber auch schon in die jahre gekommen ist, aber immer noch allen Anderen um Lichtjahre voraus ist ===> BFS = BeOS File System. Integriert bzw. Bestandteil von BeOS, Haiku , ZETA und SkyOS. Unglaublich, was dieses Filesystem leistet ! Dank an Jean-Luis Gasse , dem Entwickler von BeOS, das leider aufgrund mangelndes Marketing den Bach runter ging . Hätte sich Steve "Appe" damals für BeOS entschieden und Gasse in den Vorstand aufgenommen, dann hätten wir heute wahrscheinlich das schnellste, sicherste und stabilste OS aller Zeiten. Aber leider nahm die Geschichte einen anderen Lauf.....
Du wiedersprichst dir etwas selbst. Also Reiser4 ist ein fertiges Filessystem das sogar schon eingesetzt wird, nur hat es den Einzug in den Linuxstandardkernel noch nicht geschafft, aber auch ZFS ist nicht im Linuxstandardkernel. Doch werden beide verwendet und genutzt, das modernste Filesystem hat nichts damit zutun ob es im Linuxstandartkernel ist, wenn ich durch gottes eingebung ein Filesystem erfinde das so viele neue Features und Konzepte hat wie kein anderes Filesystem, es aber nur auf einen einzige kaum eingesetzten BS verwendet werden kann ist es dann doch das modernste Filesystem zu diesen Zeitpunkt. Aber wenn es dich freut dann sag doch einfach Reiser4 sei das modernste. Doch bedenke das einige andere Meinung sind und dies anzweifeln werden, also leg dir schon mal paar Argumente bereit die deine Aussgae untermauer.
Mit FUSE scheint es sowas wie eine API für Linux zu geben, und was passiert? Ein Haufen Zeuges dockt dort an und funktioniert, und alle sind irgendwie glücklich. Wie war das mit einer stabilen API und Linux? Stichwort Gerätetreiber
Schade, dass ZFS ueber FUSE eingebaut wird. Ich haette mich wirklich gefreut, wenn man das Dateisystem "nativ" und fuer / nutzen haette koennen. Naja.. was soll's? Ich hab sowieso nur eine Linuxkiste hier rumfahren. Die restlichen sprechen ZFS oder UFS richtig.
wie war das? ein tool eine aufgabe? was soll ein datei system mit nem volume manager? es gibt doch den device mapper? da reicht es doch wenn das dateisystem gut mit aenderungen an den LVs klar kommt und z.b. dynamisch wachsen/schrumpfen kann,kein grund nen eignene volume manager zu haben...
Wenn man von Haus aus eh nur ein Filesystem hat, kann man doch bequem den LV integrieren, insbesondere wenn man das Software-RAID auch noch mit integriert. Denn Wunsch "Ich hätte gern eine 10G Partition auf einem RAID 5" kriegt man mit getrennten Komponenten nicht so einfach hin.
? einfach den device mapper auf die raid5 device kloppen und gut is? hab ich mit raid1 schon gemacht...
ich hab ja nichts gegen wenns gut zusammenarbeitet,vll noch paar programme/scripts die die noetigen befehle alle aufrufen,aber doch nicht unzertrennlich...
Dann hat Sun halt eventuell andere Prioritäten als du. (Es ist eigentlich sowieso ein Anachronismus, Dateisysteme und Partitionen zu haben. Erst das eine vergrössern, dann das andere. Warum nicht Partitionen abschaffen und nur noch Dateisysteme? In die Richtung geht m.E. ZFS.)
Ich habe jetzt schon öfters von FUSE gelesen und weiss, das damit Dateisysteme nicht im Kernelspace sondern im Userspace ablaufen. So. Hier endet mein Horizont.
Ich wäre euch sehr dankbar wenn mir irgendwer, auf einfach, sagen könnte was ich mir darunter vorstellen muss.
Ist der Treiber nicht mehr im Kernel sebst? Macht FUSE eine Schnittstelle zwischen Kernel und Treiber? Wenn ja, funktioniert diese Schnittstelle nur für Dateisysteme? Kann man FUSE auch für das Dateisystems des root directorys verwenden? Was sind die Nachteile von FUSE? Bekomme ich als Heimanwender davon überhaupt was zu sehen?
Ich glaub jetzt hab ich alle Fragen gestellt die mir momentan dazu einfallen und ich würde mich freuen, wenn mir irgendjemand ein wenig auf die Sprünge helfen könnte.
Fuse besteht aus einem Kernelmodul einer Bibliothek und ein paar Progrämmchen.
Das Kernelmodul stellt alle nötigen funktionen zur verfügung, um Programmen es zu ermöglichen wie Dateisysteme zu eragieren. Wenn man ein programm startet, welches Fuse verwendet, so werden alle anfragen die auf dem mountpoint erfolchen (lesen schrigen, stat, mkdir, touch, etc.) an das Programm weitergeleitet, welches passend reagieren muß.
Die Voreile: - auch einfache User können Dateisysteme, ohne irgendwelche subit/sudo/rechte, mounten (sofern das dateisystem als als Fuseimplementation vorliegt.) - Es können Programmierstrukturen verwendet werden, die im Kernel selber nicht erlaubt sind (Rekusionen, Rückgriff auf andere Biblitheken usw.) - man kann zweckbezogene Dateisysteme programmieren (z.B. ein Dateisystem, welches die aktuellen Zustand einer Datenbank repräsentiert) - Der Kernel ist sicher wenn das Fuse-Dateisystem abstürzt. (vorausgesetzt, das Problem liegt nicht am Kernelmodul) - man ist nicht auf C angewiesen um ein Dateisystem zu Programmieren (man kann auch C#, Java, Ruby, Python, Perl, C++ verwenden)
die Nachteile: - Es ist langsamer als ein Kernelmodul - Es funktioniert nur wenn Fuse im Kernel ist. - Aus Sicherheit sind gewisse Aktionen nicht erlaubt. - die Anzahl der zu nutzenden Dateisysteme ist beschränkt (ich galube Kernelbedingt sind es 24) - Man braucht das Dateisystemprogramm um auf daten zurückgreifen zu können. Ein mit fuse erstelletes Dateisystem ist nur bedingt inerportabel,
Das Modul ist nur dazu gedacht Dateisysteme zu Programmieren, zu nichts anderem.
1. Don't trust faulty hardware.
2. Every hardware is faulty.
Dort stellt sich der Experte von einem Datenrettungsunternehmen die selbe Frage.
jwm
Wenn man ausschließlich auf Suns Webseiten googelt, bekommt man dutzendhaft Belege für beide Schreibweisen, manchmal gar im selben Dokument. Auch ob "Zetabyte" ein "echtes" Wort ist, scheint bei Sun umstritten. Mehrere Quellen geben naheliegenderweise an, dies beziehe sich auf die Einheit Zetabyte (gleich 10 hoch 21 Bytes). Der "Sun Engineering Community Manager" Jim Grisanzio zitiert auf seiner Webseite gar einen Bericht der (abstruserweise?) behauptet, "a zetabyte being 128 bits". Wieder andere meinen, dies sei ein Kunstwort.
Kann das jemand aufklären, vorzugsweise von Sun selbst? Zetta oder Zeta?
Hätten sich ein paar Wichtigtuer nicht so sehr an der irreführenden Benennung der Reiser4-Module (Plugins) aufgeregt und nciht verlangt, dass alle Reiser4-Features allen anderen Dateisystemen zugänglich gemacht werden sollten (verlagerung in das VFS), dann wäre das ZFS nur das zweitmodernste Dateisystem der Welt.
Schade.
Aber immerhin haben es ja manche Distributionen dabei, so dass sich der interessierte Entwickler selbst ein Bild davon machen kann.
Oder um es mit Otto Rehakles Worten in Bezug auf seine antiquirte Spielphilosophie zu sagen: "Modern ist, wer gewinnt!"
Mich interessiert nicht, welches FS wie modern ist, sondern ob die Konzepte dahinter funktionieren! Bei Modernitätsranglisten läge M$ in vielen Kategorien vorne - und wir alle wissen, daß man damit in Sachen Qualität nur selten gewinnt!
Ciao,
Christian
Ein wirklich modernes Filesydtem, das aber auch schon in die jahre gekommen ist, aber immer noch allen Anderen um Lichtjahre voraus ist ===> BFS = BeOS File System.
Integriert bzw. Bestandteil von BeOS, Haiku , ZETA und SkyOS.
Unglaublich, was dieses Filesystem leistet ! Dank an Jean-Luis Gasse , dem Entwickler von BeOS, das leider aufgrund mangelndes Marketing den Bach runter ging .
Hätte sich Steve "Appe" damals für BeOS entschieden und Gasse in den Vorstand aufgenommen, dann hätten wir heute wahrscheinlich das schnellste, sicherste und stabilste OS aller Zeiten. Aber leider nahm die Geschichte einen anderen Lauf.....
I love ZETA and SkyOS.
fridy
Ein Haufen Zeuges dockt dort an und funktioniert, und alle sind irgendwie glücklich. Wie war das mit einer stabilen API und Linux? Stichwort Gerätetreiber
Gruß Micha
Aber wenn du lust hast, kannst du ja
"Drivers in userspace" gründen.
"Drivers in userspace" gründen.
JUHUU.... endlich ein Microkernel
was soll ein datei system mit nem volume manager? es gibt doch den device mapper? da reicht es doch wenn das dateisystem gut mit aenderungen an den LVs klar kommt und z.b. dynamisch wachsen/schrumpfen kann,kein grund nen eignene volume manager zu haben...
Wenn man von Haus aus eh nur ein Filesystem hat, kann man doch bequem den LV integrieren, insbesondere wenn man das Software-RAID auch noch mit integriert. Denn Wunsch "Ich hätte gern eine 10G Partition auf einem RAID 5" kriegt man mit getrennten Komponenten nicht so einfach hin.
ich hab ja nichts gegen wenns gut zusammenarbeitet,vll noch paar programme/scripts die die noetigen befehle alle aufrufen,aber doch nicht unzertrennlich...
Richtig, warum also krampfhaft auf mehrere Tools aufteilen?
Schau dir einfach die beiden Demons "ZFS Basics" und "Self Healing" an, dann können wir weiter diskutieren.
http://www.opensolaris.org/os/community/zfs/
Ich habe jetzt schon öfters von FUSE gelesen und weiss, das damit Dateisysteme nicht im Kernelspace sondern im Userspace ablaufen. So. Hier endet mein Horizont.
Ich wäre euch sehr dankbar wenn mir irgendwer, auf einfach, sagen könnte was ich mir darunter vorstellen muss.
Ist der Treiber nicht mehr im Kernel sebst?
Macht FUSE eine Schnittstelle zwischen Kernel und Treiber?
Wenn ja, funktioniert diese Schnittstelle nur für Dateisysteme?
Kann man FUSE auch für das Dateisystems des root directorys verwenden?
Was sind die Nachteile von FUSE?
Bekomme ich als Heimanwender davon überhaupt was zu sehen?
Ich glaub jetzt hab ich alle Fragen gestellt die mir momentan dazu einfallen und ich würde mich freuen, wenn mir irgendjemand ein wenig auf die Sprünge helfen könnte.
Vielen Dank
Das Kernelmodul stellt alle nötigen funktionen zur verfügung, um Programmen es zu ermöglichen wie Dateisysteme zu eragieren. Wenn man ein programm startet, welches Fuse verwendet, so werden alle anfragen die auf dem mountpoint erfolchen (lesen schrigen, stat, mkdir, touch, etc.) an das Programm weitergeleitet, welches passend reagieren muß.
Die Voreile:
- auch einfache User können Dateisysteme, ohne irgendwelche subit/sudo/rechte, mounten (sofern das dateisystem als als Fuseimplementation vorliegt.)
- Es können Programmierstrukturen verwendet werden, die im Kernel selber nicht erlaubt sind (Rekusionen, Rückgriff auf andere Biblitheken usw.)
- man kann zweckbezogene Dateisysteme programmieren (z.B. ein Dateisystem, welches die aktuellen Zustand einer Datenbank repräsentiert)
- Der Kernel ist sicher wenn das Fuse-Dateisystem abstürzt. (vorausgesetzt, das Problem liegt nicht am Kernelmodul)
- man ist nicht auf C angewiesen um ein Dateisystem zu Programmieren (man kann auch C#, Java, Ruby, Python, Perl, C++ verwenden)
die Nachteile:
- Es ist langsamer als ein Kernelmodul
- Es funktioniert nur wenn Fuse im Kernel ist.
- Aus Sicherheit sind gewisse Aktionen nicht erlaubt.
- die Anzahl der zu nutzenden Dateisysteme ist beschränkt (ich galube Kernelbedingt sind es 24)
- Man braucht das Dateisystemprogramm um auf daten zurückgreifen zu können. Ein mit fuse erstelletes Dateisystem ist nur bedingt inerportabel,
Das Modul ist nur dazu gedacht Dateisysteme zu Programmieren, zu nichts anderem.