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

Schau dazu mal den letzten Satz unter
Wikipedia ext3

Wie sieht das denn bei den anderen Alternativen aus? (Reiser etc.)

Jo, dieses Problem hatte ich auch schonmal. Ist echt ärgerlich.

Das eleganteste wäre ein Filesystem, das wie unter Windows einen Papierkorb bereit stellt.

Die Implementation wäre eigentlich gar nicht so schwer. Man müsste dazu eigentlich nur das Fuse-Filesystem als Basis nehmen und alle Files in einen speziellen Ordner verschieben anstatt sie zu löschen. Wenn das Filesystem voll ist und noch weitere Daten geschrieben werden sollen, könnte man die ältesten Files im Papierkorb löschen.

Der große Vorteil wäre, daß man ohne irgendwelche Recovery-Tools auskommt und das darunter liegende Filesystem keine Rolle spielt.

Leider fehlt mir etwas die Zeit dazu, sonst hätte ich schon damit angefangen das zu implementieren.

ciao,

pacemaker

hannsens

Die Funktionalität, die Du wünscht würde das Prinzip Journaling Filesystem ad absurdum führen.

Du mußt für Dich, bzw. alle anderen für sich, eine Entscheidung fällen. Entweder schnelle fsck, auch nach Crash, und kein undelete Feature oder undelete und elendslange fsck Sessions nach Absturz .....

Ihr könnt ja auch wieder auf FAT/VFAT/FAT32 umsteigen, dort gibt es ein ähnliches Feature. Allerdings bezweifle ich hier noch mehr die Crash-Festigkeit.

Also, Grundsätzlich verstehe ich Dein "Kritik" nicht. Es gibt immer Vor- und Nachteil. Man muß sich deren nur im Vorfeld bewußt sein....

Bis dann
Frank

Die sicherste und vernünftigste Alternative wird wohl eine große externe Festplatte für Backups oder ein Backupserver sein.

@hummingbird_de

Deswegen ja der Vorschlag mit dem Userspace-Filesystem als 'Wrapper' um das eigentliche FS.

Das vereint beide Vorteile: Journaling und Undelete-Möglichkeit.

Der einzige Nachteil ist, daß es natürlich etwas Performance kostet. Bei 'größeren' Files (zu denen ich neben .vdr Files auch mp3's zähle) hält sich der Performance-Verlust aber in Grenzen.

Mir ist schleierhaft, warum es sowas noch nicht gibt.

ciao,

pacemaker

Befehl "rm" mit einem Script austauschen was ein mv in dem Ordner Papierkorb macht, wer sowas braucht

Bei reiserfs siehts wohl ähnlich finster aus dem Recovery.

AleX

Ja. Das geht dann aber nur, wenn man per Komandozeile etwas löscht.

Wenn irgendein anderes Tool etwas löscht, hat man schon wieder verloren. Ich denke da nur an Samba-Shares o.Ä.

@all

Die Performance wird das Hauptproblem sein. Man müßte quasi das Journal zu einer Datenbank aufblasen. Das würde dazu führen, das jeder FS Zugriff enorme Rechenleistung benötigen würde. Unterm Strich vermute ich würden wir dann einen Dualprozessor für unsere VDRs benötigen, einen für VDR, einen zweiten fürs FS ....

Wenn das einfach zu implementieren wäre und die Performance Beeinträchtigungen sich in Grenzen halten würden, hätte man das sicherlich schon längst umgesetzt.

Alle großen IT Unternehmen, die Server für OLTP & SAP Betrieb anbieten, HP, IBM etc., benutzen Journaling Filesystems ohne undelete Funktion. Und mal ehrlich eine gelöschte Datenbank Datei bei einer Supermarkt Kette kostet etwas mehr Geld als eine gelöschete MP3 oder VDR Datei. Das ist auch nicht schön, aber keine Katastrophe ....

In Umfeldern wie diesen wird man sogar strafrechtlich verfolgt, wenn man kein Sicherungskonzept umsetzt!

Bis dann
Frank

Würde ein

alias rm="rm -i"

in z.B. /etc/profile nicht helfen, obiges "Malheur" zu vermeiden? Dann müsste rm für jeden Ordner extra (hoffe ich, kann's grade nicht ausprobieren) nachfragen, ob xy wirklich gelöscht weren soll.

Ansonsten ist das mit dem Undelete natürlich Geschmackssache. Ich persönlich schätze es, dass es unter Linux (von Desktops wie KDE mal abgesehen) nicht sowas wie einen Papierkorb und auch kein Undelete gibt. Ich habe auch unter Windows den Papierkorb abgeschaltet und auf "sofort Löschen" gestellt. Gegen versehentliches Löschen von Benutzerdaten helfen Backups und die genannte Sicherheits-Nachfrage, gegen Löschen von Systemdaten durch Amoklaufende Skripts etc. helfen entsprechend restriktive Benutzerrechte.

Bye,
Andreas

HI allerseits!

Wollte auf diesem Wege auch nur schnell mal meinen Ärger über ext3 loswerden!!!!!

Vorgestern: nach performanceproblemen der letzten wochen writecache der hd eingeschaltet, nachts scheinbar ein reset/crash des rechners...

Gestern früh: vdr startet nicht mehr, eingabe-/ausgabefehler bei div. dateien zB libstdc++.5, etc

Gestern vormittag: linux startet nicht mehr, kernel panic ..., platte ausgebaut am anderen pc per knoppix gecheckt

Resultat: alle im rootdir befindlichen symlinks gerettet (WOW!!), sämtliche subdirs (von /usr /bin /etc /var /lib bis zu /sat /home ...) WEG!!!!!!

GRRRRRRRRRRRRRRRRRR!!!!!

tja, debian neuaufgesetzt, zum glück waren die mp3s und filme auf den platten 2 bis 4 (reiser) und nicht auf der ersten (ext3)

@all

Ich setzte seit dem ersten Auftauchen auf verschiedensten Rechnern ext3 ein. Grund waren die damals erlittenen Detenverluste mit ReiserFS (Kinderkrankheiten) und das man online ein ext2 auf ext3 bekommen kann. Ich habe noch nie(!) Datenverlust mit ext3 gehabt. Und ich rede hier nicht nur von VDRs oder Desktops, sondern vorallem von Linux-Servern bei meinen Kunden. Darunter große Cluster-Systeme und SAP/Oracle Instanzen. Und für meine Kunden ist eine versehentlich gelöschte Datei kein Problem, die haben Sicherungskonzepte. Ich selbst nehme es sportlich wenn die Dateien weg sind, ich kann mir ja schließlich nicht noch einen Sicherungsserver in das Wohnzimmer stellen.

Bax

Leider ist mir nicht bekannt auf welchem Pattern Du Performance Probleme attestiert hast. Aber der Linux Kernel erkennt in 99,999% aller Fälle das Optimum Deiner Hardware und betreibt diese so schnell und sicher wie möglich. Wenn Du nun den Write-Cache Deiner Platte entgegen aller Empfehlungen einschaltest und Daten verlierst, kannst Du die Schuld nicht irgendjemand oder irgendetwas anderem geben. Es gibt keine Empfehlung dies zu tun und wenn nur auf eigene Verantwortung.

Wenn also die Daten so wichtig sind, dann würde ich nicht solche Spielereien machen. Und wenn die HW zu langsam ist für Deine Anforderungen, mußt Du diese entsprechend ersetzen.

Trotzdem mein Beileid zum Datenverlust, sowas tut weh ....

Servus
Frank

Bax

Wenn der Write-Cache der Platte eingeschaltet ist, ist das Betriebssystem machtlos, da es nicht wissen kann, wann welche Daten tatsächlich auf Platte geschrieben werden. Das ist mal vom verwendeten FS unabhängig. Deshalb wie hummingbird_de schon sagte, Write Cache einschalten nur in bestimmten wohl überlegten Fällen. Performance-Probleme auf der Root-Platte gehören da mit Sicherheit nicht zu, zumal sich da schreibenderweise auch nicht allzu viel tun sollte. Auf 'ner extra Platte für Aufzeichnungen kannst du das evtl. machen.

Bye,
Andreas

Schreicache grundsätzlich nur Akku/Batterie gepuffert verwenden,
welcher autom. vom Controller überwacht wird und bei leerem/defektem Akku/Batterie/Cache
abgeschaltet, bzw. max. noch zum LeseCache hinzugeschaltet, wird!

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?

Die Performance von XFS kann ich nicht so genau beurteilen, ich hatte aber XFS selbst mal einige Zeit im Einsatz. Hauptgrund war damals, dass XFS das erste FS unter Linux war, das zuverlässig mit ACLs (Access Control Lists) umgehen konnte. Zuverlässig ist es auf jeden Fall.
XFS ist vor allem für groooße Datenvolumen geeignet, es kann meines Wissens 4TB oder mehr am Stück adressieren. Bei solch großen Systemen ist es mit Sicherheit auch schneller, da es das Journal auf einen extra Datenträger auslagern kann.
Ich glaube aber nicht, dass es für einen VDR nennenswert was bringt.

Zitat

Original von hummingbird_de
@all

Die Performance wird das Hauptproblem sein. Man müßte quasi das Journal zu einer Datenbank aufblasen.

Müsste man nicht, man kann Files ja in /.recycler verschieben, nur für root lesbar oder so. Wenn /.recycler überläuft wird immer das älteste gelöscht.

Man müsste nur "rm" eben ersetzen....das beträfe das Journal überhaupt nicht.

Zitat

Original von andreas_h
Bax

Wenn der Write-Cache der Platte eingeschaltet ist, ist das Betriebssystem machtlos, da es nicht wissen kann, wann welche Daten tatsächlich auf Platte geschrieben werden. Das ist mal vom verwendeten FS unabhängig.

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