OT: Ext3-Filesystem ist ja ein Datenfriedhof (kein Undelete moeglich!!!!)

Zitat

Original von celica

Wie sieht es denn eigentlich mit xfs aus?
Wollte xfs evtl. beim nächsten Umbau verwenden da mir in ersten Test`s die Performance besser erschien?

Hallo.

Ich nutz schon immer xfs für den vdr. Kann bis jetzt nichts negatives endecken.
Nutz xfs inzwischen auf allen Rechner.

Zitat

Original von s_herzog
AFAIK kann eine Platte ihre 8MB bei Stromverlust noch ausschreiben, oder hab ich das mal falsch gehört?

Das gilt für Platten mit Batterie-Backup, wie schon erwähnt wurde. Das gibt's in bestimmten SCSI-Platten, aber nicht in normalen IDE-Platten. Ein einfacher Kondensator würde dafür niemals ausreichen. Googel mal nach "schreibcache stromausfall", da findest du Info's.
Das Betriebssystem kann die Platte per Kommando dazu veranlassen, den Cache jetzt auf Platte zu schreiben, was IMHO vor dem Shutdown gemacht wird. Würde es das ständig machen, wäre der Sinn des Caches futsch.

Wer XFS System-FS für einen VDR nutzt, dem ist nicht mehr zu helfen.

XFS ist für große Dateien konzipiert wurden und verschwendet bei kleinereren Dateien Platz. Des Weiteren betreibt XFS extremes Caching. Alles was geht wird im Speicher gehalten, auch beim Schreiben. D.h. Strom weg, noch nicht geschriebene Daten weg. Das FS ist zwar noch konsistent durch das Journaling, aber es kann passieren, dass eine vorhandene Datei in einer noch älteren Version vorhanden ist.
XFS also nur auf Rechnern einsetzen, die
1. sehr Stabil laufen
2. Per UPS vor Stromausfall geschützt sind
3. wirklich nur viele große Dateien verwalten

Ext3 verschwendet zwar auch Platz ist aber etwas sicherer aber laaangsaaam.

Reiserfs hat mittlerweile alle Kinderkrankheiten hinter sich und läuft stabil. Außerdem wird weniger Platz verschwendet. Ich erinnere mich noch an meine volle 60er Ext3-Platte, die nach Backup/Restore auf Reiserfs nur noch mit ca. 42 Gb belegt war. Allerdings kann es bei Reiserfs vorkommen das ACLs noch nicht 100% implementiert sind. Das ist aber für VDRs irrelevant.

Wer ohnehin Experimente wagt, kann sich noch Reiser4 anschauen. Ist wahnsinnig schnell, braucht noch weniger Platz für dieselben Dateien, ist dafür noch sehr instabil.
Auf manchen Rechnern macht es gar keine Probleme auf manchen dafür ständig.

So das war mein Senf dazu.

phixom

Moin.

Also die video-Partition des VDR ist aber genau so ein Fall, bei dem man große Dateien hat. Denke schon, daß XFS dafür geeignet ist. Die System-Partition würde ich aber aus lieber mit Ext3 formatieren.

Wir verwenden xfs hier in der Firma eigentlich grundsätzlich (außer vielleicht auf den System-Partitionen). Bei uns kommt es auf Performance sowie Datensicherheit an (medizinischer Bereich).

@hummingbird_de:

Wie kommst Du darauf, daß man etwas am Journaling machen müsste? Mit Datenbanken schon gar nicht.

Wir haben hier in der Firma auch ein eigenes Dateisystem auf Basis von Fuse geschrieben. Es bietet zwar kein Undelete. macht dafür aber noch wesentlich kompliziertere Sachen. Der Performance-Verlust hält sich in Grenzen.

Für ein UndeleteFS würden ja die allermeisten FS-Zugriffe direkt an den Kernel weitergereicht. Deshalb sollte so ein FS auf etwa 80% der nativen Leistung der Festplatte kommen. Die CPU-Last ist auch nicht soooo groß. Dual-Xeons braucht man auf keinen Fall.

Ich würde es ja gerne beweisen, nur fehlt mir leider die Zeit.

Da Fuse ja jetzt offiziell in den Kernel aufgenommen wurde, erbarmt sich ja vielleicht jemand und schreibt sowas. Es gibt übrigens schon viele schöne auf Fuse basierende Filesysteme. Siehe hier:

http://fuse.sourceforge.net/wiki/index.php/FileSystems

Als Beispiel seien hier nur das ssh-FS oder das ftp-FS genannt. Es gibt aber auch ganz abartige Sachen wie ein WikipediaFS oder ein BitTorrent-FS. Der Fantasie sind keine Grenzen gesetzt.

Ciao,

pacemaker

phixom

Welche Gründe gäbe es, bei einem VDR so auf die FS-Performance zu achten? Ausser vielleicht bei den Extrem-VDR-Junkies hier mit mehreren TB Video-Speicher, 4 Karten und Gigabit-Anbindung sollte das eigentlich nicht so wichtig sein, oder? Mein VDR (siehe Sig) schafft es jedenfalls problemlos, die 100MBit-Anbindung zu füttern und auch eine oder zwei Aufzeichnungen schnell genug auf Platte zu schaufeln. Bei Plattengeschwindigkeiten von > 50MB/s ist das FS sicher nicht das Problem, oder?

Hi,

mal aus einer anderen Sicht: Usability. In so ziemlich jeder bedeutsamen Richtlinie zur ergonomischen User Interface Gestaltung (und ja, die CLI ist auch eins) steht ein Grundsatz, wie "das einfache Wiederherstellen nach Fehlern ermöglichen". Zumeist wird sogar noch expliziter eine Undo Funktion gefordert. Manchmal ist es in diesen Richtlinien so, dass bestimmte Regeln nur für Nichtexperten-Benutzer umgesetzt werden sollten (z.B. leichte Lernbarkeit). Das gilt aber nicht für die o.g. Die gilt immer.
Das wollte ich nur mal den Schlaumeiern unter die Nase reiben, die hier Sprüche loslassen, wie:

• muss der User sich eben entscheiden, ob er FS Journalling oder Undelete will
• bin froh, dass das in KDE nicht so ist (was i.Ü. nicht stimmt)

Das Fehlen einer zuverlässigen und transparenten Undelete Funktion ist aus Sicht der Softwareergonomie schlicht unerlässlich.

--schmettow.

schmettow

Ich fühl' mich jetzt mal direkt angesprochen...

Ja, ich kenne solche Richtlinien, und für die große Allgemeinheit der Fälle finde ich sie auch richtig. Deshalb ist es für mich auch OK, dass es unter Windows und auch unter KDE (so meinte ich das oben auch) einen Papierkorb gibt. Ich finde es aber auch gut, dass man das ggf. abschalten kann, denn es gibt auch Anwendungsfälle, in denen eine Undelete-Funktion nicht notwendig oder sogar schädlich ist. Diese konkrete Praxis wird von den Leuten, die sich solche Richtlinien ausdenken, oft nicht beachtet.
Ich arbeite u.a. in einem Umfeld, wo sicherheitskritische Daten bearbeitet werden, wo man sicher sein muss, dass sie nach dem Löschen tatsächlich nicht mehr lesbar sind. Deshalb sind dort Undelete-Funktionen schlicht verboten, sicherheitshalber wird beim Runterfahren der komplette freie Speicherplatz auf der Platte überschrieben. Die Leute dort sind natürlich entsprechend ausgebildet und wissen, dass sie den schnellen Löschfinger zu Hause lassen müssen.
Außerdem darf hier nicht vergessen werden, dass die Papierkorb-Funktion etc. keine Funktion des Dateisystems ist. Windows verschiebt die Dateien beim Löschen einfach in einen anderen Ordner, so wie KDE das auch macht. Die Kommandozeile unter Windows tut das im übrigen ebenso wenig wie das Linux-CLI. Ich halte es dort auch nicht für notwendig, da CLIs mittlerweile nur was für erfahrene Anwender sind. Für das eigentliche "User-Interface" des VDR (Fernbedienung) gibt es ja mittlerweile auch eine Undelete-Funktion via PlugIn.

So viel dazu, dass eine Undelete-Funktion "unerlässlich" sei.

Hi,

zugegeben: bei ausgeprägten Sicherheitsanforderungen an ein System gibt es meistens einen Tradeoff zur Usability. Das fängt meistens schon beim Authentifizierungsmechanismus (Login) an. Aber das trifft nur auf einen gewissen Anteil der Systeme zu, auf obigen Fall zumindest eindeutig nicht.
Außerdem sollte die Devise dann lauten, die Sicherheitsmechanismen für den User so transparent wie möglich zu halten. Ansonsten passiert das, was man als unerwünschte Adaption bezeichnet: Die Benutzer fangen an die Sicherheitsmechanismen systematisch zu umgehen. Im Fall der Passwortabfrage ist das z.B. das berühmt-berüchtigte Sticky Note am unteren Bildschirmrand.

Bei der Undelete Funktion könnte der Benutzer z.B. auf die Idee kommen, manuelles Backup oder Versionierung zu betreiben. Die elegantere Lösung wäre z.B. ein komplett verschlüsseltes Dateisystem mit Undelete Funktion.

Das bei Windows und KDE das Undelete nur "aufgepfropft" ist, halte ich ebenfalls für suboptimal, da das ergonomischen Prinzip der Konsistenz bzw. Erwartungstreue verletzt wird. Ob ich mich auf die Undelete Funktion verlassen kann, hängt u.U. davon ab, welchen Dateibrowser ich benutze.

Noch eine Bemerkung: Sicherheitsabfragen al la "alias rm rm -i" bzw. "Wollen Sie die Datei XY wirklich löschen?", sind ebenfalls keine Lösung, da ein Gewöhnungseffekt eintritt. Der zweite erforderliche Klick wird schlichtweg zu einem automatischen Verhaltensmuster und damit praktisch wirkungslos.

Die Vorschläge, die in diesem Thread gemacht wurden (z.B. transparentes Undelete mit FUSE) halte ich für ausgesprochen vernünftig. Selbst eine verringerung der Performanz um Faktor 10 ist m.E. akzeptabel (zumindest für Desktop Systeme). Das entspricht kaum der Größenordnung mit der heutige Virenscanner die Lese- und Schreiboperationen ausbremsen.

--schmettow.

Ich verspreche Dir, daß Du keinen Faktor 10 haben wirst. Noch nicht mal Faktor 2.

Also dann schmeiß schonmal den gcc an...

Zitat

Original von schmettow
Bei der Undelete Funktion könnte der Benutzer z.B. auf die Idee kommen, manuelles Backup oder Versionierung zu betreiben. Die elegantere Lösung wäre z.B. ein komplett verschlüsseltes Dateisystem mit Undelete Funktion.

Full ACK! Ist nur leider ein Performance-Problem bei größeren Datenmengen, aber da teste ich grade verschiedene Lösungen. Wie gesagt, sollte kein Widerspruch sein, nur ein Einwand gegen die Absolutheit deiner Äußerung.