LVM z 1 partycji - czy warto?
jeo stancey
dyskach wirtualno-logicznych LVM gdzie "pula" (VG) woluminów
fizycznych (PV) to tylko JEDNA jedyna partycja? (jeszcze ew. osobna
fizyczna partycja na /boot, '/' z esencjalnymi katalogami - ale to
osobny temat)
1.) Jak taka abstrakcyjna warstwa nad dyskiem wpływa na transfer
dyskowy?
2.) Jak wpływa na użycie pamięci i CPU?
3.) Gdzie fizycznie te dane będą lądować na dysku ze względu z którego
LV
pochodzą? Czy są przestrzennie totalnie wymieszane czy jakoś
posegregowane? (Jeśli wymieszane to przynajmniej głowica nie musi tak
latać...)
Michoo
> Proszę o opinie czy warto stawiać Linuksa na domowej workstation na
> dyskach wirtualno-logicznych LVM gdzie "pula" (VG) woluminów
> fizycznych (PV) to tylko JEDNA jedyna partycja? (jeszcze ew. osobna
> fizyczna partycja na /boot, '/' z esencjalnymi katalogami - ale to
> osobny temat)
przydziela partycje wg potrzeby.
>
> 1.) Jak taka abstrakcyjna warstwa nad dyskiem wpływa na transfer
> dyskowy?
Niezauważalnie. Chyba, że się postarasz żeby zepsuć. (Pojedyncze
przemieszane bloki.)
>
> 2.) Jak wpływa na użycie pamięci i CPU?
j.w.
>
> 3.) Gdzie fizycznie te dane będą lądować na dysku ze względu z którego
> LV
> pochodzą? Czy są przestrzennie totalnie wymieszane czy jakoś
> posegregowane? (Jeśli wymieszane to przynajmniej głowica nie musi tak
> latać...)
Możesz znaleźć informacje jak dokładnie działa LVM. W skrócie: masz
minimalny rozmiar bloku - volumen składa się z określonej liczby takich
bloków. System dba o to, żeby o ile to możliwe te bloki stanowiły ciągłe
obszary.
--
Pozdrawiam
Michoo
Kajetan Staszkiewicz
> Proszę o opinie czy warto stawiać Linuksa na domowej workstation na
> dyskach wirtualno-logicznych LVM gdzie "pula" (VG) woluminów
> fizycznych (PV) to tylko JEDNA jedyna partycja? (jeszcze ew. osobna
> fizyczna partycja na /boot, '/' z esencjalnymi katalogami - ale to
> osobny temat)
Warto. Masz wtedy możliwość łatwego tworzenia osobnych filesystemów różnej
wielkości pod różne zastosowania i możliwość tworzenia snapshotów.
Szczególnie snapshoty są fajne i przydatne.
> 1.) Jak taka abstrakcyjna warstwa nad dyskiem wpływa na transfer
> dyskowy?
>
> 2.) Jak wpływa na użycie pamięci i CPU?
Ciężko powiedzieć, nigdy nie przeprowadzałem takich pomiarów. Na pewno wpływ
jest niezerowy, ale raczej marginalny... Zarówno RHEL (i CentOS) jak i
OpenSUSE na dzień dobry proponują układ partycji z użyciem LVM.
--
| pozdrawiam / greetings | powered by SUSE, CentOS and FreeBSD |
| Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net |
| Vegeta | www: http://vegeta.tuxpowered.net |
`------------------------^--------------------------------------'
thc_flow
Ja osobiście preferuję LVM, pomijając kwestie bezpieczeństwa, takie jak
w.w. snapshoty, łatwiej (i szybciej) zmienić rozmiar partycji.
Problematyczne staje się to w przypadku używania obok Windowsa (mało
sterowników umożliwia odczyt z LVM), a także niektóre LiveCD nie mają
obsługi LVM.
Dane są posegregowane, jest to "partycja w partycji", która ma stały
rozmiar, przypomina to pod tym względem BSD'owe rozwiązanie.
Obciążenia systemu jakoś nie zauważyłem, a mam sprzęt dość słaby (P2
533MHz i 384MB RAM), więc nie powinno być problemu i z tym.
jeo stancey
> > 1.) Jak taka abstrakcyjna warstwa nad dyskiem wpływa na transfer
> > dyskowy?
>
> Niezauważalnie. Chyba, że się postarasz żeby zepsuć. (Pojedyncze
> przemieszane bloki.)
Podobno można postawić LVs jako contiguous lub non-contiguous. I w tym
drugim przypadku bloki będą przemieszane, prawda? Czy nie sądzisz, że
czasem to może być pożyteczne? Poszczególne katalogi linuksa leżą na
osobnych LV i są one używane jednocześnie. Tak więc wówczas chyba
dobrze by było żeby te dane były fizycznie jak najbliżej siebie?
Inaczej to mamy taki schemat:
jakiś wielki LV a w nim trochę wykorzystane na początku a potem już
tylko pusta przestrzeń,
potem kolejny podobnie tyko trochę na początku zapełniony itd.
i głowica musi czytać jednocześnie z obu i przeskakiwać ponad tą pustą
przestrzenią...
jeo stancey
wrote:
> Warto. Masz wtedy możliwość łatwego tworzenia osobnych filesystemów różnej
> wielkości pod różne zastosowania
ale w czym to jest lepsze od zrobienia wielu partycji fizycznych w tym
takich tradycynych logicznych na EXTENDED?
Pewnie powiesz, że chodzi o łatwość w poźnieszej modyfikacji wielkości
tych LV.
Ale przecież jest sporo dobrych i pewnych narzędzi do modyfikowania
partycji fizycznych, np. PartitionMagic itp.
Tak więc jakie są inne zalety LVM które dają przewagę takiemu
rozwiązaniu?
> i możliwość tworzenia snapshotów.
> Szczególnie snapshoty są fajne i przydatne.
Przydatne - do czego? Proszę podaj konkretne sytuacje i zastosowania.
Dziękuję.
Kajetan Staszkiewicz
> On 6 Lis, 11:49, Kajetan Staszkiewicz <vegetaBezSp...@tuxpowered.net>
> wrote:
>> Warto. Masz wtedy możliwość łatwego tworzenia osobnych filesystemów
>> różnej wielkości pod różne zastosowania
>
> ale w czym to jest lepsze od zrobienia wielu partycji fizycznych w tym
> takich tradycynych logicznych na EXTENDED?
Zwykła partycja zajmuje obszar dysku bez przerw w środku. Nie ma możliwości
fragmentacji dysku, więc nie możesz tworzyć nowych partycji całkiem
dowolnie. Czy tablica partycji (nawet rozszerzonych) nie jest ograniczona do
4 partycji?
> Pewnie powiesz, że chodzi o łatwość w poźnieszej modyfikacji wielkości
> tych LV.
Tak.
> Ale przecież jest sporo dobrych i pewnych narzędzi do modyfikowania
> partycji fizycznych, np. PartitionMagic itp.
O ile obsługują używany przez ciebie system plików.
> Tak więc jakie są inne zalety LVM które dają przewagę takiemu
> rozwiązaniu?
>
>> i możliwość tworzenia snapshotów.
>> Szczególnie snapshoty są fajne i przydatne.
>
> Przydatne - do czego? Proszę podaj konkretne sytuacje i zastosowania.
Przykład z życia wzięty - aktualizacja systemy operacyjnego routera/centrali
voip w biurze na drugim końcu świata (a przynajmniej Europy). Przed
aktualizacją systemu robię snapshot, ustawiam boot loader, by domyślnie
bootował system z tego snapshotu ale by najpierw spróbował raz odpalić z
właściwej partycji. Jeśli coś się nie powiedzie, wystarczy zrestartować
serwer by wstał stary system. Może się on nawet zrestartować sam jeśli
kernel spanikuje albo z pomocą crona jeśli wstanie np. bez obsługi sieci i
nie zaloguję się.
jeo stancey
wrote:
> > ale w czym to jest lepsze od zrobienia wielu partycji fizycznych w tym
> > takich tradycynych logicznych na EXTENDED?
>
> Zwykła partycja zajmuje obszar dysku bez przerw w środku. Nie ma możliwości
> fragmentacji dysku, więc nie możesz tworzyć nowych partycji całkiem
> dowolnie.
LV jest więc trochę tak jak plik w systemie plików? Początkowo jak w
świeżej VG robimy kilka woluminów logicznych LVs to są one ciągłe i
bez przerw jeden za drugim, ale potem jak coś pomodyfukujemy, np.
zmniejszymy dotychczasowe i dodamy kolejne LV - to owe LVs mogą być w
częsciach rozrzucone po różnych miejcach?
I tak jak dla plików w fs taka fragmentacja chyba nie jest najlepsza
dla szybkości transferu danych z dysku?
> Czy tablica partycji (nawet rozszerzonych) nie jest ograniczona do
> 4 partycji?
Owszem, możesz mieć 3 partycje podstawowe + 1 EXTENED na której mogą
być dalsze mnóstwo partycji-dysków_logicznych.
> > Pewnie powiesz, że chodzi o łatwość w poźnieszej modyfikacji wielkości
> > tych LV.
>
> Tak.
>
> > Ale przecież jest sporo dobrych i pewnych narzędzi do modyfikowania
> > partycji fizycznych, np. PartitionMagic itp.
>
> O ile obsługują używany przez ciebie system plików.
Jednak jeśli obsługują to czy warto uciekać się do LVM?
BTW. a jak się zachowują LVs postawione jako non-contiguous? Są jakoś
bardziej dynamiczne w zapisywaniu kolejnych porcji danych na HD? Tzn.
LVs są sfragmentowane już od początku istnienia? - lecz przecież to
nie oznacza fragmentacji plików.
Michoo
> On 6 Lis, 11:03, Michoo<michoo_n...@vp.pl> wrote:
>>> 1.) Jak taka abstrakcyjna warstwa nad dyskiem wpływa na transfer
>>> dyskowy?
>>
>> Niezauważalnie. Chyba, że się postarasz żeby zepsuć. (Pojedyncze
>> przemieszane bloki.)
>
> Podobno można postawić LVs jako contiguous lub non-contiguous.
chyba tylko do przestrzeni extentów - alokuje je w sposób ciągły, czyli
jeżeli dobrze rozumiem:
V1|V2|V3 po usunięciu V2 i zaalokowaniu V4 przy contiguous będzie
V1|V4A|V3|V4B a przy normal V1| |V3|V4
> I w tym
> drugim przypadku bloki będą przemieszane, prawda? Czy nie sądzisz, że
> czasem to może być pożyteczne? Poszczególne katalogi linuksa leżą na
> osobnych LV i są one używane jednocześnie. Tak więc wówczas chyba
> dobrze by było żeby te dane były fizycznie jak najbliżej siebie?
odległość, ale operacje sekwencyjne są najlepsze - a od tego jest cache.
W idealnym scenariuszu: system ładuje pierwszy obszar do cache, ładuje
drugi obszar do cache i operuje na tym.
--
Pozdrawiam
Michoo
Stachu 'Dozzie' K.
> On 6 Lis, 11:49, Kajetan Staszkiewicz <vegetaBezSp...@tuxpowered.net>
> wrote:
>> Warto. Masz wtedy możliwość łatwego tworzenia osobnych filesystemów różnej
>> wielkości pod różne zastosowania
>
> ale w czym to jest lepsze od zrobienia wielu partycji fizycznych w tym
> takich tradycynych logicznych na EXTENDED?
> Pewnie powiesz, że chodzi o łatwość w poźnieszej modyfikacji wielkości
> tych LV.
> Ale przecież jest sporo dobrych i pewnych narzędzi do modyfikowania
> partycji fizycznych, np. PartitionMagic itp.
>
> Tak więc jakie są inne zalety LVM które dają przewagę takiemu
> rozwiązaniu?
Brak rebootu.
>> i możliwość tworzenia snapshotów.
>> Szczególnie snapshoty są fajne i przydatne.
>
> Przydatne - do czego? Proszę podaj konkretne sytuacje i zastosowania.
Jak nie wiesz do czego mogą ci być przydatne snapshoty, to znaczy że ich
nie potrzebujesz i możesz zignorować ten argument.
--
Secunia non olet.
Stanislaw Klekot