# Filesystem gesucht

## 69719

Servus,

ich hatte vor einer ganzen weile mal etwas von einem Filesystem gelesen, welches man über ein anderes mounten konnten und man trotzdem die Files von dem Dateisystem darunter sehen konnte. Ich vermute, dass ich das im Zusammenhang mit Portage speedup gelesen hatte. Dort war die rede von einem ro Portage FS, welches unter /usr/portage gemountet wurde und anschliessend ein anderes drüber gehangen, was dafür sorge, dass das ro FS gesehen werden konnte, aber man auch Änderungen vornehmen kann, die aber in ein extra Image/Partition geschrieben werden.

Beispiel:

test.iso beinhaltet

 - file1

 - file2

/dev/sda1 beinhaltet

 - file 3

 - file 4

erst wird test.iso nach /usr/portage gemountet, anschließend /dev/sda1.

Und es sollen alle 4 files nun dort zu sehen sein.

Hat eventuell jemand Informationen dazu für mich?

* UPDATE *

Es müßte sich um sys-fs/unionfs handeln, wenn ich richtig liege.

----------

## disi

http://aufs.sourceforge.net/

http://www.fsl.cs.sunysb.edu/project-unionfs.html

 :Smile: 

----------

## Christian99

Hi, wie disi schon sagte, sind das unionfs oder das neuere aufs. wenn du es für portage verwenden willst kommt der geschwindigkeitsvorteil eher durch ein komprimierendes fs, zb squashfs, welches ro ist.

In diesen zusammenhang kann ich squash_dir aus dem mv overlay wärmstens empfehlen. das bietet init skripte, die das verzeichniss mounten, so dass man drin schreiben kann (über aufs) und beim runterfahren wird auf änderungen überprüft, und gegebenenfalls ein neues image mit den änderungen erstellt. Sehr schön zu konfigurieren, spart einen die relativ kompliziereten aufs optionen in der /etc/fstab.

Ich verwende das, und mein portage tree braucht statt 300MB nur 90MB

----------

## 69719

Um Portage speedup geht es mir gar nicht. Ich habe das Problem, dass meine Media Kiste zuhause immer mal nach einem Update nicht funktionieren will und da möchte ich ganz gerne ein Rollback haben ohne ganze Backups einspielen zu müssen. Aber scheinbar ist das mit unionfs/aufs nicht wirklich möglich, da ich dies nicht wirklich über das root Filesystem hängen kann. Ich werde wohl einen Wrapper schreiben der jegliche Schreibvorgänge/Lesevorgänge umbiegt, ähnlich wie VMware ThinApp. So sind dann die Updates im System für den aktuellen Prozess zu sehen und können nach erfolgreichen emerge Vorgang ins System eingebracht bzw. auch rückgängig gemacht werden. Nur fehlt mir leider ein wenig die Zeit dazu oder gibt es schon ähnliche Ansätze?

----------

## musv

Das UnionFS über das ganze root legen, geht vermutlich nicht. Aber du kannst das über einzelne Verzeichnisse legen. Und für Dein Backup müsstest du halt über die ganzen "verdächtigen" Verzeichnisse (usr, bin, etc, lib, sbin, var?) ein unionfs legen. Ist etwas Aufwand, sollte aber machbar sein. 

Frage ist eher der Sinn der Sache. Angenommen ein größeres Update (>100 Pakete) schlägt beim letzten Paket fehl. Dann schmeißt du die ganzen vorher korrekt installierten Pakete weg, falls du das automatisiert erledigen willst. Weiterhin musst du die ganzen Änderungen nach Abschluss auf das Hauptsystem kopieren. Bei den vielen kleinen Dateien (inkl. Portage-Update) dürfte das so einige Zeit in Anspruch nehmen.

----------

## py-ro

Warum für diesen Zweck nicht Snapshots bemühen? 

Zum Beispiel LVM, EVMS, btrfs, zfs oder next3.

Bye

Py

----------

## 69719

Der Sinn der Sache besteht darin, dass Update rückgängig machen zu können, da ich schon ein paar mal das Problem hatte, dass sich die Kiste in Kombination mit dem starten des X-Server's verabschiedet hatte. Da mir dann zum beheben des Problems die Zeit fehlt, würde ich es einfach rückgängig machen und somit wieder alles am Laufen haben. Es nervt dann einfach, wenn man endlich mal zur Ruhe kommt und einen Film anschauen will und verdutzt feststellt, dass die Kiste ja nicht mehr startet durch das letzte Update.

Auf LVM oder EVMS möchte ich ungern aufbauen, btrfs ist noch experimentell, zfs nicht im kernel, next3 wird wohl auch nicht in frage kommen, da ich von ext3 auf ext4 gewechselt bin, um das überprüfen des Filesystems zu beschleunigen.

----------

## disi

Vielleicht ist das mit squashfs dann doch keine schlechte Idee?

Du kannst ja naechtlich oder eben spaetestens for jedem Update ein neues squashfs anlegen?

Dann einfach zwei Boot Optionen, das Live System mit den moeglichen Updates oder das vorher erstellte funktionierende squashfs (read only).

Dazu muss /boot auf einer Extra Partition sein. Ich nehme an, die Filme oder was auch immer sind auch auf einer extra Partition/Platte?

z.B. wie hier:

http://www.linuxquestions.org/questions/linux-general-1/use-squashfs-as-647320/

----------

## 69719

Naja, eine gute Idee ist es mit dem squashfs, allerdings könnte ich in der Zeit auch das ganze Backup zurück spielen.

Ich werde wohl auf btrfs setzen, allerdings habe ich in beim testen gemerkt, dass man zwar Snapshots erstellen kann, aber nicht löschen (sys-fs/btrfs-progs-0.19-r1, sys-kernel/gentoo-sources-2.6.34-r11).

Es erscheint immer die Meldung

```

ioctl:: Invalid argument

```

was nach meinen Vermutungen auf fehlende Implementierung schliesst oder Übergabe eines falschen Request's an das Filesystem.

Werde es später mal mit einem neueren Kernel versuchen.

----------

## LinuxTom

 *escor wrote:*   

> ... und können nach erfolgreichen emerge Vorgang ins System eingebracht bzw. auch rückgängig gemacht werden. ...

 

Hi escor,

ich habe es völlig anders gelöst und bin damit sehr zufrieden. Ich habe mir eine Chroot-Umgebung auf meinem Server aufgebaut, der in Deinem Beispiel ein Abbild Deiner Media-Kiste ist. In dieser Chroot-Umgebung emerge ich dann, stelle Pakete um usw.

```
FEATURES="buildpkg strict"
```

Wenn fertig, packages auf Media-Kiste kopieren und mit

```
FEATURES="getbinpkg strict"
```

emergen. Bis auf normale Konfigurationen (lafilefixer / revdev usw.) geht es dann sehr schnell. Grundlagen (gleiche make.conf auf Media-Kiste und chroot vorrausgesetzt).

----------

