Probleme mit .2fs Files

Post Reply
Message
Author
srbo
Posts: 28
Joined: Fri 16 Nov 2007, 20:26
Location: Melle, Germany

Probleme mit .2fs Files

#1 Post by srbo »

Hallo!
Wie schon im Titel erwähnt habe ich in unterschiedlichen Installationen sehr große Probleme mit den .2fs Files.
Geprüft habe ich dieses unter Puppy 2.171, Muppy 008.1 und Muppy 008.2, wobei folgendes auffiel:

1.) Puppy/Muppy gestartet. (Klar.)
2.) Puppy/Muppy ordnungsgemäß beendet. (Auch klar.)
3.) Anderes Linux (SuSe oder im Wechsel Puppy/Muppy) gestartet.
4.) Mit e2fsck -y /path/file.2fs das File getestet / repariert.
5.) Punkt 4 aus Sicherheitsgründen wiederholt.
6.) Anderes Linux beendet.
7.) Puppy/Muppy gestartet.
8.) Puppy/Muppy beendet.
9.) Anderes Linux gestartet (Wie unter Punkt 3)
10.) .2fs File geprüft, es waren wieder Fehlereinträge vorhanden.

Bedauerlich dabei ist, daß e2fsck jederzeit die Meldung
/mnt/home/pup_save.2fs was not cleanly unmounted, check forced.
ausgibt obwohl ich vorher das frequentierende Puppy/Muppy garantiert ordnungsgemäß beendet hatte.

Was kann man machen? Ist das evtl. die Ursache dafür das hin und wieder die eine oder andere Anwendung nicht richtig läuft?

Stefan

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#2 Post by MU »

Tach,

ist genug Platz darin?
Ich vermute der check schreibt einige Daten, so daß es nicht voll sein darf.
Ich würde es problehalber auch mal von Puppy/Muppy aus checken.

Dazu Muppy von CD starten mit der Option
puppy pfix=ram

Oder erstelle im selben Ordner wie msy_save.2fs eine msy_save-DUMMY.2fs , dann erhältst Du ein Bootmenü, über daß Du Muppy von der Festplatte aus im Ram starten kannst.
Dann e2fsck ausführen.
Vielleicht gibt es da Versionsunterschiede in Suse?

Gruß, Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

srbo
Posts: 28
Joined: Fri 16 Nov 2007, 20:26
Location: Melle, Germany

#3 Post by srbo »

Selber Tach! :wink:

Die .2sf Files sind bis maximal 10% gefüllt und ich habe diese Test's u.A. auch mit SuSe's e2fsck, ist übrigens die selbe Software wie unter Puppy/Muppy, getestet. SuSe hatte ich nur verwendet um evtl. "Fehler" im e2fsck von Puppy/Muppy ausschließen zu können.

Ergänzend evtl. noch, dass es sich beim Wirtsystem, also dem Filesystem in dem die 2.fs Dateien enthalten sind, um vfat und reiserfs handelt, die Problematik ist die selbe und tritt auf mehreren PC's reproduzierbar auf.
Hardwareprobleme, wie z.B. defekte Cluster etc. sind an sich auszuschließen, alles vorher gecheckt.
Meine Vermutung geht eher so in die Richtung das Puppy evtl. wirklich nicht vollständig dismountet bevor der reboot/shutdown eingeleitet wird.

Ebenfalls Grüsse,
Stefan

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#4 Post by MU »

Meine Vermutung geht eher so in die Richtung das Puppy evtl. wirklich nicht vollständig dismountet bevor der reboot/shutdown eingeleitet wird.
Das kann man ja testen.
X beenden, und dann per Hand unmounten.
Wird noch auf Daten auf der gemounteten Platte zugegriffen, wird es Fehlermeldungen geben (cannot unmount, device is busy).

Die Problematik gab es früher bei Puppy1 mit Unionfs-layern, wenn man X nicht zuerst gekillt hat vor dem Unmounten.
Die unmount-scripte wurden später entsprechend angepasst.

Hab grad versucht Dich anzurufen, es geht aber keiner ran.
Gruß, Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

srbo
Posts: 28
Joined: Fri 16 Nov 2007, 20:26
Location: Melle, Germany

#5 Post by srbo »

Hallo!
Ich weiss, so einen Quatsch wie ich macht wahrscheinlich kein Mensch, nur habe ich das mit dem .2fs nochmals auf einem anderen PC getestet.

Das Ergebnis ist das selbe: .2fs File mit e2fsck geprüft und repariert, MUPPY 008.2 gestartet, gleich wieder runter gefahren, MUPPY 008.2 über pfix=ram gestartet, e2fsck brachte wieder die Meldung des nicht sauberen Dismounten und es wurden wieder Fehler korrigiert.

Da es hier um die Datensicherheit geht, mir diese sehr am Herzen liegt, denke ich schon das man sich dieses "Phänomens" mal dringend annehmen sollte, zumal es auch in PUPPY direkt auftritt.

Vielleicht ist es ja auch nur ein "Fehlalarm" von mir weil ich irgend etwas falsch mache.

Viele Grüße,
Stefan

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#6 Post by MU »

Scheint ein Systemimanentes Problem zu sein:
http://murga-linux.com/puppy/viewtopic.php?t=26594

http://www.murga-linux.com/puppy/viewtopic.php?t=17987

Barry:
The problem is not new with v2.16, it has always been there.
We have never been able to unmount the pup_save file cleanly.
GuestToo dazu:
sync flushes the write buffers to the save file ... most of the errors are orphaned inodes ... when a file is deleted that is still being used, the inodes will be marked as deleted, but the data will not be deleted ... the blocks holding the actual data will be marked as empty later ... if the system shuts down without unmounting, those blocks will not be marked as empty, but the inodes will say they are empty
...
i added a line to the init script in initrd.gz to repair my pup_save.3fs file when Puppy 216 boots (i had to find a patch for the cpio 2.7 source so it would work properly with symlinks)
Das heißt:
Der saubere Unmount hängt scheinbar mit dem Layersystem zusammen.
Werden Dateien gelöscht, werden die zugehörigen Inodes als gelöscht markiert. Nur die Daten selbst nicht.
Dies geschieht erst bei einem e2fsck, so daß GuestToo dies beim Start manuell erzwingt durch Aufruf von e2fsck.

Der Thread ist etwas schwer zu verfolgen, da er sich auf eine
Phase von Puppy 2 bezieht, in der gerade mit Aufs experimentiert wurde.
Eine "saubere" Lösung wurde offenbar nicht gefunden, dies erklärt, daß es in Puppy 3 ebenfalls vorhanden ist.

Interessant wäre für mich zu wissen, was für konkrete Folgen das hat.
Da die inodes als gelöscht markiert wurden, sind die Daten auch gelöscht (nur noch nicht mit Nullen überschrieben).
Ich habe nach dem Reboot wieder Platz, und kann neue Daten schreiben.
Dabei werden vermutlich die alten Datenfragmente einfach überschrieben.
Ich vermute, wichtig ist einzig die Inode-Tabelle, die ja richtig funktioniert.
Bislang konnte ich keine negativen Effekte bemerken in der Praxis.

Ich könnte initrd aber dahingehend patchen, so daß bei jedem Start ein e2fsck erzwungen wird, was im Serverumfeld Sinn machen würde.
Dann würden die Daten der Inode-Tabelle entsprechend wirklich gelöscht werden.

Dies sollten wir für Muppy-Server als default festlegen, sicher ist sicher, und ein Server wird nur selten rebootet. Da fällt der Zeitaufwand für den Check nicht ins Gewicht.

Gruß, Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#7 Post by MU »

Hier ist initrd.gz für Muppy008.2 zum testen.
Kann für alle 008.2 verwendet werden, auch Server-Alpha.
Ist die englische, das ist zum testen aber egal (geht auch mit den deutschen Muppys).

RECHTSklick zum runterladen verwenden (oder wget) :!:

http://dotpups.de/tests/initrd.gz

Die einzige Änderung ist:
direkt bevor msy_save*.2fs gemountet wird, wird ein e2fsck -y ausgeführt.

Ich bekomme hier immer 4 Fehler bezüglich inodes angezeigt, wenn ich Muppy sofort reboote, nachdem es gestartet wurde.
Vermutlich verursacht durch Temporärdateien wie bootsystem.log.

Ich vermute, dies passiert:
Puppy erstellt Temporärdateien, bevor es den Pivot auf Unionfs durchführt.
Dann werden sie ins Unionfs-Dateisystem kopiert.
Damit können die ursprünglichen dann nicht mehr sauber unmountet werden.

Gruß, Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#8 Post by MU »

nochwas:
speziell in Bezug auf Minisys.

Das ganze Unionfs-Geraffel ist ja überhaupt nur nötig, um die UNIX-Ordnerstruktur (schreibgeschützt) beschreibbar zu machen.
Also /usr , /var und so weiter.

Aber Minisys hat mit UNIX ja nix zu tun.

Es ist also auch nicht nötig, es per Unionfs einzubinden.

Ansatz: Minisys fliegt raus aus msy_082.sfs.
Stattdessen setzen wir eine zweite Speicherdatei ein.

Diese wird nicht per Unionfs gemountet, sondern "normal".

Also:

mkdir /minisys
mount /mnt/home/zweite.2fs /minisys

Wird Muppy runtergefahren, wird die ge-unmounted:
sync
umount /minisys
wmpoweroff

Damit haben wir dann zumindest für Minisys ein "perfekt" ungemountetes Dateisystem.

Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#9 Post by MU »

Denkt man diesen Ansatz weiter, könnten auch die Home-Ordner wie /root in zweite.2fs.

Es sollte wirklich nur das per Unionfs gemerged werden, was unbedingt nötig ist.
Also nur das per squashfs hochkomprimierte Kernsystem.
Alle userspezifischischen Daten sollten ohne Unionfs in der zweiten Speicherdatei abgelegt werden.
Unionfs würde dann nur verwendet, um "updates" des Kernsystems durchzuführen.

Dies hätte den Nebeneffekt, daß Updates, z.B. von 008.3 auf 008.4 einfacher wären.
Durch die strikte Trennung von Daten und System muß nur das System geupdatet (ersetzt) werden, nicht jedoch zweite.2fs.

Der Gedanke gefällt mir immer besser.
Das wäre auch ganz im UNIX-Sinne, da /home in Serversystemen eigentlich immer auf einer eigenen Partition liegt.
Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

srbo
Posts: 28
Joined: Fri 16 Nov 2007, 20:26
Location: Melle, Germany

#10 Post by srbo »

Hi Mark,
Dies hätte den Nebeneffekt, daß Updates, z.B. von 008.3 auf 008.4 einfacher wären.
Durch die strikte Trennung von Daten und System muß nur das System geupdatet (ersetzt) werden, nicht jedoch zweite.2fs.

Der Gedanke gefällt mir immer besser.
Das wäre auch ganz im UNIX-Sinne, da /home in Serversystemen eigentlich immer auf einer eigenen Partition liegt.
sehe ich genau so, hätte sogar noch den guten Nebeneffekt, daß für die Datensicherung nur die Datenbereiche kontinuierlich gesichert werden müssen bzw. über ein rollierendes Backupsystem automatisch 1 oder 2 Backups auf dem PC lokal vorliegen könnten ohne gleich die ganzen Programme doppelt bzw. 3-fach mitzukopieren.

Gruß,
Stefan

User avatar
urban soul
Posts: 273
Joined: Wed 05 Mar 2008, 17:03
Location: "Killing a nerd is not as much fun as ist sounds" B.Simpson
Contact:

#11 Post by urban soul »

Hallo,

unionfs hat hier ein Problem. Es kommt nämlich zu einer catch 2-2 Situation, da in Puppy / gelayert wird. Komischerweise wirkt sich das in der Praxis bei den meisten (nicht allen!) Anwendern kaum aus.

Ich reagiere darauf so, dass ich das .2fs-file als Systemergänzung benutze und alle Userdaten auf einer eigenen Partition liegen.

Ich wurde auf diese Sache aufmerkam nachdem auch meine NTFS Partitionen nicht sauber ausgehängt wurden und das ist dann schon kritisch.

Trotzdem: Der Vorteil überwiegt in meinen Augen: extrem flexibel ist das Ganze und die Entwicklunger wissen das zu schätzen.

In Puppy 3.02alpha1 ist der fsck übrigens wieder standartmässig im init Skript.

urban
Last edited by urban soul on Thu 27 Mar 2008, 04:09, edited 1 time in total.

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#12 Post by MU »

Danke, urban.

Ich hab das Thema nochmal im Bug-form zur Sprache gedacht.
http://murga-linux.com/puppy/viewtopic.php?t=27407

Barry plant, sich des Problems anzunehmen, durch neuere Kernel mit bereinigtem Unionfs.
Damit soll es möglich werden, Layer wieder zu unmounten.
Ein rewrite des Init-scripts wäre dann noch nötig.

Ich gehe davon aus, daß das noch dauern wird, daher müssen wir für die 008er Serie von Muppy mit Workarounds leben (Dateisystemcheck beim booten, evtl. ext3, und für Minisys ein extra save.2fs ohne Unionfs).

Stefan, wir besprechen Details dann ab Dienstag persönlich.
Gruß, Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

User avatar
urban soul
Posts: 273
Joined: Wed 05 Mar 2008, 17:03
Location: "Killing a nerd is not as much fun as ist sounds" B.Simpson
Contact:

#13 Post by urban soul »

@Mark:
genau: man müsste im laufenden Betrieb layers aus der union entfernen können. Und das wird auch kommen, da bin ich ganz optimistisch. (War ja schonmal angekündigt).

Nochmal für alle: Das ist kein Puppy Bug sondern ein Limit von Unionfs und spielt in Praxis (seltsamerweise möchte man meinen) keine Rolle.

Urban

Post Reply