Gemeinsame Platte für FreeBSD und Linux

cryptosteve

cryptosteve

Ex-Steve`
Hi,

ich habe meinen Homeserver nun schweren Herzens abgebaut und mir für eine stromsparende Lösung entschieden. Nun habe ich eien 300GB-Platte übrig, die ich gerne als Datenspeicher für bestimmte Teile meines Homeverzeichnisses nutzen würde (vornehmlich Digitalkamerabilder, etc.).

Welches ist das geeignetste Filesystem dafür, ext2 oder FAT32? Wie sind Eure Erfahrungen?
 
FAT32 kannst du in meinen Augen vergessen. Das ist nichts für große Platten mit vielen Dateien. Außer du willst ständig defragmentiern :ugly:

Was du dir mal anschauen könntest: Debian hat bei der Installation ein Option, die es erlaubt auch auf *BSD-Dateisysteme zuzugreifen. Wie ausgereift das ganze ist, weiß ich auch nicht, da noch nie ausprobiert. :)

Vlt. hilft auch eine Anfrage in einem Linux-Forum ;)
 
@Steve`
Hi,

ich habe meinen Homeserver nun schweren Herzens abgebaut und mir für eine stromsparende Lösung entschieden. Nun habe ich eien 300GB-Platte übrig, die ich gerne als Datenspeicher für bestimmte Teile meines Homeverzeichnisses nutzen würde (vornehmlich Digitalkamerabilder, etc.).

Welches ist das geeignetste Filesystem dafür, ext2 oder FAT32? Wie sind Eure Erfahrungen?
Zum Vergrößern anklicken....
Wirf mal einen Blick auf den Thread BSD file systeme

Leider beschreibst Du nicht mit welchen Betriebssystemen Du darauf zugreifen willst.

Ich würde ext2 nehmen!
 
Nachdem FAT32 wohl ausscheidet, werde ich einfach mal unter Linux ein ext3 formatieren. Das kann man bekanntlich unter BSD als ext2 mounten. Ich werde mir mal angucken, wie stabil das ganze ist.
 
Also letztlich gabs dazu in de.comp.os.unix.misc (iirc wars da und nicht in dcub) eine Diskussion über Dateisysteme für Linux, BSD (und Solaris).

Fazit:
fat geht überall, will man aber nicht unbedingt.
ext2 geht für Linux und BSD
ufs geht für Linux wohl nur lesend.
 
Da es sich um Dateien meines Homeverzeichnisses handelt (nebst Datensammlungen wie Bilder, mp3s, etc.), ist schreibender Zugriff zwingend erforderlich.

Ich habe mich jetzt für ext3 entschieden. Das verwende ich unter Linux ohnehin und unter FreeBSD läßt es sich recht problemlos als ext2 mounten. Wenn ich das recht in Erinnerung habe, ist dieser Mißstand, dass ext2 beim FreeBSD-Runterfahren nicht sauber ausgehängt wurde, auch behoben.

Das Formatieren unter Linux hat mein System zwar eingefroren, aber ich habe das dann abgebrochen und unter FreeBSD neu probiert, dort klappte es einwandfrei. Sehr skuril. :)
 
Steve` schrieb:
Ich habe mich jetzt für ext3 entschieden. Das verwende ich unter Linux ohnehin und unter FreeBSD läßt es sich recht problemlos als ext2 mounten. Wenn ich das recht in Erinnerung habe, ist dieser Mißstand, dass ext2 beim FreeBSD-Runterfahren nicht sauber ausgehängt wurde, auch behoben.
Zum Vergrößern anklicken....
Könntest Du mir dies gegebenenfalls bestätigen?
Verwendest du 4.x, 5.x oder 6.x?

ciao
chaos
 
Für 6.x kann ich Dir das bestätigen, ich verwende hier 6.0-STABLE. Der Fix ist bereits bereit im Vorrelease-Stadium hinzugekommen und sollte auch in RELENG_5 enthalten sein.

Vergleiche bitte auch diesen google-Link
 
Ganz unschöner Nebeneffekt ist übrigens, dass die ext2/ext3-Partition heftigst geschrottet ist, wenn einem FreeBSD mal abkachelt (was hier durchaus häufiger mal vorkommt). Danach ist jedesmal ein ausführlicher Filecheck nötig, der hier gut und gerne 30 Minuten rennt.
 
Mountest du die Partitionen synchron oder asynchron? Unter Linux wird ext2/3 ja leider asychron gemounted, was nicht zuletzt zu hoher Geschwindigkeit, aber leider auch leicht zu schwerer Inkonsistenz der Metadaten bei Crash führt. Abhilfe schafft sowohl unter BSD (afaik dort sogar Standard) das synchrone mounten, macht das Dateisystem dann natürlich aber sehr langsam...
 
<Kram in weit zurückliegenden Erinnerungen>
Wenn ich das noch richtig in Erinnerung habe, ist doch ein ext3 nix anderes als ein ext2 mit Journal. Ein ext3 lässt sich als ext2 mounten, dann wird aber das Journal nicht weitergeschrieben, was beim nächsten Zugriff als ext3 gemerkt und entsprechend bemeckert wird.
Du solltest daher auf das Journaling verzichten und nur mit ext2 zugreifen.
</Kram in weit zurückliegenden Erinnerungen>

Stefan
 
OOZE schrieb:
Abhilfe schafft sowohl unter BSD (afaik dort sogar Standard) das synchrone mounten, macht das Dateisystem dann natürlich aber sehr langsam...
Zum Vergrößern anklicken....
Pfft, darüber habe ich mir noch gar keine Gedanken gemacht. Ich mounte die Platte stinknormal über die /etc/fstab mit normalen Einträgen ala "/dev/ad0s1 /mnt/data ext2fs default 0 0" oder sowas. Die Geschwindigkeit der Platte ist eher unerheblich, weil ich für den täglichen Gebrauch vor allem dotfiles und kleinere Gesamtkonfigurationen lade.
 
stefan schrieb:
Du solltest daher auf das Journaling verzichten und nur mit ext2 zugreifen.
Zum Vergrößern anklicken....
Unter BSD ist AFAIR nur der ext2-Zugriff möglich. Es findet also gar kein ext3-Zugriff statt. Wenn mir jetzt unter BSD die Kiste abraucht und ich möchte sofort wieder ins BSD starten, geht das schon nicht, weil das System schwerst beschädigt ist. Zwischendurch ist gar kein ext3-Zugriff beteiligt.

Jetzt frage ich mich nachträchlich aber auch, wie das bei einer am Router angeschlossenen USB-Platte ist, wenn man den Router einfach ausmacht?! Das müßte ja jedesmal schwere Konsequenzen nach sich ziehen?!
 
Mittlerweile habe ich übrigens rausgefunden, dass man die Platte wenigstens BSDseitig wieder mit 'fsck.ext3 /dev/$device' flott bekommt. Ist natürlich trotzdem supernervig.
 
Steve` schrieb:
Unter BSD ist AFAIR nur der ext2-Zugriff möglich. Es findet also gar kein ext3-Zugriff statt. Wenn mir jetzt unter BSD die Kiste abraucht und ich möchte sofort wieder ins BSD starten, geht das schon nicht, weil das System schwerst beschädigt ist. Zwischendurch ist gar kein ext3-Zugriff beteiligt.
Zum Vergrößern anklicken....

Das ist schon richtig, aber er (=stefan) meinte, Du sollst das auch unter der Pinguin-Tucke als ext2 und nicht als ext3 mounten.
 
@CAMISOLITE
Das ist schon richtig, aber er (=stefan) meinte, Du sollst das auch unter der Pinguin-Tucke als ext2 und nicht als ext3 mounten.
Zum Vergrößern anklicken....
Was hat er denn davon?

Bei ext2 müßte der File system check sowieso erfolgen, der wie geschildert ein halbe Stunde dauert!

http://www.redhat.com/support/wpapers/redhat/ext3

> Availability
> After an unclean system shutdown (unexpected power failure, system crash),
> each ext2 file system cannot be mounted until its consistency has been checked
> by the e2fsck program. The amount of time that the e2fsck program takes is
> determined primarily by the size of the file system, and for today's relatively
> large (many tens of gigabytes) file systems, this takes a long time. Also, the
> more files you have on the file system, the longer the consistency check takes.
> File systems that are several hundreds of gigabytes in size may take an hour or
> more to check. This severely limits availability.
 
tib schrieb:
@CAMISOLITE

Was hat er denn davon?
Zum Vergrößern anklicken....

Das steht doch schon hier.

tib schrieb:
Bei ext2 müßte der File system check sowieso erfolgen, der wie geschildert ein halbe Stunde dauert!
Zum Vergrößern anklicken....

Die halbe Stunde bezog sich doch auf FreeBSD ! Und unter FreeBSD nützt ihm ext3 nichts, wenn das System das Dateisystem nur als ext2 ansprechen kann. Deine Quelle bezieht sich auf die Linux-Seite.

Ich habe irgendwie das Gefühl, daß wir alle aneinander vorbeireden und die Diskussion bereits in diesem frühen Stadium aus dem Ruder läuft. Entweder habe ich hier etwas nicht mitbekommen oder einige Diskussionsteilnehmer haben entscheidene Details nicht richtig gelesen.
 
@CAMISOLITE
Das steht doch schon hier.
Zum Vergrößern anklicken....
Ich sehe hier keine explizite Aussage bzgl. des OS. Und Steve` hatte das auch nicht so empfunden

Die halbe Stunde bezog sich doch auf FreeBSD ! Und unter FreeBSD nützt ihm ext3 nichts, wenn das System das Dateisystem nur als ext2 ansprechen kann. Deine Quelle bezieht sich auf die Linux-Seite.
Zum Vergrößern anklicken....
Die Aussage der Quelle war, das auf Grund des fehlenden Journalings die Dauer des file system checks für eine ext2-Partition proportional zur Größe ist.
Und dies sollte unabhängig vom OS sein, das die Partition als ext2 mountet.

Außerdem hattest Du doch hier vorgeschlagen unter Linux als ext2 zu mounten!

Ich habe irgendwie das Gefühl, daß wir alle aneinander vorbeireden und die Diskussion bereits in diesem frühen Stadium aus dem Ruder läuft. Entweder habe ich hier etwas nicht mitbekommen
Zum Vergrößern anklicken....
deshalb werden wir ja drüber

oder einige Diskussionsteilnehmer haben entscheidene Details nicht richtig gelesen.
Zum Vergrößern anklicken....
Also, mich darfste nicht schlagen, bin promovierter Legastheniker :)
 
@Steve`
Was sagt eigentlich Linux dazu, wenn Du versuchst die von BSD geschredderte ext2-Partition als ext3 zu mounten?
 
@tib:

Es wird jetzt eigentlich noch chaotischer. Bitte lies richtig. :grumble:

Thema "halbe Stunde" kommt von Steve` und bezieht sich auf seine FreeBSD-Aktivitäten.

Thema "Linux-mount" kommt von stefan und sagt aus, daß das Journaling eines ext3-FS nach einem ext2-Zugriff (z.B. unter FreeBSD) evtl. aus dem Tritt geraten kann, was logischerweise erst dann offenkundig wird, wenn das FS wieder unter Linux gemountet wird.

So, wenn wir uns jetzt immer noch nicht verstehen, dann haue ich Dich ! :ugly:
 
CAMISOLITE schrieb:
Thema "Linux-mount" kommt von stefan und sagt aus, daß das Journaling eines ext3-FS nach einem ext2-Zugriff (z.B. unter FreeBSD) evtl. aus dem Tritt geraten kann, was logischerweise erst dann offenkundig wird, wenn das FS wieder unter Linux gemountet wird.
Zum Vergrößern anklicken....
Das stimmt leider nicht. Linux (mein Linux) bekommt es offensichtlich nicht mit, dass das System zwischenzeitlich als ext2 fortgeführt worden und und mounted die 'angeschredderte Partition' anstandslos. Ich weiß jetzt nicht, ob das ein Bug oder ein Feature ist, jedenfalls sollten ja Metadaten und Daten nicht in sync sein. Habe bloß nicht genug Linuxdetailwissen um zu sagen, ob das nicht ggf. im Hintergrund repariert wird.

Egal, halten wir fest: es gibt für mich - außer ggf. NFS - keinen geeigneten Weg, eine gemeinsame Datenbasis zu schaffen. Aber NFS von USB-Platten vom AsusRouter erscheint mir auch nicht so geeignet, weil ich den Router nachts hart ausschalte und damit auch die USB-Platten knallhart abklemmen würde. Die hätten vermutlich das gleiche Problem wie ein hart ausgeschaltetes Rechner-Filesystem.
 
Steve` schrieb:
Das stimmt leider nicht. Linux (mein Linux) bekommt es offensichtlich nicht mit,
Zum Vergrößern anklicken....

Nur mal so Interesse halber: Welches ist Dein Linux (Distri, Kernel, ...) ?

Ich kann auch nicht so recht nachvollziehen wieso Dein FreeBSD da so rumzickt. Ich hatte das mal in der Kombination NetBSD/Slackware erfolgreich in Betrieb. Hast Du schonmal andere FreeBSD-Versionen (5.4) oder gar andere BSDs probiert ? Oder ist es gar ein Hardwareproblem ? Poste doch mal Deine konkrete Plattenaufteilung. Es kann doch nicht sein, daß das jetzt an so einer Kleinigkeit scheitert.

Ansonsten kann ich nur sagen, daß bei Linux mit seinen ganzen Dateisystemen Vorsicht angebracht ist. Habe da schon nette Effekte gesehen. Linux ist halt auf Tempo optimiert (Stichwort: asynchron, s.o.) und geht im Zweifel Kompromisse ein, die ein BSD-Hardliner aus qualitativen Erwägungen nie und nimmer akzeptieren würde (vgl. auch Thema WINE und Speicherzugriffe).
 
Es handelt sich um ein x86_64er Gentoo Linux mit "Linux 2.6.13-gentoo-r5"er Kernel. Meine Festplattenaufteilung ist recht einfach,von FreeBSD-Sicht 200GB SATA (/dev/ad11) für Gentoo, 200GB SATA (/dev/ad12) für FreeBSD 6.0-STABLE, 200GB ATA (dev/ad0) für Daten.

Aber ich leide schon seit recht langer Zeit an FreeBSD-Krankheiten rum. So ist die Performance der Grafikkarte seit Versionen > 5.2.1 absolut miserabel, wenn hohe I/O-Last auf der Netzwerkkarte oder den Platten liegt. Oder das System friert regelmäßig bei der Verwendung von nvidia-driver + xawtv + overlay fest. Entsprechende mehrfache Anfragen hier und auf @current blieben leider unbeantwortet oder aber ohne Ergebnis. Hardwarefehler können ebenfalls ausgeschlossen werden, weil der Fehler bei komplettem Hardwarewechsel unverändert mitwandert.

Mittlerweile habe ich allerdings eingesehen, dass FreeBSD als Desktopsystem für meinen täglichen Einsatz schlicht nicht geeignet ist. Bevor ich auf FreeBSD 5.0BETA2 gewechselt bin, war ich übrigens bei NetBSD. Dort mangelte es damals allerdings an der Software.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben