LVM Schreiblogik

[blubbersuelze]

Hallo zusammen,

ich habe da eine Frage zur Logik von LVM.

Das System ist wie folgt aufgebaut:
Eine Volumengruppe über folgende Festplatten:
sda 1TB
sdb 2TB
sdc 2TB
sdd 4TB

Auf dieser Volumengruppe liegt eine Logical Volume, welches die komplette Volumengruppe ausnutzt.

vgdisplay --verbose listet die physical Volumes auch in der Reihenfolge
sda
sdb
sdc
sdd
auf ...

Nun zu meiner Frage ...

LVM schreibt als erstes physikalisch auf sdd, aber sollte LVM nicht als erstes sda befüllen,
da es auch in der Volumengruppe als erstes aufgelistet wird?

Hat LVM da eine spezielle Logik um zuerst allen freien Platz auf dem größten physical Volume zu füllen,
oder beginnt LVM hinten und füllt nach vorne auf?

danke für die Info

mfg.
blubbersuelze :p

[blubbersuelze]

ein kleiner Nachtrag:

Nachdem sdd komplett vollgeschrieben zu sein scheint, schreibt LVM auf sdb weiter.

Dies spricht für für meine erste Vermutung:

zuerst allen freien Platz auf dem größten physical Volume zu füllen

weiß da jemand etwas genaueres und kann das bestätigen oder dementieren und mir Details dazu geben wie die Schreiblogik von LVM ist?

[BetterWorld]

You've got the source.
Read it.

Und ich glaube ganz und gar nicht, dass das in Reihenfolge nach Grösse sortiert läuft.

Warum willst du das wissen?

[blubbersuelze]

You've got the source.
Read it.
unpassender geht es wohl garnicht!
Außerdem habe ich keine Lust zehntausende Zeilen von Sourcecode auseinander zu nehmen um dort das zu finden was ich suche.
Des weiteren muss da ja irgend eine Logik vorhanden sein, wie auch immer diese aussieht.
Und es könnte ja sein das genau diese Frage jemand beantworten kann.


Und ich glaube ganz und gar nicht, dass das in Reihenfolge nach Grösse sortiert läuft.

Das heißt das du es selbst nicht weißt, außerdem spricht meine momentane Beobachtung exakt dieser Vermutung.

Warum ich das wissen will.
Ich will das wissen um die Vorgehensweise bei Schreibprozessen von LVM zu verstehen.
Wird ja wohl kein Geheimnis sein.

[fork]

Ich meine, dass ich das mal gelesen habe, dass LVM die PV nacheinander vollschreibt. Lesen des source-Codes wird wahrscheinlich nicht unbedingt notwendig sein. Wenn Du's wirklich wissen willst, kann ich nur empfehlen, die vorhandene LVM-Doku intensiv durchzuarbeiten.

Ich stelle mir schon aber auch die Frage, wieso Du das wissen willst? Geht es um Performance? Falls ja, ist reines LVM nicht geeignet. RAID0 wäre besser. Bzgl. der Datensicherheit wäre beides nicht zu empfehlen, auch wenn Du mit LVM nach dem augenscheinlichen Schreibmechanismus bessere Chancen bei einer Datenwiederherstellung hast.

[blubbersuelze]

Dann werde ich mir mal die Doku zu gemüte führen müssen, danke.

Es interessiert mich einfach, da LVM bei meinen Festplatten nicht sda -> sdb -> sdc -> sdd vollschreibt.

[BetterWorld]

ich bin mir ziemlich sicher, dass das hier niemand einfach so weiß.
Man wird die Sourcen lesen müssen.

In der Doku dazu wirst du da nicht fündig.
Die hab ich gelesen.

Erstmal kann man ein PV aus einer kompletten Platte erzeugen.
Oder aus einer oder mehreren Partitionen.
Was dann letztlich in einer PhysicalVolumeGroup drin hängt, hängt davon ab, was Root da halt drin haben will.

Tja, und dann definieren wir ein LogicalVolume.
Da werden 4MB große Chunks aus der VolumeGroup zusammengefügt, um einen dir zusammenhängend erscheinenden Speicherplatz zu bilden. Das wird dann formatiert.

Wenn letztlich der tatsächliche Speicherplatz vogelwild über mehrere Platten und kreuz und quer über Partitionen oder auch nicht verteilt ist,
macht es schon aus Performancegründen überhaupt keinen Sinn eine dem User einleuchtende Schreibreihenfolge einhalten zu wollen.
Selbst bei einer normalen Harddisk mit normalen Partitionierungsschema ist das nicht der Fall.
Auch da erscheint nur dem User die Schreibreihenfolge sequentiell (weil LBA), auf der Platte können diese einzelnen Sektoren dennoch wild durcheinandergewürfelt liegen. Das macht die in Platten integrierte Elektronik ohne Zugriffsmöglichkeit des Betriebssystems ganz alleine.
(Man bräuchte die "Spezialsoftware" der Hersteller UND die GENAUEN Plattendaten (die kein Mensch außerhalb der Hersteller zu sehen bekommt), um feststellen zu können, wo nun was wirklich liegt).

Die bereits einige Male abstrahierte Reihenfolge der LVM Chunks wird sich also -wie bei Linux üblich- nicht an die schlichte Usermentalitätsreihenfolge halten, sondern wie auch immer optimiert nur ein logisches Abbild zeigen.
Die tatsächlich zugrunde liegenden Sachverhalte sind -ebenfalls wie immer- wesentlich komplizierter.

Du kannst ja mal versuchen deine VolumeGroups aus vielen kleinen Teilstücken aber schön verteilt über viele Platten zusammenzusetzen.
Aus denen baust du dir dann kleine LVs.
Die schreibst du mit Dateien, die größer als 4MB sind (falls du den Standard nicht geändert hast), voll. Eine mit "A"s als Inhalt.


# schreibt 16MB eines Zeichens
file=/irgend/wo/unsinnigeAs
char=A

printf "%$(printf "%d" 0xFFFFFF)s" $char | tr " " $char > $file
Eine weitere mit Bs und anderem Namen.
Und eine mit Cs usw.

Dann kannst du mal auf der Platte, in den LVMs gucken, wo nun wirklich was steht.
Einfach mit dd alle z.B. 3,5 MB ein paar Sektoren anzeigen lassen.

Und dann, wenn jetzt schon die kleinen LVs voll sind, erweiterst du die einfach, indem du weitere Chunks hinzufügst.
Wo kommen die jetzt her?
Von noch freiem Platz in VolumeGroups oder neuen VolumeGroups.
Die Dinge beginnen jetzt auch dem User mächtig verwirrt zu erscheinen.

Langsam solltest du merken, dass einfach die Frage nicht passt.
Und eine nicht passende Antwort auf einen nicht passende Frage passt halt mal.
Minus mal Minus is ja Plus.

Du magst bei einer neuen "frisch&sequentiell eingerichteten" LVM Partitionierung wohl leicht zu einem solchen Trugschluß gelangen.
Dem LVM ist das egal.

Die Antwort, dass du dafür die Sourcen wirst bemühen müssen,
dürfte jetzt einsehbar sein.
In der normalen Doku findest du dazu sehr wahrscheinlich nichts.

[florian0285]

Hier ist das etwas beschrieben:

http://www.slashroot.in/advanced-guide-lvm-logical-volume-management-linux-part-1

So beim Überfliegen bestätigt sich deine Beobachtung in der Default Konfiguration anscheinend. Der Rest sah jetzt nach RAID verhalten aus. Habs aber nur überflogen.

Eine Alternative zum Sourcecode wühlen dürfte ne Mail an die Entwickler sein. Geht bestimmt schneller [emoji6]

[fork]

Das hier...

https://www.thomas-krenn.com/de/wiki/LVM_Grundlagen

führt u. a. hierzu...

https://wiki.gentoo.org/wiki/Device-mapper

und das widerrum hier hin...

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/linear.txt?id=refs/tags/v4.7

Und das sieht für mich erst Mal so aus, als ob ein Standard-LVM-Linear-Volume stupide von vorne bis hinten, oder umgedreht aufgefüllt wird, ganz egal wie lausig dass von der Performance her ist. Wenn Performance wichtig ist, dann ist linear nicht das richtige. (Oder es ist ein RAID drunter, dann wird das mit der Performance auf einer anderen Ebene geregelt und man kann getrost linear verwenden).

Zum Thema interne Adressierung in der Platte

Wenn ich meine VG mit 1000 PE(Physical Extent) auf Platte1 und 1000 PE auf Platte2 erstelle(also insgesamt 2000 LE(Logical Extent, Grösse entspricht PE)), dann ist bei der Zählweise, die bei der 1. Platte beginnt LE #1001 nicht mehr auf Platte 1, ganz egal, wie die Platte intern die Adressen durcheinander schüttelt - was ja total transparent abläuft.

Diese LVM-Doku scheint auch recht brauchbar: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/LVM_components.html

hth

[BetterWorld]

Und das sieht für mich erst Mal so aus, als ob ein Standard-LVM-Linear-Volume stupide von vorne bis hinten, oder umgedreht aufgefüllt wird, ganz egal wie lausig dass von der Performance her ist. Wenn Performance wichtig ist, dann ist linear nicht das richtige. (Oder es ist ein RAID drunter, dann wird das mit der Performance auf einer anderen Ebene geregelt und man kann getrost linear verwenden)."Sieht so aus". Mehr aber auch nicht.


Wenn ich meine VG mit 1000 PE(Physical Extent) auf Platte1 und 1000 PE auf Platte2 erstelle(also insgesamt 2000 LE(Logical Extent, Grösse entspricht PE)), dann ist bei der Zählweise, die bei der 1. Platte beginnt LE #1001 nicht mehr auf Platte 1, ganz egal, wie die Platte intern die Adressen durcheinander schüttelt - was ja total transparent abläuft.Nein. Das muss nicht sein.
Es hängt wirklich -lässt man mal Stripping außer Acht- davon ab, WIE und in WELCHER Reihenfolge man das LV mit den PEs zusammengestrickt hat.

Diese Annahmen sind wirklich nur dann wahr, wenn man den einfachst möglichen Fall nimmt und dann jeweils "brutal alles" in ein LV würgt.
In vielen anderen Fällen stimmt das einfach nicht.

In der Praxis wird man -früher oder später- nur mit zusammengestückelten LVs hantieren.
Da gilt das alles nicht.
Es ist ja (unter anderem) Sinn und Zweck von LVM, dass man seinen Speicher möglichst ohne umount und Gedöns erweitern und weitere Platten einbinden kann.

[florian0285]

Wenn ich das so lese geht das leicht am Anwendungsfall des TE`s vorbei. Für sein 0815 linear schreibendes LV liest sich das aus der Doku ziemlich einleuchtend heraus, dass physisch linear geschrieben wird. Ungeachtet dessen ob es dann zur Fragmentierung der Daten kommt oder ob gestückelte LV's in ferner Zukunft in seinen Fall mit einfließen.
Die Antwort ist demnach "Ja" es gibt eine Logik, die per Default linear auf die Platten schreibt. Betterworld seine Faktoren spielen dann im laufenden Betrieb erst eine Rolle, wenn das LV verändert wird bzw. auch dann, wenn Daten fragmentiert sind.

Die Frage ist relativ einfach gestellt, daher sollte auch relativ einfach geantwortet werden. Keep it simple oder?

Für tiefgehendere Informationen gibt es die Links, Doku, Source Code und den Kontakt zu den Entwicklern.

[BetterWorld]

Wenn ich das so lese geht das leicht am Anwendungsfall des TE`s vorbei. Für sein 0815 linear schreibendes LV liest sich das aus der Doku ziemlich einleuchtend heraus, dass physisch linear geschrieben wird.Nein, die Doku sagt dazu genau nichts. Aus gutem Grund.
Das sind Interpretationen. Mehr nicht.


Ungeachtet dessen ob es dann zur Fragmentierung der Daten kommt oder ob gestückelte LV's in ferner Zukunft in seinen Fall mit einfließen.
Die Antwort ist demnach "Ja" es gibt eine Logik, die per Default linear auf die Platten schreibt.Nein.
Das ist eine Behauptung, die durch keine Doku gedeckt wird.
Es erscheint im einfachen Fall so. Mehr nicht.


Betterworld seine Faktoren spielen dann im laufenden Betrieb erst eine Rolle, wenn das LV verändert wird bzw. auch dann, wenn Daten fragmentiert sind.
Die Frage ist relativ einfach gestellt, daher sollte auch relativ einfach geantwortet werden. Keep it simple oder?Noch mal Einspruch.
Im Netz gibt es schon viel zu viel gefährliches Halbwissen.
Mit solchen Vermutungen werden wieder scheinbare Fakten hinzugefügt.
Wenn man es nicht weiß, sollte man einfach darüber schweigen, statt Vermutungen zu Fakten zu erheben.

Es ist außerdem implizit falsch: Wenn ich ein LV so zusammensetzen kann, dass es eben "nicht scheinbar linear" schreibt -und ich kann das-, dann ist es einfach falsch.
Punkt.

Das Argument "keep it simple" hier zu missbrauchen legitimiert dann auch die Absage an Newtonsche Physik, denn ganz offensichtlich war ja der Baum sauer auf Newton. Gravitation gibt es nicht.


Für tiefgehendere Informationen gibt es die Links, Doku, Source Code und den Kontakt zu den Entwicklern.Ich sagte ja von Anfang an: Das erschließt sich erst im Quelltext.

[florian0285]

Ich dreh den Spieß mal um und behaupte, dass deine Behauptung durch nichts gedeckt wird.

Nimm den Link zur Redhat Doku von fork und übersetze mir bitte den Punkt 4.3.2 besonders den Part mit contiguous und den Abschnitt davor zur Reihenfolge der LVM Allocation. Würde mich interessiern ob ich da jetzt zu viel interpretiere?

Nachtrag: Allein aus Performancegründen ist doch ein willkürlicher random-write-ping-pong sinnfrei.

[BetterWorld]

Dir ist schon klar, dass das Allozieren von Physical Extends für ein LV etwas ganz anderes, als die Schreibreihenfolge in einem LV?
Hast du schon mal mit LVM gearbeitet?
Ich habe übrigens auch nie von random write ping pong geschrieben.


Dem Threadersteller habe ich meine Meinung dazu geschrieben.
Und mir dir debattiere ich nicht dein Mistverständnis irgendwelcher Dokus.
Du redest nicht von der Sache.
Mir ist schon klar, was du möchtest.
Mir ist das aber zu kindisch.

[florian0285]

Ist mir klar. Wen man aber die Doku gänzlich liest ergibt sich der Zusammenhang mit der kurz gesagt "in order" Reihenfolge in der "linear" Konfig. Also es steht für mich schwarz auf weiß da und ist auch logisch. Deine Einwände finde ich ebenfalls logisch... aber nur im laufenden Betrieb usw. wie ich bereits erwähnt habe.

Ich will hier auf garnichts raus... sondern dem TE nur eine vernünftige Antwort geben.
Doku lesen und darüber zu diskutieren finde ich jetzt nicht kindisch. Immerhin kann man diese auch falsch verstehen. Ich lass mich ja auch gern eines besseren belehren, aber nicht durch reine Behauptungen [emoji6]

[fork]

@blubbersülze:

... weil ich gerade damit zu tun habe. Probier Doch mal:


vgcfgbackup -f ausgabedatei.txt

Da sind doch Informationen drin, die Dich vielleicht interessieren dürften.