PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Solange es nur um das OS geht (Warum will man TFFS oder NAS wiederherstellen? Die kann man anschließend per "Factory Reset" ja löschen lassen.), sind das ja alles nur "read-only"-Partitionen ... die Kernel-Partitionen sollten "im Betrieb" ohnehin gar nicht mehr angefaßt werden, weil die Kernel ja jeweils ins RAM entpackt wurden beim Start und da kein nachträglicher Zugriff erfolgen sollte bzw. auch nicht ohne weiteres erfolgen kann, denn die Kompression ist stream- und nicht block-basiert, so daß man da gar nicht eine bestimmte Stelle genau adressieren kann im gepackten Zustand, selbst wenn man eine Memory-Page nachladen wollte.
Und auch die Dateisysteme sind - schon wg. des verwendeten SquashFS-Formats - "nur lesbar" und es erfolgen aus dem laufenden System heraus keine weiteren Schreibzugriffe (auch nicht beim Dismounten). Die einzige Gefahr, die hier dann bestehen würde im laufenden Betrieb, ist die Notwendigkeit des "Nachladens" von Blöcken aus dem SquashFS-Image. Das gilt aber i.d.R. auch nur für die Dateien selbst, weil schon die Verwaltungsinformationen beim SquashFS komprimiert sind (auch das wieder stream-orientiert) und daher per se eigentlich schon im Speicher (in dekomprimierter Form) vorliegen.
Solange also auf einen System nicht jede Menge Prozesse parallel laufen bei wenig freiem RAM (was dann ggf. dazu führt, daß (r/o-)Speicherseiten verworfen werden und nachgeladen werden müssen, wenn sie wieder gebraucht werden - solange sie nicht gleich in Swap-Space ausgelagert werden), kann man einigermaßen risikolos auch die Partitionen "hinter" einem SquashFS-Image beschreiben.
Nur sollte man dann irgendwie dafür sorgen, daß (a) so wenige andere Prozesse wie möglich laufen (die dann Speicher anfordern könnten) und (b) die Kommandos bereits vorher klar sind und nicht erst eines nach dem anderen am Prompt eingetippt werden (müssen) und (c) das System danach so bald als möglich neu starten (ggf. vorher noch "sync"en), damit nicht doch noch Lesezugriffe auf mittlerweile geänderte Blockinhalte erfolgen.
Das geht notfalls (wenn man alles andere gesichert hat) auch über "sysrq-trigger" - solche "embedded devices" müssen das i.d.R. auch abkönnen, weil ihnen oft genug vom Besitzer einfach der Stecker gezogen wird.
Und auch die Dateisysteme sind - schon wg. des verwendeten SquashFS-Formats - "nur lesbar" und es erfolgen aus dem laufenden System heraus keine weiteren Schreibzugriffe (auch nicht beim Dismounten). Die einzige Gefahr, die hier dann bestehen würde im laufenden Betrieb, ist die Notwendigkeit des "Nachladens" von Blöcken aus dem SquashFS-Image. Das gilt aber i.d.R. auch nur für die Dateien selbst, weil schon die Verwaltungsinformationen beim SquashFS komprimiert sind (auch das wieder stream-orientiert) und daher per se eigentlich schon im Speicher (in dekomprimierter Form) vorliegen.
Solange also auf einen System nicht jede Menge Prozesse parallel laufen bei wenig freiem RAM (was dann ggf. dazu führt, daß (r/o-)Speicherseiten verworfen werden und nachgeladen werden müssen, wenn sie wieder gebraucht werden - solange sie nicht gleich in Swap-Space ausgelagert werden), kann man einigermaßen risikolos auch die Partitionen "hinter" einem SquashFS-Image beschreiben.
Nur sollte man dann irgendwie dafür sorgen, daß (a) so wenige andere Prozesse wie möglich laufen (die dann Speicher anfordern könnten) und (b) die Kommandos bereits vorher klar sind und nicht erst eines nach dem anderen am Prompt eingetippt werden (müssen) und (c) das System danach so bald als möglich neu starten (ggf. vorher noch "sync"en), damit nicht doch noch Lesezugriffe auf mittlerweile geänderte Blockinhalte erfolgen.
Das geht notfalls (wenn man alles andere gesichert hat) auch über "sysrq-trigger" - solche "embedded devices" müssen das i.d.R. auch abkönnen, weil ihnen oft genug vom Besitzer einfach der Stecker gezogen wird.