Partitionering: LVM of niet?

[Pete]

Op mijn workstation ga ik de nieuwste ubuntu installeren. Op dit moment heb ik de volgende harde schijven:
sda - 150 GB - 2 partities, huidige ubuntu en niet belangrijke data, deze disk is oud en langzaam
sdb - 250 GB - leeg, voor nieuwe ubuntu
sdc - 250 GB - 2 partities, Belangrijke data & swap
sdd - 250 Gb - 1 partitie, backup

Ik zit te denken aan drie partities voor de nieuwe ubuntu, /, /home en /var.

Heeft het nut om lvm te gaan gebruiken? Ik weet dat met lvm je eenvoudig partities kunt wijzigen in grootte en zelfs partities kunt uitbreiden over disks.

Kan ik bijvoorbeeld mijn huidige data kan behouden als ik lvm wil gebruiken voor alle disks? Kan ik ook lvm gebruiken voor alleen sdb?

Ik verwacht ook niet dat ik mijn partities te klein worden. Heeft lvm nut voor mij?

[moto-moi]

Ik zou eerder gaan denken aan een raid5 opstelling met de 250GB schijven die je hebt en de 150GB schijf verder vergeten

[Abomination]

LVM is alleen nuttig als je later de partities wil vergroten met een nieuwe schijf zonder iets te veranderen aan de bestaande partities en data.
Wanneer alles een eigen plekje krijgt op de verschillende disks, en je niet gaat spannen met de schijven, dan is LVM niet nodig. Nieuwe schijven kunnen ook als mount point en daarna met eventueel symlink toegevoegd worden aan een lokatie mocht dat nodig zijn.

[Pete]

moto-moi schreef op zaterdag 21 november 2009 @ 10:55:
Ik zou eerder gaan denken aan een raid5 opstelling met de 250GB schijven die je hebt en de 150GB schijf verder vergeten

Met een raid5 opstelling houd ik dan maar 500GB over en dat is een beetje te weinig. Ook heb ik niet het budget om er op dit moment schijven bij te kopen. Daarnaast verwacht ik niet superveel snelheids voordeel van raid5 zonder een dedicated controller.

Is het ook niet af te raden je OS op een raid5 te zetten?

[Verwijderd]

Pete schreef op zaterdag 21 november 2009 @ 11:39:

Is het ook niet af te raden je OS op een raid5 te zetten?

Kan geen kwaad, en is geen enkel probleem.

Ik zie echter nog niets staan over back-up, wel over "belangrijke data". Minstens één schijf hoort dus niet in een RAID of LVM configuratie te staan. Backups moeten niet real-time geüpdate worden tenzij je incremental of differential backups kunt maken.

[Pete]

Verwijderd schreef op zaterdag 21 november 2009 @ 11:50:
[...]

Kan geen kwaad, en is geen enkel probleem.

Ik zie echter nog niets staan over back-up, wel over "belangrijke data". Minstens één schijf hoort dus niet in een RAID of LVM configuratie te staan. Backups moeten niet real-time geüpdate worden tenzij je incremental of differential backups kunt maken.

Lees goed. sdd is op dit moment de backup schijf. Daarnaast (wat ik niet nog niet had vermeld) is er een netwerk harde schijf met backups.

[Verwijderd]

Ik zou dit doen als je data toch wel belangrijk is:

sda --> disk voor het OS

sdb --> raid5
sdc --> raid5
sdd --> raid5

of:

sda --> disk voor het OS

sdb --> raid1
sdc --> raid1
sdd --> raid1 spare

Wat ik niet zou doen:

Al die disks in een LVM gooien ipv RAID als een van die disks uit valt

[Caelorum]

Daarnaast is het werkelijk waar een ramp om een lvm partitie te verkleinen..
Het enigste voordeel dat je krijgt van LVM is dat je binnen de LVM partitie heel erg eenvoudig nieuwe logical volumes kan aanmaken of bestaande wijzigen.

Ikzelf zou gewoon lekker allemaal aparte partities maken.

[jayvol09]

Als je /var apart wilt doen is het niet handig om die bij de raid 5 array te doen omdat je dan alsnog naar alle schijven schrijft. Ook is het idd niet erg handig je OS op de raid 5 array te zetten. Ik zou geen raid nemen als je toch al een backup op het netwerk hebt.
LVM is een slecht systeem dat wss met nieuwe filesystems overbodig gaat worden.

sdb - primary root partitie van 20GB en primary partitie van 8GB voor /var en 512MB swap de rest /home

je hebt hier nu dus al 3 primaire partities +swap
Je kunt nu bv. raid0 van de 250 GB schijven maken voor een 500GB primaire partitie voor data en de 150GB laten voor wat t is (voeg em toe aan je netwerk backup ofzo).

[Verwijderd]

Caelorum schreef op zaterdag 21 november 2009 @ 12:57:
Daarnaast is het werkelijk waar een ramp om een lvm partitie te verkleinen..

Dat is niet waar, hoe kom je hier bij?

[Verwijderd]

jayvol09 schreef op zaterdag 21 november 2009 @ 14:45:
LVM is een slecht systeem dat wss met nieuwe filesystems overbodig gaat worden.

Wat is er dan volgens jou zo slecht aan LVM? Klein voorbeeldje: sinds jaar en dag is LVM default onder RHEL, dagelijks vertrouwen talloze enterprise organisaties op LVM. LVM is zeer betrouwbaar en bestaat sinds lange tijd in de Linux kernel.

[Caelorum]

Verwijderd schreef op zaterdag 21 november 2009 @ 15:24:
[...]


Dat is niet waar, hoe kom je hier bij?

Ik had het hier over het fysieke volume waar de volumegroup op staat,
Als je mij een makkelijke manier kan beschrijven waarmee ik een lvgroup ter grootte van mijn HD kan verkleinen zodat ik er een extra partitie op kan maken buiten de LVM om hou ik me aanbevolen..
Elke poging van mijn kant zover resulteerde in een nietwerkend systeem.

[moto-moi]

jayvol09 schreef op zaterdag 21 november 2009 @ 14:45:
Als je /var apart wilt doen is het niet handig om die bij de raid 5 array te doen omdat je dan alsnog naar alle schijven schrijft. Ook is het idd niet erg handig je OS op de raid 5 array te zetten. Ik zou geen raid nemen als je toch al een backup op het netwerk hebt.

want een backup terugzetten is altijd te prefereren boven het niet stukgaan van je complete machine

Ik zou altijd raid5 gebruiken als het ff kan Backups zijn leuk, maar het liefst gebruik je ze nooit.

Je kunt nu bv. raid0 van de 250 GB schijven maken voor een 500GB primaire partitie voor data en de 150GB laten voor wat t is (voeg em toe aan je netwerk backup ofzo).

Ehm. Raid0 is alleen zinvol voor dat die je direct weg zou kunnen gooien omdat je ze al ergens anders live standby hebt, bijvoorbeeld bij een news-frontend. Ik zou dat echt nooit als tip geven voor iemand die het als workstation wil gebruiken hoor

[jayvol09]

Wat is er dan volgens jou zo slecht aan LVM?

Het werkt/doet wat het moet doen, maar betekent niet dat t optimaal is. Ik vind t onnodig technisch (komt vast omdat t oud is), als ik een extra reepje RAM in mn pc doe hoef ik toch ook niet met managers enzo aan de slag.

want een backup terugzetten is altijd te prefereren boven het niet stukgaan van je complete machine

Ja, RAID is geen backup, en rebuilden van een array duurt denk ook nog is langer dan backup terugzetten. Ook gaf TS al aan de capaciteit niet te willen verliezen.

Ik zou [raid0] echt nooit als tip geven voor iemand die het als workstation wil gebruiken hoor

Nou het heeft zn voordelen als je veel data heen en weer copieert, en dat het als 1 schijf gezien wordt betekent efficienter gebruik. Maar als hij de 2 schijven als aparte filesystems wil mounten is hij toch aangewezen op een exended partitie met 2 logical volumes van 250GB? Dat wou ik vermijden.

[blaataaps]

jayvol09 schreef op zaterdag 21 november 2009 @ 17:47:
[...]

Het werkt/doet wat het moet doen, maar betekent niet dat t optimaal is. Ik vind t onnodig technisch (komt vast omdat t oud is).

Het tegenovergestelde ontkennen is geen argument voor je eigen standpunt
Waarom is het "slecht" en "niet optimaal"? Het heeft bijna geen overhead en levert nogal wat flexibiliteit

Ja, RAID is geen backup, en rebuilden van een array duurt denk ook nog is langer dan backup terugzetten. Ook gaf TS al aan de capaciteit niet te willen verliezen.

Dit snap ik niet helemaal ("denk ook nog is"?). Een raid rebuilden is wat anders dan een backup terugzetten (raid rebuilden is geen downtime), en van disk naar disk lineair blocks kopieren duurt langer dan een backup terugzetten?

[jayvol09]

blaataaps schreef op zaterdag 21 november 2009 @ 19:39:
[...]
Het tegenovergestelde ontkennen is geen argument voor je eigen standpunt
Waarom is het "slecht" en "niet optimaal"? Het heeft bijna geen overhead en levert nogal wat flexibiliteit
[...]

Volgens mij had ik gezegd dat ik t te technisch vond, dus ik heb t niet over prestaties maar het concept zelf. Maar 'slecht' was misschien niet goed gekozen, ik denk dat met de huidige stand van zaken dit software gewoon verouderd is en er behoefte is aan simpliciteit in de partitie-wereld. Als er niets anders is dan moetje t wel gebruiken. Dus ik bedoelde niet "gebruik geen lvm omdat t slecht is".

Dit snap ik niet helemaal ("denk ook nog is"?). Een raid rebuilden is wat anders dan een backup terugzetten (raid rebuilden is geen downtime), en van disk naar disk lineair blocks kopieren duurt langer dan een backup terugzetten?

Ligt idd ook wel aan de grootte van t array, ik denk dat backup terugzetten sneller gaat (meen tijd terug iets gelezen te hebben over trage rebuilds). Maar overbodigheid is niet de hoofdreden waarom ik geen raid5 zou nemen. Capaciteit verliezen zodat je een klein beetje downtime (downtime btw alleen in het geval dat root schijf breekt) voorkomt leek me niet wat de TS zocht.
Ook is met deze schijvenset het niet praktisch om de OS e.d. op de array te zetten (en de langzame 150GB lijkt me daar ook geen optie voor)

[ Voor 4% gewijzigd door jayvol09 op 21-11-2009 20:57 ]

[CAPSLOCK2000]

Caelorum schreef op zaterdag 21 november 2009 @ 15:42:

Ik had het hier over het fysieke volume waar de volumegroup op staat,
Als je mij een makkelijke manier kan beschrijven waarmee ik een lvgroup ter grootte van mijn HD kan verkleinen zodat ik er een extra partitie op kan maken buiten de LVM om hou ik me aanbevolen..
Elke poging van mijn kant zover resulteerde in een nietwerkend systeem.

Stel dat je /dev/sda1 wil krimpen naar 100G (niet getest, lees de handleiding):

code:

lvreduce -L 100G /dev/mapper/mijnLogicalVolume
pvresize --setphysicalvolumesize 100G /dev/sda1

Je moet daarvoor wel het filesystem op mijnLogicalVolume verkleinen. Dat kan een groter probleem zijn maar heeft niks met LVM te maken.

Verder vind ik je voorbeeld eerlijk gezegd een beetje een randgeval. Het is klagen dat je nieuwe jas zou koud is als je de rits open laat staan. Je gebruikt LVM juist zodat je geen traditionele partities meer hoeft te gebruiken.

[Caelorum]

CAPSLOCK2000 schreef op dinsdag 24 november 2009 @ 12:59:
[...]


Stel dat je /dev/sda1 wil krimpen naar 100G (niet getest, lees de handleiding):

code:

lvreduce -L 100G /dev/mapper/mijnLogicalVolume
pvresize --setphysicalvolumesize 100G /dev/sda1

Je moet daarvoor wel het filesystem op mijnLogicalVolume verkleinen. Dat kan een groter probleem zijn maar heeft niks met LVM te maken.

Verder vind ik je voorbeeld eerlijk gezegd een beetje een randgeval. Het is klagen dat je nieuwe jas zou koud is als je de rits open laat staan. Je gebruikt LVM juist zodat je geen traditionele partities meer hoeft te gebruiken.

Dat is allemaal wel leuk, maar daarmee verklein je alleen een logical volume. De volgroup blijft daarmee nog steeds even groot en evenveel ruimte innemen. Deze zal je dan ook nog moeten verkleinen en pas daarna kan je een nieuwe partitie aanmaken, welke bijv in windows gebruikt kan worden.
Als ik onder fedora zou blijven werken zou allles perfect gaan ja, maar zodra je een windows OS moet gebruiken ben je de sjaak.

Daarnaast heeft het alles met LVm te maken omdat het letterlijk 2 console commands kost om het zonder LVM te doen en met LVM een stuk of 6, waarbij je alsnog 90% kans hebt je LVM om zeep te helpen.

[CAPSLOCK2000]

Caelorum schreef op dinsdag 24 november 2009 @ 21:22:
[...]

Dat is allemaal wel leuk, maar daarmee verklein je alleen een logical volume. De volgroup blijft daarmee nog steeds even groot en evenveel ruimte innemen. Deze zal je dan ook nog moeten verkleinen en pas daarna kan

Ik dacht dat een volume group automatisch mee groeit en krimpt met de fysieke volumes die er in zitten.

je een nieuwe partitie aanmaken, welke bijv in windows gebruikt kan worden.
Als ik onder fedora zou blijven werken zou allles perfect gaan ja, maar zodra je een windows OS moet gebruiken ben je de sjaak.

Als het met Windows compatible moet zijn heb je een punt.

Daarnaast heeft het alles met LVm te maken omdat het letterlijk 2 console commands kost om het zonder LVM te doen en met LVM een stuk of 6, waarbij je alsnog 90% kans hebt je LVM om zeep te helpen.

LVM is wat meer typen, maar je maakt het erger dan het is. De meeste distributies hebben tegenwoordig ook GUI's om LVM te managen, dus als je niet wil typen dan hoeft het niet.

[MisterE]

CAPSLOCK2000 schreef op woensdag 25 november 2009 @ 12:00:
[...]

Ik dacht dat een volume group automatisch mee groeit en krimpt met de fysieke volumes die er in zitten.

Je LV verkleinen/vergroten heeft niets met de VG te maken. Je VG moet je zien als een heel hoop kleine partities (extends) die je aan een LV kan geven. Waar je wel rekening mee moet houden is dat je het filesystemen op je LV moet aanpassen nadat je hem vergroot hebt. Bij het verkleinen moet je juist eerst je filesystem aanpassen voordat je de LV kleiner maakt, anders kan je data kwijt raken.
Bij AIX hoef je daar bijv geen rekening mee te houden, maar daar kennen ze ook iets minder filesystems

[Caelorum]

CAPSLOCK2000 schreef op woensdag 25 november 2009 @ 12:00:
LVM is wat meer typen, maar je maakt het erger dan het is. De meeste distributies hebben tegenwoordig ook GUI's om LVM te managen, dus als je niet wil typen dan hoeft het niet.

Dat klopt maar juist op dit punt is waar de GUI's niet in voorzien. Zowel de GUI's van de vershillende distro's als gparted etc.
Zoals ik al zei is LVM echt heerlijk maar je moet wel zeker weten dat je de ruimte die je aan de LVM geeft niet later nog nodig hebt voor een OS zoals windows.

[CAPSLOCK2000]

MisterE schreef op woensdag 25 november 2009 @ 12:59:

Je LV verkleinen/vergroten heeft niets met de VG te maken. Je VG moet je zien als een heel hoop kleine partities (extends) die je aan een LV kan geven. Waar je wel rekening mee moet houden is dat je het filesystemen op je LV moet aanpassen nadat je hem vergroot hebt. Bij het verkleinen moet je juist eerst je filesystem aanpassen voordat je de LV kleiner maakt, anders kan je data kwijt raken.
Bij AIX hoef je daar bijv geen rekening mee te houden, maar daar kennen ze ook iets minder filesystems

Mijn punt was dat om een Physical Volume te verkleinen je eerst ruimte in je Volume Group moet hebben. Dat kan bijvoorbeeld door een Logical Volume te verkleinen. Als er ruimte in je VG is dan kun je ook je PV verkleinen. Aan de VG zelf hoef je niks te veranderen.

Caelorum schreef op woensdag 25 november 2009 @ 15:59:

Dat klopt maar juist op dit punt is waar de GUI's niet in voorzien. Zowel de GUI's van de vershillende distro's als gparted etc.
Zoals ik al zei is LVM echt heerlijk maar je moet wel zeker weten dat je de ruimte die je aan de LVM geeft niet later nog nodig hebt voor een OS zoals windows.

Ik weet dat Redhat er een heeft. Debian heeft er een in de installer zitten, al heb ik die nog nooit als stand-alone gezien, ik vermoed dat het wel kan. Ubuntu heeft ongetwijfeld ook wat.

[Caelorum]

CAPSLOCK, ik weet dat deze GUIs hebben, maar deze kunnen alleen LVs afhandelen. Met de daadwerkelijke PV kan je iig in fedora niks doen.
Het programma dat dit wel zou kunnen is gparted, maar deze kan dan weer niet met LVM overweg

[jayvol09]

Kan je ze niet combineren om te krijgen wat je wilt