reverses losetup

[weedy]

Hi, ich habe einen Dateiserver, der schon fast randvoll ist.

Jetzt will ich aber von ext4 auf nilfs2 wechseln, und zwar, ohne alles hin und herkopieren zu müssen, also nur nur mit einer Kopie.

Da man nilfs2 und ext4 "nach rechts" vergrössern und verkleinern kann, kam mir die Idee, dass, wenn ich ext4 am rechten rand verkleinere und dann rechts davon die nilfs2 -Partition anlege,
diese auch nach rechts vergrössern könnte, wenn die nilfs-Partition seitenverkehrt abgelegt ist; die abgelegte Partition wird dann nach links vergrössert und so treffen sich ext4 und nilfs an der Grenze, die nach links wandert.

So könnte ich nach und nach alles rüber bewegen.

Ich habe im Umfeld von losetup leider keine Möglichkeit gefunden, dies zu bewerkstelligen, gibt es da vieleicht eine andere Möglichkeit?

Gruß

[heisenberg]

Hört sich verdammt kompliziert an. Mein spontaner Gedanke wäre es, dass Du Dir es einfach machst. (Wald, Bäume, sehen, und so halt).

Ist das ein privates Datengrab, was irgendwo zu Hause rumsteht, oder ist es etwas, auf das auch andere Leute darauf zugreifen, so dass eine Downtime nicht so schön ist?

Bei letzterem kann ich - natürlich abhängig von den Rahmenbedinungen - auch noch einmal etwas auf eine Lösung mit LVM eingehen, so dass Du das Ganze ohne Downtime hinbekommst. Je nach Rahmenbedingungen braucht man dabei evtl. auch nur einen Kopiervorgang.

Ansonsten mal ein paar Infos, speziell die Ausgabe von lsblk. Alternativ df -h und fdisk -l.

Was Du genau vorhast, hab' ich auch noch nicht verstanden. Du möchtest das Dateisystem auf einer Platte, die fast voll ist, in ein anderes Dateisystem umwandeln? Oder möchtest Du da nicht auch den Speicher noch erweitern?

[r4pt0r]

Wenn er sowieso randvoll ist: neue Platte(n) dazu und das FS mit jeweils leeren Datenträgern migrieren. Ist schneller und wesentlich sicherer für deine Daten...

Für einen Fileserver der naturgemäß immer weiter wächst ist dann auch _dringend_ zumindest LVM unterm Dateisystem anzuraten - alternativ Dateisysteme wie btrfs oder zfs, die auch vor bitrot schützen.

[heisenberg]

ZFS würde ich wegen den RAM-Anforderungen nicht so schnell empfehlen( min. 8 GB ). Ausserdem ist es nicht ganz so flexibel wie LVM(Da kann man unter der Haube alles im laufenden Betrieb austauschen). Davon abgesehen ist ZFS natürlich extrem cool(TM) wegen Snapshots, Prüfsummen, transparenter Kompression und angenehmen CLI-Tools.

[catdog2]

ZFS würde ich wegen den RAM-Anforderungen nicht so schnell empfehlen( min. 8 GB ). Ausserdem ist es nicht ganz so flexibel wie LVM(Da kann man unter der Haube alles im laufenden Betrieb austauschen). Davon abgesehen ist ZFS natürlich extrem cool(TM) wegen Snapshots, Prüfsummen, transparenter Kompression und angenehmen CLI-Tools.

Meines Wissens betreffen diese RAM Bedürfnisse nur die Online Deduplication, ein Feature welches man nicht nutzen muss.

[heisenberg]

Meines Wissens betreffen diese RAM Bedürfnisse nur die Online Deduplication

In der FAQ steht 8-16 GB als Grundvoraussetzung, bei Ubuntu-Users ist von 4 GB die Rede - jeweils OHNE Deduplication. Dann gibt's da noch die Daumenregel zusätzlich 1 GB pro TB Daten. Da habe ich aber gerade keine Quelle für.

Siehe:
http://zfsonlinux.org/faq.html#BasicRequirements

Deduplizierung braucht jede Menge mehr! Deduplizierung ist ohne gründliches einlesen sowieso nicht zu empfehlen.

(Ich habe hier ZFS auf Linux im Einsatz).

[r4pt0r]

ZFS nimmt alles an RAM was es bekommen kann (->cache), rückt ihn aber auch sofort wieder raus wenn er anderweitig benötigt wird.
Ich hatte testweise ZFS auf einem NAS (qnap) mit nur 1GB RAM eingerichtet. Davon abgesehen dass man mit nem Atom mit so wenig RAM schon ewig braucht um die Kernelmodule zu bauen (fast 2 Tassen Kaffe...), ist das ganze wirklich ziemlich zäh. Lesend bekommt man (einzelner stream!) gerade so einen GBit link gesättigt, schreibend geht er aber schon nach wenigen 100MB in die Knie und fängt stark an zu "bursten".
Mit 4GB läuft das ganze mittlerweile ausreichend performant als backupsystem. Amanda sammelt jede nacht ca 350GB von insgesamt 6 Systemen ein, der 2xGBit bond ist dabei im schnitt zu 80-85% ausgelastet.
Für dynamischere arbeitslasten sollte man aber wirklich mindestens 8GB RAM vorhalten und/oder SSDs für ZIL und L2ARC mit in den pool aufnehmen. ZIL auf SSD beschleunigt random writes _extrem_ gut und mit großem L2ARC auf SSD fällt weniger RAM auch nicht mehr ganz so extrem auf, erst recht wenn die Daten anschließend nur über GBit LAN gepumpt werden.

Ansonsten profitiert ZFS durch sein "doppeltes caching" (most recent und most frequent) wohl mehr als andere Dateisysteme von mehr RAM - wie viel man wirklich "braucht" hängt von der Arbeitslast ab. Ein NAS das nur 1-2 Clients über einzelne GBit-Links versorgen muss kommt mit weniger RAM aus als ein Storagesystem das mehrere Virtualisierungsserver mit VM-Images versorgen muss...
Je größer der pool, desto mehr macht sich der verfügbare RAM auch beim scrubbing bemerkbar. Wenn das (bei ansonsten niedriger/ohne I/O-Last) nicht mehr mit nahezu maximaler r/w-Bandbreite der Platten/Controller läuft, sollte man über mehr RAM nachdenken, oder die CPU ist am Limit.

Der Pool in meinem privaten Storageserver besteht aktuell aus 8 Platten mit 7TB nutzbarem speicher + 2x 30GB SSD für ZIL und L2ARC. Ein Celeron G1840 mit 8GB RAM kommt damit prima zurecht inklusive LZ4-kompression für den gesamten pool.
Lesend via FC bekomme ich am Initiator ~360MB/s laut hdparm - das dürfte schon das Bandbreitenmaximum des pools sein, speziell da im moment noch 2 SATA2 HDDs mit dabei sind. Schreibrate bleibt konstant auf ca 300MB/s (mit 50GB testfile aus /dev/random getestet) und bricht nicht ein - was die HDDs nicht sofort packen schlucken da wohl die SSDs weg...

Deduplizierung ist wirklich nur für _extreme_ Datenmengen interessant, bei denen eine hohe Rate an identischen Blöcken anzunehmen ist. Ein VM-Storage mit sehr vielen Containern wäre solch ein Fall: Dort sind oft 50% der enthaltenen Daten identisch. Für das "normale Datengrab" stehen Aufwand und Kosten aber in keiner Relation zum nutzen - meistens sind größere Platten günstiger als mehr (ECC) RAM fur die deduplizierung, erst recht wenn man von SATA-Platten ausgeht (bei SAS kann man das schon eher mal durchrechnen).
Laut "FreeBSD Mastery: ZFS" (Michael W. Lucas, Allan Jude) kann man für 1TB speicherplatz mit bis zu 5GB RAM rechnen, das variiert sehr stark nach der Art (größe) der Daten. Die annähernde Berechnung über die Anzahl der blöcke wird dort ebenfalls beschrieben, so kann man es ggf für den eigenen Pool hochrechnen. Je block werden 320k RAM benötigt - hatte das mal für meinen Pool hochgerechnet und bin bei ca 24GB RAM rausgekommen...
Problem bei der deduplikation: Die Zuordnungstabelle *muss* im RAM vorgehalten werden, da _jeder_ Dateisystemzugriff zuerst über diese Tabelle laufen muss - liegt die Tabelle auf den langsamen Platten geht das System völlig in die Knie.

Kompression ist da schon deutlich interessanter und dank sehr effektivem und schnellem LZ4 praktisch "umsonst".

[smutbert]

Die Idee im Eingangspost finde ich lustig. Dazu passend habe ich hier ein dm-reverse gefunden
http://www.saout.de/misc/
http://www.saout.de/misc/dm-reverse.c

Wenn ich es recht verstehe macht das mittels device-mapper chunk-weise dasselbe, was dir bei losetup vorgeschwebt ist.


Ich fände auch Erfahrungen zu nilfs interessant - viel habe ich darüber ja bis jetzt nicht gefunden - entweder es gibt keine Probleme oder es verwendet niemand ☺

[weedy]

Die Idee im Eingangspost finde ich lustig. Dazu passend habe ich hier ein dm-reverse gefunden
http://www.saout.de/misc/
http://www.saout.de/misc/dm-reverse.c

Wenn ich es recht verstehe macht das mittels device-mapper chunk-weise dasselbe, was dir bei losetup vorgeschwebt ist.


Ich fände auch Erfahrungen zu nilfs interessant - viel habe ich darüber ja bis jetzt nicht gefunden - entweder es gibt keine Probleme oder es verwendet niemand ☺

Ich nutze seit 2 Monaten nilfs2 für tägliche und wöchentliche Backups. Vor und nach jedem Backup erzeuge ich einen Snapshot.

nilfs2 macht in Millisekundenbruchteilen sogenannte Checkpoints, die eine Zeitlang (siehe configfile) vorgehalten werden. Diese Checkpoints repraesentieren die jeweiligen für sich konsisten Dateisystem-Zustände. Man könnte folglich ein grösserwerdendes File nachträglich betrachten bzw alle Versionen eines sich ändernden Files. Dazu kann man Checkpoints in Snapshots umwandeln, welche sich danach readonly mounten lassen. Die Snapshots entstehen genausoschnell, man muss sie aber explizit erzeugen (mkcp - make a NILFS2 checkpoint (--snapshot)).

Ich habe in nilfs2 deswegen mehr vertrauen (als. zb in btrfs, mit dem ich in der Anfangszeit auch ein paar Probleme hatte), da die snapshotterei kein nice to have Feature ist, sondern offenbar die grundlegende Datenstruktur des gesamten Dateisystems darstellt.

Ich nehme für dieses Feature und das Versprechen, dass das Dateisystem selbst bei kaputten Platten (badblocks) eher auf Robustheit ausgelegt ist und auch dann immer noch konsistent sein soll, eine um die Hälfte geringere Schreibgeschwindigkeit als ext3/ext4 in kauf.

Bislang sind keine Probleme aufgetreten.

Ich hatte auch schon ältere Snapshots gemoutet, nie gab es ein Problem.

Interessant finde ich jedoch die obengenannte Möglichkeit, lvm einzusetzen. Ich könnte demnach die Partition bei Bedarf problemlos resizen und danach das Dateisystem. Ich schätze mal, dass die Möglichkeit, über lvm snapshots machen zu können, auch obsolete ist, wenn dies das Dateisystem selber kann, denn da llvm über das eingesetzte Dateisystem nichts weiss, kann dies nur über einen ineffizienten Weg erfolgen.

Beherrscht llvm auch Raid(n,m) bzw. Raid6-Fähigkeiten?

Oder muss man dazu llvm mit dm bzw. md *durcheinanderhau* kombinieren?

Gruß

[wanne]

Oder muss man dazu llvm mit dm bzw. md *durcheinanderhau* kombinieren?

Das könnte dann eben ZFS. (Und btrfs. Aber da ist das dann nicht stabiel. Und Erfahrungen mit nicht stabielen btrfs hast du ja schon genug gemacht.)

zb in btrfs, mit dem ich in der Anfangszeit auch ein paar Probleme hatte

Snapshots sind in btrfs auch wirklich inherent. Man darf echt keine Betas mehr raus bringen. Alle haben jetzt angst vor btrfs seit sie sich zu beta Zeiten mal die Finger verbrannt haben.

[heisenberg]

LVM kann nach direktem lesen jetzt nur Striping(RAID0). Für die höheren Raid-Level braucht es SW/HW-RAID.

...Das könnte dann eben ZFS...

Da würde ich wie hier schon geschrieben aufpassen(Siehe Raptors Beitrag) wegen der Systemanforderung.

Ich habe hier mehrere TB auf ZFS rumliegen. Vor knapp 2 Jahren war da noch regelmässig ein Problem mit einem Prozess(spl_kmem_cache oder so) der 100% CPU-Last eines Kernes gezogen hat und dann war das FS nicht mehr zugreifbar. Da hat es einen Reboot gebraucht - welcher dann regelmaessig prophylaktisch alle 2 Wochen durchgeführt wurde - und erst dann war es wieder da. Seit ca. 1 Jahr läuft das absolut problemlos. (Backupserver. Die Platten sind permanent unter Volllast).

Nachdem was ich hier so an Erfahrungen über btrfs lese, würde ich dem FS mittlerweile grundsätzlich schon trauen und im Heimbereich wegen der Resourcenanforderung gegenüber ZFS den Vorzug einräumen.

Und ich wiederhole es nochmal: LVM ist da flexibler als ZFS. Da kannst Du ne USB-Platte anstöpseln alles draufmigrieren anschliessend ein neues RAID erstellen und dann das ganze wieder in die andere Richtung zurück. Das braucht man nicht unbedingt, aber gut wenn man's weiss. ZFS kann natürlich auch Dateisysteme exportieren und importieren. Aber bei grösseren Datenmengen, will man das eigentlich lieber online machen um die Daten dauerhaft zugreifbar zu haben. Auch braucht Export / Import dann doppelten Speicherplatz bei der Migration.

[wanne]

Nachdem was ich hier so an Erfahrungen über btrfs lese, würde ich dem FS mittlerweile grundsätzlich schon trauen und im Heimbereich wegen der Resourcenanforderung gegenüber ZFS den Vorzug einräumen.

Sehe ich auch so. Aber eben nicht mehr als RAID0. RAID5 und RAID6 sind in btrfs wirklich ganz ganz neu. Da sollte man im Moment einen großen bogen drum machen.

Und ich wiederhole es nochmal: LVM ist da flexibler als ZFS. Da kannst Du ne USB-Platte anstöpseln alles draufmigrieren anschliessend ein neues RAID erstellen und dann das ganze wieder in die andere Richtung zurück. Das braucht man nicht unbedingt, aber gut wenn man's weiss. ZFS kann natürlich auch Dateisysteme exportieren und importieren. Aber bei grösseren Datenmengen, will man das eigentlich lieber online machen um die Daten dauerhaft zugreifbar zu haben. Auch braucht Export / Import dann doppelten Speicherplatz bei der Migration.

btrfs und ZFS können selbstverständlich im laufenden betrieb vergrößert werden und auf beliebige Platten ausgeweitet werden. (Lediglich bei RAID5 (bzw. RAID-Z) gibt es einige Einschränkungen. Da will ZFS dann beim Vergrößeren ein RAID6 draus machen.)

[r4pt0r]

LVM kann auch mirroring auf LV-ebene per "lvcreate -mN" wobei N die Anzahl der mirrors ist. Ist sogar relativ performant beim rebuild, da es auf blockebene gebaut wird, somit also nur belegte blöcke wiederhergestellt werden. Dafür leidet aber die I/O-Performance ggü. dm-raid.
Mit LVM lassen sich sogar ziemlich wilde setups mit mirroring auf der selben physischen Platte oder über sata- und usb-Platten bauen. Auch Kombinationen mit stripes sind machbar - z.B. ein 1TB mirror über 1x 1TB und 2x500G striped. Flexibel ist man mit LVM in dieser hinsicht wirklich, erst recht wenn mans mit dm-raid kombiniert - wieviel davon wirklich praktikabel/sinnvol ist sei dahingestellt. Das wuchert ziemlich schnell wenn man sich nicht beherrscht...


Zum migrieren/"backup" auf usb:
Ich hab kürzlich mal die split-funktion von ZFS ausprobiert - dabei wird von einem pool der aus mirror-vdevs bestehen jeweils ein device aus jedem mirror herausgelöst und diese als eigenständiger pool exportiert. Man hat innerhalb von sekundenbruchteilen einen kompletten pool konsistent "gesnapshottet" und kann diesen auf ein anderes system migrieren, damit irgendwas testen oder die Platten als coldbackup in den Schrank legen.

[heisenberg]

... btrfs und ZFS können selbstverständlich im laufenden betrieb vergrößert ...

Ja. Online-Vergrössern ist meist unproblematisch - und idR ist das genau das was man will: Mehr Platten bzw. grössere Platten.

Das meinte ich aber nicht. Ich meine wirklich, das man den kompletten Unterbau auswechseln kann - während das FS online ist - egal was da unten drunter ist. Vielleicht weil man aus einem RAID-5 dann doch ein RAID-10(Weil RAID-10 ja 2 x RAID-5 ist von der Geschwindigkeit! ) machen will.

Puh! Habe ich doch einen Use-Case für die Flexibilität von LVM gefunden.

[wanne]

Das meinte ich aber nicht. Ich meine wirklich, das man den kompletten Unterbau auswechseln kann - während das FS online ist - egal was da unten drunter ist. Vielleicht weil man aus einem RAID-5 dann doch ein RAID-10(Weil RAID-10 ja 2 x RAID-5 ist von der Geschwindigkeit! ) machen will.

Der mouve geht auch mit ZFS. Zugegebener weise aber nicht von RAID 10 nach RAID 5.
Aber da musst du ja eh md-raid zur Hilfe nehemen. Über das kannst du ZFS dann wieder genauso verschieben wie deinen LVM.

[heisenberg]

Der move geht auch mit ZFS. Zugegebenerweise aber nicht von RAID 10 nach RAID 5.
Aber da musst du ja eh md-raid zur Hilfe nehemen. Über das kannst du ZFS dann wieder genauso verschieben wie deinen LVM.

Das würde mich jetzt interessieren:

Wie kann das gehen, aus einem ZFS-Raidz auf ein Raid-10 im laufenden Betrieb zu migrieren? Und vor allem: Was soll Linux SW-RAID dabei helfen? ZFS kann selbst RAID-10, wieso sollte man sich den Schmerz antun wollen, auch noch Linux-SW-RAID und ZFS zu mischen?

[smutbert]

@Weedy
Vielen Dank für deine Ausführungen über nilfs2.

[wanne]

Zum ursprünglichen Vorhaben: Fesplatten Arbeiten auf Blöcken. Die kannst du gar nicht umdrehen. Würdet du jetzt einfach die Blöcke in umgekehrter Reihenfolge abspeichern hast du das Problem, dass Festplatten darauf ausgelegt immer große Teile hintereinander liegender Daten zu lesen (Die Differenz zwischen der zeit die ein anderer Block zum lesen braucht und der Zeit, die der Nächste block braucht nennt man seek time.) Typischerweise braucht das lesen der vorherigen Blocks um den Faktor 100 bis 1000 länger und ist für die Festplatte extrem belastend. Sprich deine Festplatte würde nicht nur langsam sondern auch ziemlich schnell kaputt gehen.
Die einzig Sinnvolle Methode ist wohl, möglichst viel von der vorderen Partition abzuzwacken und dann jedes mal in dem freien Bereich eine Partition zu erstellen, um die kannst du dann LVM/btrfs/zfs erweitern. Und auch hier gilt: Je größer die einzelnen Partitionen desto weniger belastend für die Platte.
Für die Methode wäre btw. eine Migration zu GPT sehr hilfreich. (Weitgehend beliebig viele beliebig große Partitionen.)