Re: Gedankenspiel neuer Server - Filesystem
Hi Dietrich,
Am Mittwoch, 3. Juli 2013, 14:30:15 schrieb Dietrich Clauss:
> Marc Haber <mh+debian-user-german@zugschlus.de> wrote:
> > On Tue, 2 Jul 2013 17:07:36 +0200, Dietrich Clauss
>
> > <dc2@clauss.dyndns.org> wrote:
> [btrfs-RAID]
>
> >>Das RAID würde ich noch nicht einsetzen und erstmal die weitere
> >>Entwicklung abwarten.
> >>
> > Warum nicht?
>
> Weil z.B. 'df' noch nicht richtig funktioniert. Wenn man dann hier[1]
df funktioniert wunderbar.
Es läßt sich über die konkrete Implementierung streiten und ich bin der
Meinung, lieber den konservativsten Schätzwert zu liefern anstatt bei RAID-1
die rohe Kapazität zu liefern. Es gibt jedoch auch gute Gründe, es genau so zu
machen, wie BTRFS das gerade handhabt.
> liest:
> | If everything is RAID-1 (or RAID-0, or in general all the same RAID
> | level), then yes, we could give a sane and consistent value from df.
> | However, we have plans to allow per-subvolume and per-file RAID levels.
> | In this case, it becomes impossible to give a sensible estimate as to
> | how much space there is left.
>
> Per-file RAID levels. Wie soll das aussehen? Wenn ich dann in einem
> RAID-1 eine Festplatte tausche, verschwinden dann auf einmal Dateien?
> Das scheint mir vom Gesamtkonzept her noch ziemlich unausgegoren zu
> sein. Wenn ich die benötigten Funktionen auch mit ausgereiftem Zeugs
> bekomme, hier also ext-irgendwas und raid-1, dann gebe ich doch dem den
> Vorzug und warte ab, wohin die Entwicklung geht.
Ich finde das durchaus durchdacht. Ein Subvolume mit RAID-1, ein Subvolume mit
RAID-0 für temporäre Daten, ein Subvolume mit RAID-6, wers mag.
Und BTRFS RAID hat eine Reihe von Vorteilen:
1) Sofort nach mkfs.btrfs verfügbar ohne Initialisierung.
2) Bei Redundanz kann BTRFS Defekte, also Blöcke mit falschen Prüfsummen
reparieren.
3) Eben oben erwähnte Flexibilität.
Ich hab ein BTRFS RAID 1 schon seit Jahren am Laufen, ohne jegliche Probleme.
> >>oder aber das btrfs-RAID wird so umgebaut, daß es auch mit anderen
> >>Dateisystemen funktioniert.
> >>
> > Wie soll das gehen?
>
> Indem man von den FS-Interna sinnvoll abstrahiert und dem MD-Gerät die
> Informationen liefert, die es wirklich wissen muß.
>
> Eine SSD möchte auch gern wissen, welche Blöcke ungenutzt sind. Dafür
> wurde der TRIM-Befehl erfunden. Niemand kommt hier auf die eigenartige
> Idee, das Wear-Leveling müsse deshalb von den Dateisystemen erledigt
> werden.
An dieser Diskussion beteilige ich mich nicht, da ich das sinnlos finde.
Kernel-Entwickler führten diese Diskussion schon etliche Male. Unter anderem
auch bei Reiser 4.
Es steht Dir natürlich frei, zu versuchen, auf MD-Basis eine gleichartige
Funktionalität bereit zu stellen. Ich denke, das wird auf Blockgeräte-Basis an
seine Grenzen stoßen, wobei sich diese Prüfsummen-Geschichte schon einbauen
ließe…
Die ZFS-Entwickler haben nicht ohne Grund genau die gleiche Entscheidung
getroffen.
Und ich nehme einfach das BTRFS das da ist, solange ich mich nicht entscheide,
selbst etwas zu entwickeln. Und nutze die Vorteile. Layering Violation hin,
Layering Violation her.
Kleine Ankündigung: Ich habe nicht vor, diese Diskussion nach dieser Äußerung
meines Standpunktes noch weiter zu führen. Möge ein jeder entscheiden, wie er
möchte.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: