LVM:Dubbioso

[conraid]

Tra l'altro vedo dal changelog di ext2progs
http://e2fsprogs.sourceforge.net/e2fspr ... tml#1.41.4
che il resize online è presente dal 2005

Quindi meska dovrebbe funzionarti senza tool aggiuntivi

[masalapianta]

Bene.
Benissimo,quindi il resize online è possibile

si

,è possibile anche per la / ?

mai fatto su /, comunque non vedo particolari problemi

[Meskalamdug]

Bene grazie 1000

[Mario Vanoni]

Umile domanda, pregi/differenze tra

piu` partizioni con LVM
contro
partizione unica HD root (/)

Sto facendo test con USB stick da giorni,
i log file in /var/log superano 2GB per test.
Con HD di 1TB e partizione unica, no problems.

Non sapendo, e/o non potendo prevedere
quale dimensione un log file puo` raggiungere,
come ci si arrangia con LVM?

Domanda puramente accademica.

[Meskalamdug]

Io lo ho messo per comodità
supponiamo domani voglia montare
un altro disco,lo posso aggiungere
e poi col resize online divido lo spazio
tra i vari volumi logici.
Tutto quà,almeno per me

[Meskalamdug]

"Non sapendo, e/o non potendo prevedere
quale dimensione un log file puo` raggiungere,
come ci si arrangia con LVM?"
Se non erro si possono gestire le grandezze
dei log con logrotate.

[conraid]

Umile domanda, pregi/differenze tra

piu` partizioni con LVM
contro
partizione unica HD root (/)

Sto facendo test con USB stick da giorni,
i log file in /var/log superano 2GB per test.
Con HD di 1TB e partizione unica, no problems.

Non sapendo, e/o non potendo prevedere
quale dimensione un log file puo` raggiungere,
come ci si arrangia con LVM?

Domanda puramente accademica.

Non c'entra niente la differenza tra LVM e partizione unica, puoi anche avere LVM con un unico filesystem (uso la parola filesystem per dire che può esere partizione, unità logica, etc...) , per esempio se ti piace avere un'unico filesystem / ma hai due dischi, con LVM puoi fare in modo che / prenda entrambi gli hard disk.

Sulla seconda domanda ne abbiamo parlato fin troppo

[masalapianta]

Umile domanda, pregi/differenze tra

piu` partizioni con LVM
contro
partizione unica HD root (/)

bhe la lista e' lunga, cosi' a braccio mi vengono in mente le seguenti cose:
1) assoluta scalabilita' riguardo allo spazio allocato per i filesystem (puoi ingrandire e rimpicciolire a piacere, utilizzando anche dispositivi fisici differenti per lo stesso file system, quali dischi locali, lun remote da uno storage fibre channel,iscsi,ecc.., dischi usb, pen drive,ramdisk, meta device, e potenzialmente qualsiasi cosa il kernel veda come un dispositivo a blocchi)
2) possibilita' di fare snapshot
3) possibilita' di far gestire raid 1/0 direttamente al volume manager
riguardo ai vantaggi di avere file system separati rispetto ad un unico file system, ho gia spiegato esaurientemente tutti i perche' e i percome al seguente link:
viewtopic.php?f=2&t=25203

Non sapendo, e/o non potendo prevedere
quale dimensione un log file puo` raggiungere,
come ci si arrangia con LVM?

dalla domanda intuisco che sei completamente a digiuno del concetto di volume manager (e non solo delle implementazioni su linux), quindi come premessa alla risposta faccio un breve ed approssimativo excursus della struttura di un volume manger (della tipologia di lvm2 o del lvm di AIX, quindi senza plex o altri layer d'astrazione introdotti in volume manager come vxvm o altri):
principalmente in un volume manager ci sono le seguenti entita': volumi fisici, gruppi, volumi logici
un volume fisico non e' altro che un dispositivo a blocchi (normalmente una partizione, ma non necessariamente) che viene marcato con dei metadati (uuid e altre cose), un gruppo e' un insieme di volumi fisici e infine un volume logico non e' altro che un dispositivo a blocchi che puo' essere creato utilizzando lo spazio allocato per un gruppo.

Rispondendo alla tua domanda, uno dei vantaggi di lvm e' proprio che non ti devi preoccupare di quanto spazio in futuro ti servira' su un fs, in quanto se un volume logico e' ormai pieno e magari non hai physical extent liberi sul volume group sul quale risiede il volume logico, ti basta attaccare un disco alla macchina (o una LUN da una SAN), marcarlo come volume fisico e aggiungerlo al tuo gruppo, a quel punto avrai altri physycal extent che ti permetteranno di ingrandire il tuo volume logico e il fs che ci sta sopra

[Mario Vanoni]

Rispondendo alla tua domanda, uno dei vantaggi di lvm e' proprio che non ti devi preoccupare di quanto spazio in futuro ti servira' su un fs, in quanto se un volume logico e' ormai pieno e magari non hai physical extent liberi sul volume group sul quale risiede il volume logico, ti basta attaccare un disco alla macchina (o una LUN da una SAN), marcarlo come volume fisico e aggiungerlo al tuo gruppo, a quel punto avrai altri physycal extent che ti permetteranno di ingrandire il tuo volume logico e il fs che ci sta sopra

Grazie, mi sono spiegato male.

Non hai 1TB come root (/),
ma tot partizioni/LVM, p.e. /var di 1GB.

Il tuo programma fa un log file,
tu lo guardi con less in modo tail -f,
dopo 2 giorni supera il limite di /var,
magari a mezzanotte del secondo giorno.

Cosa succede con LVM?

Con root (/) di 1TB niente, /var ha spazio,
less ti segna sempre gli ultimi cambiamenti.
E continuera` fino a "no space left" con 1TB.

Sempre domanda accademica.

PS logrotate non serve, un test == un log file.

[conraid]

Con root (/) di 1TB niente, /var ha spazio,
less ti segna sempre gli ultimi cambiamenti.
E continuera` fino a "no space left" con 1TB.

Sempre domanda accademica.

fa la stessa cosa che con partizioni non lvm, ma se sei un sito di quelli belli grandi e magari sotto attacco ddos saturi anche 1TB (anche se in quel caso i log li gestisci in altro modo, logorate, remoti, etc..), allora /var separato ti permette di non saturare le altre partizioni
Lo spazio è questione "relativa" e poi dipende da come gestisci i vari servizi, in una configurazione di default in Slackware per esempio dentro /var ci sono database, siti, mail, etc... quindi forse conviene "separare" /var/log

Comunque LVM non aumenta o diminuisce da solo, e non so quanto convenga farlo fare a qualche script automatico

[masalapianta]

Grazie, mi sono spiegato male.

Non hai 1TB come root (/),
ma tot partizioni/LVM, p.e. /var di 1GB.

Il tuo programma fa un log file,
tu lo guardi con less in modo tail -f,
dopo 2 giorni supera il limite di /var,
magari a mezzanotte del secondo giorno.

Cosa succede con LVM?

Con root (/) di 1TB niente, /var ha spazio,
less ti segna sempre gli ultimi cambiamenti.
E continuera` fino a "no space left" con 1TB.

Sempre domanda accademica.

scusa ma la domanda non ha senso, in pratica dici: "se ho un filesystem e si riempie che succede?" che c'entra lvm con questo? E' ovvio che ogni fs va dimensionato per la mole di dati che tu prevedi dovra' contenere, poi ovvio che alla lunga potresti doverlo allargare, ma nell'arco di una notte se ti si riempie significa che era stato dimensionato male oppure che qualche processo ha cominciato a lavorare in maniera anomala riempiendolo (ma questo succede pure con un unico fs da 1TB, certo ci mettera' magari 3 ore a riempirsi invece che 5 minuti, ma la mattina troverai comunque dei processi inchiodati e un bel "no space left" anche col fs da 1TB)

[Mario Vanoni]

scusa ma la domanda non ha senso, in pratica dici: "se ho un filesystem e si riempie che succede?" che c'entra lvm con questo? E' ovvio che ogni fs va dimensionato per la mole di dati che tu prevedi dovra' contenere, poi ovvio che alla lunga potresti doverlo allargare, ma nell'arco di una notte se ti si riempie significa che era stato dimensionato male oppure che qualche processo ha cominciato a lavorare in maniera anomala riempiendolo (ma questo succede pure con un unico fs da 1TB, certo ci mettera' magari 3 ore a riempirsi invece che 5 minuti, ma la mattina troverai comunque dei processi inchiodati e un bel "no space left" anche col fs da 1TB)

Hai ragione, grazie.

Valutavo solo se per me LVM ha senso,
indubbiamente NO, con HD 1.5TB ottenibili gia` oggi,
tra sei mesi ci sono HD 2TB al prezzo di 1TB.

Slackware 12.2, compreso /var,
occupa 31GB del TB, 96% libero.
OK, i dati importanti sono sul secondo HD 1TB.

[masalapianta]

Valutavo solo se per me LVM ha senso,
indubbiamente NO, con HD 1.5TB ottenibili gia` oggi,
tra sei mesi ci sono HD 2TB al prezzo di 1TB.

Slackware 12.2, compreso /var,
occupa 31GB del TB, 96% libero.
OK, i dati importanti sono sul secondo HD 1TB.

bhe LVM non e' solo resize, ci son gli snapshot, la gestione di raid 1/0 fatta direttamente dal volume manager, il fatto che quando esaurisci lo spazio non sei obbligato a spostare un enorme mole di dati su un disco piu' grande e tante altre cose; btw in tutto questo la cosa che realmente pone grossi limiti (a prescindere che si usi un volume manager o meno) e' creare un unico fs e mettere tutto li, per i motivi che ho gia spiegato nel seguente link:
viewtopic.php?f=2&t=25203

[C4Rd0]

Ciao a tutti,
volevo fare una domanda in merito a LVM: ma secondo voi, c'è convenienza a usarlo in un portatile? C'è qualcuno lo usa su un laptop? Ipressioni, commenti, insulti?

Ciao.
C4Rd0.

[Meskalamdug]

Attenzione!
Non usate ext4 con lvm2 per scopi
"produttivi" so che nessuno lo fa
ma avvertire è meglio.
Ho appena provato una rimozione
di disco vecchio(lvresize,vgreduce,etc..)
su ext4 e ho praticamente perso la partizione
Stessa procedura con ext3 e tutto è andato bene
ecco come ho proceduto.

Aggiungo disco

Codice: Seleziona tutto

pvcreate /dev/hda1

espando un esistente vg

Codice: Seleziona tutto

vgextend Disco /dev/hda1

espando un esistente lv

Codice: Seleziona tutto

lvextend -L 100%FREE /dev/Disco/Prova
resize2fs /dev/Disco/Prova 

Il disco hda è vecchio...lo voglio levare.

Codice: Seleziona tutto

fsck.ext3 -f /dev/Disco/Prova
 resize2fs /dev/Disco/Prova 99GB#99G è la dimensione di hdb(nuovo disco che voglio tenere)

Riduco il lv...

Codice: Seleziona tutto

lvreduce -L 99G /dev/Disco/Prova

Levo il disco dal gruppo...

Codice: Seleziona tutto

vgreduce Disco /dev/hda1

e infine dal PV

Codice: Seleziona tutto

 pvremove /dev/hda1

Ripeto,con ext4 ho perso tutti i dati(il lv non montava e dava errori con fsck)
con ext3 tutto a posto.