Filesystem über mehrere Festplatten?

[Colttt]

ZFS im Vergleich dazu ist mir zu unflexibel.

Beispiel: Ich sah mal einen Server, der hatte nach und nach immer wieder RAID1-VDEVs drangepappt bekommen, immer wenn der Speicherplatz halt knapp geworden ist. Kann man dass jetzt auf der Ebene unterhalb des Dateisystems lösen? Nein. Geht nicht. Man kann nur VDEVs ersetzen, nicht aber löschen oder die Daten auf andere VDEVs hinzufügen. Man muss die Altlasten mitschleppen oder muß ein neues Dateisystem erstellen und die Daten kopieren. Bei LVM gibt's da den Befehl pvmove. Mit dem kann man das VDEV-Equivalent da ersetzen oder entfernen, wobei die Daten dann auf die übrigen Speichergeräte umgezogen werden.

Ob der Fall bei Dir auftreten wird, weiss ich nicht. Aber wenn ich über das Thema Speicherplatzerweiterung in diesem Fall nachdenke, dann scheint mir das auf eine ähnliche Konstellation hinauslaufen zu können. Btrfs scheint sich da ähnlich zu verhalten.

ich hoffe ich verstehe dich richtig, wenn ja dann ist das so nicht ganz korrekt: https://github.com/zfsonlinux/zfs/relea ... -0.8.0-rc1 dort kann man auch Geräte wieder entfernen.

[heisenberg]

Ich hoffe ich verstehe dich richtig, wenn ja dann ist das so nicht ganz korrekt: https://github.com/zfsonlinux/zfs/relea ... -0.8.0-rc1 dort kann man auch Geräte wieder entfernen.

Ja, das hört sich doch schon Mal gut an. Danke für's finden!

Leider steht hier noch: https://github.com/zfsonlinux/zfs/pull/6900

Note that when a device is removed, we do not verify the checksum of the
data that is copied. This makes the process much faster, but if it were
used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror. Therefore, mirror and raidz devices can
not be removed.

Und wer verwendet denn bitte ZFS ohne ein redundantes VDEV? Also war's leider doch noch nix damit. Aber wer weiß. Ich könnte mir vorstellen, daß dass auch noch entwickelt wird. Eine Basis für das Feature ist ja schon einmal da. In der Unterhaltung zu dem Pull-Request steht auch irgendwas von mirror-removal drin. Vielleicht ist das Feature tatsächlich schon in der Mache.

Nachtrag

Wie vermutet, scheint dass entfernen von beliebigen VDEVs wohl schon das klare Ziel zu sein. Siehe Aussage von "Alex Reece" hier:

https://www.delphix.com/blog/delphix-en ... ce-removal

Currently, device removal only works if all top level vdevs are plain disks / files.

[bluestar]

ich hoffe ich verstehe dich richtig, wenn ja dann ist das so nicht ganz korrekt: https://github.com/zfsonlinux/zfs/relea ... -0.8.0-rc1 dort kann man auch Geräte wieder entfernen.

Ich würde auch nicht unbedingt einen -RC1 eines Filesystems als Lösungsweg vorschlagen aber zusammen mit den Details von heisenberg bleibt doch zu sagen, dass sich im Bereich ZFS noch einiges tut und da ist die Chance sehr gut, das bis zu dem nächsten Punkt Platten voll die Features und der Komfort des Dateisystems noch gewachsen sind.

Ich war auch lange Zeit ein Anhänger von LVM, bin inzwischen aber echt ein großer Fan von ZFS und bedauere das die Entwicklung von BtRfs leider sehr schleppend vorangeht und das FS somit für mich noch nicht als Alternative zu ZFS zählen kann.

[wanne]

Das Thema ist eigentlich getrennt vom Dateisystem, auch wenn ZFS und btrfs das selbst auch können. Volume Management ist das zusammenfassen von mehreren Datenträgern und die Bereitstellung als eine Speichereinheit z. B. für ein Dateisystem. Ich finde Linux-LVM(Logical Volume Manager) sehr sinnvoll, weil es sehr viel Flexibilität bringt. Man kann beliebige Speichergeräte(RAID-Sets, Einzelplatten, USB-Sticks, Whatever) zusammenfassen und alles im laufenden Betrieb transparent unterhalb der Dateisystemebene austauschen. Ich verwende das wo immer mögilch.

ZFS im Vergleich dazu ist mir zu unflexibel.

Beispiel: Ich sah mal einen Server, der hatte nach und nach immer wieder RAID1-VDEVs drangepappt bekommen, immer wenn der Speicherplatz halt knapp geworden ist. Kann man dass jetzt auf der Ebene unterhalb des Dateisystems lösen? Nein. Geht nicht. Man kann nur VDEVs ersetzen, nicht aber löschen oder die Daten auf andere VDEVs hinzufügen. Man muss die Altlasten mitschleppen oder muß ein neues Dateisystem erstellen und die Daten kopieren. Bei LVM gibt's da den Befehl pvmove. Mit dem kann man das VDEV-Equivalent da ersetzen oder entfernen, wobei die Daten dann auf die übrigen Speichergeräte umgezogen werden.

Ob der Fall bei Dir auftreten wird, weiss ich nicht. Aber wenn ich über das Thema Speicherplatzerweiterung in diesem Fall nachdenke, dann scheint mir das auf eine ähnliche Konstellation hinauslaufen zu können. Btrfs scheint sich da ähnlich zu verhalten.

Ich mag LVM bzw. dm-raid ja auch lieber, weil ich es einfach übersichtlicher finde, wenn eine Schicht eine Aufgabe erledigt. Aber mangelnde Flexibilität sehe ich absolut gar nicht.

Code: Alles auswählen

btrfs device remove olddev

Das ist halt noch viel flexibler so als beispiel:
Ich merke: Oh mein SMART meint, meine Platte ist am abkratzen.
Also schmeiß ich erst mal Kompression an und remove das problematische device. Dann habe ich die neue Platte gekauft. Also schmeiße ich wieder ein rebalance rein, damit die auch mit genutzt wird. (Performance)...
Insbesondere bei völlig unteschiedlichen Devices. Die sind ja auch unterschiedlich schnell. Willst du nicht in einem LVM haben. Dann hast du auch die Probleme von zu großen RAIDS nicht. btrfs und zfs machen eben keine raids.

[Colttt]

btrfs ruf beruht wohl oder übel auf frühe versionen, ähnlich wie bei systemd wo frühere versionen viele bugs hatten und einiges nicht funktionierte.. btrfs ist mittlerweile recht stabil, bei raid5/6 muss man entsprechend aufpassen (siehe link weiter oben). was mich nach wie vor dort am meisten stört ist die relativ miese performance was aber überwiegend dem CoW feature zugeschoben werden kann, das soll bei ZFS ähnlich sein wenn man es nur mit einer platte betreibt.


Edit:
wie der Zufall es so will soll wohl im Kernel 4.20 ein paar Performanceverbesserungen bezüglich btrfs bekommen..
https://marc.info/?l=linux-btrfs&m=154025442601840&w=2