Egy példa LVM használatára Debian-on XFS fájlrendszerrel

Dokumentáció

Ez az írás egy, az LVM nyújtotta lehetőséget mutat be egy példán keresztül, Debian rendszerben, melynek segítségével menet közben megnöveljük a / fájlrendszert. A fájlrendszer típusának XFS-t válaszottam mert az XFS lehetővé teszi a partíciók átméretezését felcsatolt fájlrendszerrel.

Megszűntettünk egy fájlrendszert, így a diszken van szabad hely (partícionálatlan terület):

A partíciós tábla kb. így nézett ki: 


/dev/hda1:    65 GB    Linux LVM
/dev/hda:     11.32 GB    Free Space (korábban ReiserFS volt rajta /dev/hda5 néven).

Van egy rootvg néven korábban létrehozott volume group-unk: 


sempron:~# vgdisplay

--- Volume group ---
VG Name rootvg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 8
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 65.00 GB
PE Size 4.00 MB
Total PE 16641
Alloc PE / Size 16128 / 63.00 GB
Free PE / Size 513 / 2.00 GB
VG UUID tdPiZj-fBYD-EBto-oHgs-4YFR-RtyV-3a3jWr

Megnézzük, milyen logical volume-ok vannak a rootvg nevű volume groupban: 


sempron:~# lvdisplay

--- Logical volume ---

LV Name /dev/rootvg/tmplv
VG Name rootvg
LV UUID recK7h-nO7E-hnKv-Qd4R-Q01S-RcP3-MvFwpK
LV Write Access read/write
LV Status available
# open 1
LV Size 1.00 GB
Current LE 256
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:0

--- Logical volume ---

LV Name /dev/rootvg/swaplv
VG Name rootvg
LV UUID kYB5fo-I00r-80qE-mPkX-j3Gb-Lh31-JJq6ra
LV Write Access read/write
LV Status available
# open 2
LV Size 2.00 GB
Current LE 512
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:1

--- Logical volume ---

LV Name /dev/rootvg/rootlv
VG Name rootvg
LV UUID Sec9al-KNSi-u4DB-ohLc-A7X8-go5t-w2VR3A
LV Write Access read/write
LV Status available
# open 1
LV Size 60.00 GB
Current LE 15360
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:2

Ebből láthatjuk, hogy a rootvg nevű volume group-ban (aminek mérete 65 GB - ld. fentebb a vgdisplay kimenetét) van 3 darab logical volume: a tmplv, a swaplv és a rootlv, méretük 1 GB, 2 GB és 60 GB. (A hiányzó 2 GB pedig ott van a volume groupban (vgdisplay kimenetében látható)).

És a rootvg nevű volume groupban van egy physical volume, a /dev/hda1: 


sempron:~# pvdisplay

--- Physical volume ---
PV Name /dev/hda1
VG Name rootvg
PV Size 65.00 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 16641
Free PE 513
Allocated PE 16128
PV UUID e5TAii-PH9w-B6FO-UWWI-AkA8-BaZR-khPVBW

A következő lépésben a pvcreate parancs segítségével megmondjuk, hogy a diszken lévő szabad területet (ami korábban /dev/hda5 néven látszott), most LVM egy fizikai volume-jának szeretnénk felhasználni. (Ez utóbbi akár teljes különálló diszk is lehetne (pl. /dev/hdb), nem szükséges, hogy partíció legyen.) 


sempron:~# pvcreate /dev/hda5

Physical volume "/dev/hda5" successfully created

Ezután látjuk a physical volume-ok között a /dev/hda5-öt: 


sempron:~# pvdisplay

--- Physical volume ---
PV Name /dev/hda1
VG Name rootvg
PV Size 65.00 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 16641
Free PE 513
Allocated PE 16128
PV UUID e5TAii-PH9w-B6FO-UWWI-AkA8-BaZR-khPVBW

--- NEW Physical volume ---
PV Name /dev/hda5
VG Name
PV Size 11.32 GB
Allocatable NO
PE Size (KByte) 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID YGi5Y0-HYst-3dyG-Z7oo-Rzwo-CrKY-HjimE2


A /dev/hda5 physical volume-ot berakjuk a már létező rootvg volume group-ba. 


sempron:~# vgextend rootvg /dev/hda5

Volume group "rootvg" successfully extended

Ezáltal, hogy új physical volume-ot adtunk hozzá, megnövekedett volume group mérete, ami szabad helyként látható: 


sempron:~# vgdisplay

--- Volume group ---

VG Name rootvg
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 2
Act PV 2
VG Size 76.32 GB
PE Size 4.00 MB
Total PE 19539
Alloc PE / Size 16128 / 63.00 GB
Free PE / Size 3411 / 13.32 GB
VG UUID tdPiZj-fBYD-EBto-oHgs-4YFR-RtyV-3a3jWr

Az lvextend parancs segítségével a volume groupban lévő szabad helyből 5 GB-ot hozzáadunk a létező rootlv logical volume-hoz, amin a / fájlrendszerünk van (persze menet közben). 


sempron:~# lvextend /dev/rootvg/rootlv --size=+5G

Extending logical volume rootlv to 65.00 GB

Logical volume rootlv successfully resized

(Ennél a műveletnél természetesen a volume group-ban lévő szabad helyből tudunk gazdálkozni – jelen esetben 5 GB-ot adtunk hozzá az egyik logical volume-hoz a volume group-ban lévő 13.32 GB helyből.)

A logical volume-ot is megnöveltük, de a fájlrendszeren még nem látunk változást... 


sempron:~# df -h

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 60G  2.3G 58G 4% /
tmpfs 443M 0 443M 0% /lib/init/rw
udev 10M 60K 10M 1% /dev
tmpfs 443M 0 443M 0% /dev/shm
/dev/mapper/rootvg-tmplv 1008M 34M 924M 4% /tmp

...mert ehhez a fájlrendszer méretét is meg kell növelnünk. Az XFS adta lehetőségeket kihasználva ezt szintén menet közben, felcsatolt / fájlrendszerrel megtehetjük: 


sempron:~# xfs_growfs /

meta-data=/dev/root isize=256 agcount=16, agsize=983040 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=15728640, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=7680, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
data blocks changed from 15728640 to 17039360

És sikerült: 


sempron:~# df -h

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv 65G  2.3G 63G 4% /
tmpfs 443M 0 443M 0% /lib/init/rw
udev 10M 60K 10M 1% /dev
tmpfs 443M 0 443M 0% /dev/shm
/dev/mapper/rootvg-tmplv 1008M 34M 924M 4% /tmp

Ezzel menet közben sikeresen megnöveltük a / fájlrendszert. Természetesen ehhez szükség volt egy szabad partícióra a gépben lévő diszken, de hot-plug-os rendszerek esetén egy új diszk menetközbeni behelyezésével ez megtehető, leállás, sőt XFS esetén fájlrendszer lecsatolása nélkül.

( TJ | 2007. 08. 19., v – 14:04 )

kösz, épp gondolkoztam, hogy megkérdezem ezt a fórumban :)

( deta | 2007. 08. 19., v – 15:04 )

de sok ilyet latnek itt a hupon flame helyett...

Attol meg nem hal(na)nak meg.
De nem fdiskkel, hanem pvcreate-tel manipulalsz - attol meg nem halnak meg ;) -,
vgextenddel adod a vg-hez - ezuan meg mar nincs ertelme a "particio" -rol beszelni.
- tehat a particion levo adat meghal - kulonosen, ha filerendszerbe volt szervezve.

( Ajnasz v | 2007. 08. 19., v – 15:19 )

Bele kell tenni a wikibe bele az ilyet :)

Hmmm.

biowulf:csardi$ mount
...
/dev/julcsavg/disklesslv on /diskless type xfs (rw)
...
biowulf:csardi$ cat /etc/exports | grep diskless
...
/diskless/biowulf/192.168.1.101/dev 192.168.1.101(rw,no_root_squash,sync)
/diskless/biowulf/192.168.1.101/etc 192.168.1.101(rw,no_root_squash,sync)
/diskless/biowulf/192.168.1.101/var 192.168.1.101(rw,no_root_squash,sync)
/diskless/biowulf/192.168.1.101/tmp 192.168.1.101(rw,no_root_squash,sync)
/diskless/biowulf/192.168.1.102/dev 192.168.1.102(rw,no_root_squash,sync)
...

Ezek szerint félnem kellene valamitől?

akkor kellene félned, ha 4k-s stackkel fordítod a kenrnel-t mert akkor Oops-ol vagy Panicol.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.3-pancs1-wifi1 - 2.6.22.3 kernel madwifivel itt

amugy a killer quartet ez: LVM+XFS+NFS+4k stack, de ezt elvileg a 2.6.22-esben javították, DE EZ NEM BIZTOS.
http://lkml.org/lkml/2007/7/16/474

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.3-pancs1-wifi1 - 2.6.22.3 kernel madwifivel itt

( siposa v | 2007. 08. 19., v – 15:49 )

Jó kis leírás.

Úgy tudom, patch-csel az ext2/3 fájlrendszereken is lehet online resize-t végrehajtani. CentOS-nak pl. része is.

( asd | 2007. 08. 19., v – 16:43 )

Jo a cikk. Vegre valami ami nem csak pletyka.

Erdemes lett volna kiterni meg a kulonbozo konyvtarak (/var, /usr, /boot, /tmp, /home) kulon felcsatolasanak elonyeire is.

asd

A kulon /usr-nek van valami elonye azon kivul, hogy lehet read-onlyra mountolni, es egy n. security layert raksz igy a rendszerbe, viszont szivas mindig read/write-ra mountolgatni? Oke, hogy ritkan telepit az ember programot, de ez szvsz nem eri meg. Ha a /usr-ben levo fileok korruptak tudnak lenni, akkor mar nem ugyis root a tamado, akkor emg mar nem ugyis mind1? Olyan elonyet tudom meg elkepzelni, hogy igy tenyleg viszonylag kicsi lesz a /. Ezen kivul milyen elonyei vannak ennek? Linuxtol is elvonatkoztathatunk.

hat vegyesen a kovetkezokre gondoltam:

/usr: ro, nodev (dpkg-t fel lehet kesziteni ra, hogy remountolja az fs-t rw es vissza ha vegzett)
/var: noexec, nosuid, noatime
/home: nodev, noexec, nosuid
/tmp: nodev, noexec, nosuid, noatime

Hasznaltam meg a /-t nodev-kent, csak megszivtam amikor kiforgattam a kernelbol a devfs-t es 2 hetig nem jottem ra, hogy miert nem tud a kernel az 1-es es a 2-es runlevel kozott valtani ;)

ugyanakkor a mai memóriaárak/méretek mellett megfontolandó a lapozóterület használatának esetleges elhagyása

Én meg a mai diszk árak mellett szoktam csinálni 10G SWAP-et, aztán ha a kollégák kicsit (?) túllőnek a célon akkor sem lövi ki az intelligens (?) gyilkos a két hete futó számítást.

Nem ismerem annyira a memóriakezeés működését, de ha nagyobb memigényű dolog fut (VMware), akkor egy picit jobb szokott lenni a foglalás egy ilyen 512 körüli swap-pal (a szerverbe 1.5 G RAM volt). Ha egy VMware gép bootol, akkor azért nem mindegy, hogy 2 vagy 5 sec a várakozás. Még ha ez nem is releváns difi.

valahogy igy (google segit):

DPkg
{
Pre-Invoke { "mount / -o remount,rw" };
Pre-Invoke { "mount /usr -o remount,rw" };
Pre-Invoke { "mount /boot -o remount,rw" };
Pre-Invoke { "mount /tmp -o remount,exec" };
Pre-Invoke { "mount /var -o remount,exec" };
Post-Invoke { "mount / -o remount,ro" };
Post-Invoke { "mount /usr -o remount,ro" };
Post-Invoke { "mount /boot -o remount,ro" };
Post-Invoke { "mount /tmp -o remount,noexec" };
Post-Invoke { "mount /var -o remount,noexec" };
};

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( uixuix | 2007. 08. 21., k – 19:54 )

/Flame -na majd en ;)

Orommel tapasztaltam hogy nem probalt meg senki xfs-t fikazni es ext3-at isteniteni...
Az en tapasztalatom szerint ez utobbi nagy (tobb 100gb) filerendszerek es nagy file-ok eseten (dvd iso-k, vmware stb.) elegge elkeserito tud lenni...
Kinomban azt hiszem vagy visszaterek az xfs-hez vagy kiprobalom a vxfs ingyenesen elerheto valtozatat.

/Flame off

Amióta az otthoni gépemben van 1GB fizikai mem, és azt látom, hogy ott áll és pókhálósodik a 2GB swap, azóta inkább csak annyi swap helyet foglalok, mint a memória mérete. (512MB-nál pl. 512Mb-ot stb.) De sztem 2GB fizikai memóriánál már megfordul a helyzet, és a swapnek elég 1GB is.

( dash | 2010. 07. 17., szo – 13:57 )

A mai napom eddigi tanulsága, hogy _dinamikus_ vbox disken ne használjunk lvm-et. (Azért támadt eme perverz ötletem mert magát az lvm létrehozását, parancsait (ebből mondjuk nem sok van, és nagyon logikusak) is gyakorolni akartam, de nem volt kéznél megfelelő fizikai masina, a hoston meg nem volt túl sok szabad hely.)

Az pv+vg+lv létrehozás ugyan sikerülni fog, de amint ráhúzunk egy rendszert egy logical volume-ra a vboxnak fogalma sem lesz róla hogy mennyi a szabad hely (mert gondolom ez a linux kernel belügye), kell-e éppen növelni (maximum a virtuális mérethatárig) a vdi-t. Tehát dinamikusan növekvő tároló esetén már a telepítés során felmásolandó fájloknál csontra fagyhat az egész.

Utólag belegondolva amit leírtam, a fenti párosítás tényleg nagy böszmeség volt :D.

Viszont mostmár tényleg értem az LVM lényegét, és azt is hogy ha fixed-size disk-kel csinálom (üres=(lv nélküli) területet is hagyva rajta), akkor ez milyen jó! Mármint gyakorlásra, mert vboxban dinamikusan növekvő lemezek halmaza egyébként egyszerűbb megoldás. Fizikai gépen pedig LVM.

---
> man woman
No manual entry for woman

https://www.dropbox.com/referrals/NTM3MTUzNzQ5