Newsgroup: it.comp.os.linux.sys
Titolo: hot LVM resizing

Salve a tutti,
su di un server devo ridimensionare una partizione a discapito di 
un'altra. Le partizioni sono entrambe LVM ma NON posso smontarle, devo 
fare tutto a caldo.
Ovviamente prima di fare tutto ho effettuato dei backup, ma non potendo 
mettere in offline il server, immaginate quanto gradirei evitare di fare 
disaster recovery :)
Diversi howto non mostrano problemi sull'effettuazione di un resize a 
caldo su partizioni montate.
lvreduce -L-1G /dev/gruppo/LVM1
lvextend -L-1G /dev/gruppo/LVM2
resize2fs ...
ecco, il problema è che lvreduce mi avverte con un ELOQUENTE messaggio:
WARNING: Reducing active and open logical volume to 14,00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
al quale, in tutta franchezza, parte una sincera grattata seguita da un 
"Annullare ANNULLARE!!" stile film militare americano.
Che faccio (non potendo smontare i volumi)?

 Che faccio (non potendo smontare i volumi)?
Anche smontando i volumi avresti lo stesso problema.
Devi prima ridurre il fs (resize2fs) e poi ridurre i
volumi *non* oltre la dimensione del fs.
bye,
-- 
piergiorgio

 
ah ok, però comunque resize2fs vuole che il fs sia smontato, come si 
evince dal man.
quindi non vi è un modo per fare un resize di un LVM con punto di mount 
/ senza riavviare? giusto? possibile? uno dei vantaggi di LVM non era 
questo?

 questo?
Con LVM e` possibile, ma deve esserlo anche con il fs.
Ho come l'impressione che vi sia un po' di confusione.
LVM ti fornisce un "device", che, tra le varie cose,
puo` essere ridimensionato quando in uso (credo).
Il filesystem che ci metti sopra, ammesso che tu ci
metta un filesystem, e` una cosa diversa.
Se il filesystem non si puo` ridimensionare online,
allora il tutto non puo` essere ridimensionato "live".
In altri termine, LVM non sa nulla del fs che sta sopra.
Quindi almeno *due* condizioni *indipendenti* devono
essere soddisfatte:
1) il fs deve essere resizeable
2) il device deve essere resizeable
bye,
-- 
piergiorgio

 questo?
LVM ti permette di fare tutto online, ma se il FS che ci scrivi sopra non 
supporta anch'esso le stesse features ovviamente non puoi godere appieno dei 
vantaggi.
L'extend è possibile online pressoché con tutti i FS, lo shrink no.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 L'extend è possibile online pressoché con tutti i FS, lo shrink no.
chiarissimi entrami, vi ringrazio. ora è tutto più trasparente.

 
ora che ci penso: quindi l'unico modo per ridimensionare / è riavviare 
con una live?

 con una live?
Ad occhio direi di si.
bye,
-- 
piergiorgio

 con una live?
Lavoravo in un posto dove su tutte le redhat era stato montato veritas, e 
quindi, questo problema non si poneva.
Adesso con ext3 mi sono ritrovato in una situazione simile alla tua. E' 
stato fatto un backup cautelativo, stop della applicazione e shrink della 
partizione. che palle. speriamo che pippo-fs che prenderà il posto di 
ext3 abbia la feature dello shrink online. Ma più che altro speriamo che 
pippo-fs venga presto.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 con una live?
Se devi stringerla sì. Se devi allargarla no.


 
già. purtroppo però per allargarne una devo stringere l'altra :\
potrei anche aggiungere un disco all'array...

 potrei anche aggiungere un disco all'array...
Per stringere volumi diversi da root è sufficiente partire in Single User 
Mode. Il problema comunque si riconduce sempre ad un'errata pianificazione 
dello schema di partizionamento, attività spesso sottovalutata.
Allocare tutto lo spazio disponibile anche se non necessario comporta sempre 
questo tipo di problemi.


 sempre questo tipo di problemi.
...ma farlo capire ai clienti è dura... :-\
-- 
http://bofhskull.wordpress.com/

 vuoi ridurne le dimensioni.
Non vorrei dire uno strafalcione, ma con reiserFS mi pare di averlo fatto a
caldo, senza smontare.. 
-- 
g4b0, linux user n. 369000
http://gabo.homelinux.com

 caldo, senza smontare.. 
Con la 3.6 no di sicuro perché la uso correntemente su diversi server. Con 
la 4 non so perché l'ho abbandonata :)
zipmantp:~# lvcreate -L 100M -n test rootvg
   Logical volume "test" created
zipmantp:~# mkfs.reiserfs /dev/rootvg/test
mkfs.reiserfs 3.6.21 (2009 
www.namesys.com
)
[CUT]
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
ReiserFS is successfully created on /dev/rootvg/test.
zipmantp:~# mount /dev/rootvg/test /mnt/temp/
zipmantp:~# resize_reiserfs -s-20M /dev/rootvg/test
resize_reiserfs 3.6.21 (2009 
www.namesys.com
)
Can't shrink filesystem on-line.
zipmantp:~# lvextend -L+50M /dev/rootvg/test
   Rounding up size to full physical extent 52.00 MB
   Extending logical volume test to 152.00 MB
   Logical volume test successfully resized
zipmantp:~# resize_reiserfs /dev/rootvg/test
resize_reiserfs 3.6.21 (2009 
www.namesys.com
)
resize_reiserfs: On-line resizing finished successfully.


 
semplicemente /var/log/ è cresciuta oltre il previsto. quasi quasi 
faccio una cosa brutta.
(copio) elimino e sposto la partizione /var/log/ e la faccio diventare 
una normale cartella di /

 
http://www.youtube.com/watch?v=jb3OWgjg_ls
esprime al meglio il concetto.. la potresti piantare di triturare le 
gonadi ad ogni piè sospinto con sta storia di ext3? in un 3ad come 
questo che era "ottimo" come contenuti per livello di informazione tu 
hai solo "rotto i coglioni" (Cit.)
Stefano

 una normale cartella di /
Brrrr...... non puoi fare cosa più bestiale... Se ti si riempie la root sei 
TFU e il tuo servizio che oggi non puoi fermare si ferma all'istante.
Piuttosto (ed è comunque una mezza porcheria) puoi creare uno script da far 
girare dopo la rotazione dei log che verifica lo spazio disponibile sul 
rootfs e, se ce n'è a sufficienza sposta i vecchi log compressi in /archive.
In questo modo liberi spazio in /var/log ma non rischi di bloccare il 
sistema se per qualche motivo i log iniziano a crescere incontrollatamente 
(e non è una possibilità remota).


 faccio una cosa brutta.
Uhm, io ho fatto cosi`.
Ho un HD da 320GB, ma ho "allocato", in vari volume LVM,
qualcosa meno, credo 250GB.
Ogni qualvolta un volume "diventa" piccolo, lo allargo
su lo spazio libero.
Certo, c'e` un limite, ma credo prima di raggiungerlo
sara` da cambiare l'HD.
In particolare /var e /var/tmp stanno su due volumi
diversi. Cosi` come, ovviamente, /usr, /home, etc.
bye,
-- 
piergiorgio



Ti faccio una sola domanda.
Quale sarebbe l'ottimo contenuto di questo thread?
Il fatto che ext3 non supporta lo shrink online?


 pianificazione dello schema di partizionamento, 
mettiamo anche che sia questo il motivo, e non sopravvenute esigenze, che 
richiedono modifiche del tutto impreviste.
Ma mi spiegate qual è l'alternativa offerta da ext3 anche per queste 
situazione in cui c'è stata una errata pianificazione?
Perché non dovrei usare un FS che prevede anche la possibilità di ovviare 
a eventuali errori di pianificazione?
Anni fa, nel posto XXX, c'erano 600 server hp-ux con veritas e un 
centinaio di RedHat sempre con veritas. Mi arrivavano di continuo 
richiesta di resize, e le espletavo in 60 secondi. Saranno stati tutti 
"errori di pianificazione", ma credimi, è meglio poter ovviare a questi 
errori in questo modo, che non dover fermare le applicazioni e far 
ripartire il sistema con un live CD.


 
elenca i FS che hai di default su linux che permettono lo shink online..
ribadisco i termini: linux, default e shrink, ergo solaris, zfs, 
sarcazzi vari NON sono validi
ora, posto che se avessi detto nel tuo post "che palle, mi tocca 
comunque spegnere la macchina/smontare il device/avere una interruzione 
di servizio" non ci sarebbe stato nulla da obiettare, ti faccio notare 
che come puoi leggere nel post di The_Zipman (quello dove dimostra che 
con reiser_fs è la stessa cosa) NON è un problema di extX, ma dei FS in 
generale.
ciò detto, riascoltati Aldo almeno un paio di volte..
S.

 Max_Adamo ha scritto:
Lascia perdere. Io l'ho messo nell'ignore list e da quel momento su icols 
leggo il 90% di cretinate in meno.
Segui il consiglio: plonkalo e vivi felice. Fidaty® :)


 sarcazzi vari NON sono validi
ma chi ha mai detto una cosa del genere? Ma dove l'avrei mai scritta?
Io ho parlato di vxfs per linux, che so benissimo che non è un filesystem 
di default per linux, e che devi pagare tanto di licenza per usarlo.
Che tutti i filesystem per Linux non hanno lo shrink online, ma figurati 
se non lo so.
Se vuoi te li elenco a mena dito:
reiser fino a 3.6: supporta lo shrink offline
jfs per linux: non supporta lo shrink (ne offline ne online)
xfs: non supporta lo shrink (ne offline ne online)
ext3: supporta lo shrink solo offline.
il mio pippo-fs si riferiva a btrfs, però per evitare guerre di religione 
cxontro ext4 avevo evitato di nominarlo.
Non mi fraintendere e rileggimi bene.... con ext3, purtroppo, allo stato 
attuale devo dire: che palle.


 icols leggo il 90% di cretinate in meno.
secondo me ti sopravvaluti parecchio... questo è il tuo problema.


 attuale devo dire: che palle.
e lascia perdere zfs.... mica tengo in considerazione un FS che dovrei 
utilizzare in userspace.
parlavo di vxfs per linux, e citavo tra le righe btrfs.


 parlavo di vxfs per linux, e citavo tra le righe btrfs.
poi ripeto, siccome non sono un fan di nulla non me ne frega nemmeno di 
btrfs pertanto pippo-fs può essere il cacchio che ci pare.
Stanno facendo il porting del filesystem di Digital/Tru64 su Linux (mi 
sfugge il nome), sarebbe sperabile che implementassero lo schrink su xfs, 
ma va bene anche se lo implementassero pure su extX, o su quel che ti 
pare.


 situazione in cui c'è stata una errata pianificazione?
Hai finito di spaccare i maroni al mondo?
-- 
http://bofhskull.wordpress.com/

 Hai finito di spaccare i maroni al mondo?
ma dai... lo so che lo sporto di questo gruppo è darsi sempre la pacche 
sulle spalle e denigrare subito chi non vuole partecipare alla vostra 
mentalità cultica.
Io vorrei che qualcuno dicesse, in tutta onestà, senza porsi grossi 
problemi di sorta, almeno uno di voi dicesse una volta, non che linux fa 
schifo (visto che a me non fa schifo), ma che effettivamente questo è un 
problema in linux.
E' inutile continuare a dirsi minchiate e a giustificare tutto parlando 
di errori di pianificazione o cazzate di questo tipo.


 /archive.
Oppure usando rsyslog, hai una comoda funzionalità, che scatena il lancio di 
uno script al superamento di una certa dimensione...
##esempio di /etc/rsyslog.conf
$template 
precise,"%syslogpriority%,%syslogfacility%,%timegenerated:::date-mysql%,%syslogtag%,%msg:::drop-last-lf%\n"
$outchannel limitato,/var/log/messages,1048576,/bin/rotate messages
*.* $limitato;precise
Ciao,
ScriptJus

 mentalità cultica.
Dimostri di non aver capito un cazzo, ma -chissà com'è- la cosa non mi 
stupisce affatto.
La mancanza di shrinking online è un problema?
Sì. Pur calmierabile con un minimo di pianificazione, tanto che pur 
svariate centinaia di server amministrati all'attivo, mi è capitato di 
sentirne la mancanza forse un paio di volte.
Sarebbe bello averlo?
Certo.
Fine del thread. Fine dell'argomento.
-- 
http://bofhskull.wordpress.com/

 Certo.
Oh cazzo. Così vi voglio. Ci voleva tanto? Ti senti un po' male adesso 
che lo hai detto?
Ma sai qual è la cosa buffa in tutta questa discussione? Che tra 6 mesi o 
un anno, pure linux avrà il suo shrink online, e tutto quello ci stiamo 
dicendo adesso non varrà più un cazzo.


 Certo.
Oh cazzo. Così vi voglio. Ci voleva tanto? Ti senti un po' male adesso 
che lo hai detto?
Ma sai qual è la cosa buffa in tutta questa discussione? Che tra 6 mesi o 
un anno, pure linux avrà il suo shrink online, e tutto quello ci stiamo 
dicendo adesso non varrà più un cazzo.
-- 


 Il Mon, 23 Mar 2009 22:20:07 +0100, Skull ha scritto:
news server dal cavolo.... mi resta il messaggio appeso e ne partono due 
o tre.


 Oh cazzo. Così vi voglio. Ci voleva tanto?
Ottimo, mi fa felice renderti contento.
Ora prometti che per i prossimi 6 mesi ti trovi un nuovo arcomento 
anzichè continuare a triturare i coglioni con questo?
-- 
http://bofhskull.wordpress.com/

 Certo.
Mah, mia opinione personale e` che, primo, non credo
lo shrink sia, statisticamente, cosi` frequente come
l'extend. Secondo, che *forse* la difficolta` che si
potrebbe avere con lo shrink online, e di conseguenza
la complessita` del codice, non giustifichino il
presunto vantaggio. Terzo, magari dopo un po' di volte
con problemi, uno impara anche a partizionare! :-)
bye,
-- 
piergiorgio



1) in ambiente desktop/domestico lo shrink online non è un  must, ma un 
"di più che non guasta", senza il quale sopravvivi tranquillamente. Puoi 
spegnere il PC quando vuoi, e farlo ripartire con la distro live che hai 
sempre a portata di mano.
2) in ambiente business di piccola/media entità, riesci ancora a 
sopravvivere senza grossi problemi anche senza lo shrink online in quanto 
la gestione dei server è verticale. Verticale vuol dire che una sola 
persona si occupa di tutto, dai backup, all'installazione, al deploy 
delle applicazioni. Ad ogni modo, in questi casi anche il downtime è 
gestibilissimo.
3) in un ambiente cosiddetto enterprise di grosse dimensioni le cose 
stanno in maniera un po' diversa e ti spiego perché in questi ambienti è 
facile fare in errori. In questi ambienti la gestione delle piattaforme 
non è verticale ma a strati. Qualcuno crea della documentazione per 
installare i sistemi e impartisce alcune direttive, e (spesso) non 
conoscendo a fondi i sistemi (ma solo la sua applicazione) impartisce 
direttive che possono essere errate. Chi installa il sistema a sua volta 
non ha possibilità di andare in deroga alle richieste scritte in un piano 
di integrazione. Deve farlo come è scritto su quel pezzo di carta e 
basta. I giri sono lunghissimi, ci si perde e si finisce per sbagliare.
4) oltre all'errore, avevo citato l'altra possibilità di modifiche delle 
applicazioni che girano sulla macchina stessa. Nel caso particolare che 
citavo io, alcuni volumi erano stati sovradimensionati e veniva usato uno 
storage condiviso. Nel momento in cui sono state aggiunge altre macchine 
al gruppo in cluster si è dovuto decidere tra:
 a) buttare soldi per aggiungere altri dischi
 b) utilizzare lo spazio dai volumi che erano stati sovradimensionati.
Si è optato per la "b". Questo ha richiesto un downtime applicativo, e la 
richiesta per un backup a scopo cautelativo. Tutto questo in ambienti di 
certe dimensioni, richiede uno sforzo notevole per l'attivazione di tute 
le procedure ed è un disastro. A quel punto non so se sia stato fatto un 
resize, o se la partizione sia stata distrutta e ricreate e sia stato 
fatto il restore.
Spero sia chiaro.


Max_Adamo wrote:
[...]
Il senso del mio dubbio era se vale la pena rischiare
di avere un FS con bug, pur di avere lo shrink online,
che, a mio avviso, su usa meno dell'extend.
Cioe` il costo di downtime per lo shrink vale la perdita
(potenziale) di dati run-time?
bye,
-- 
piergiorgio

 coglioni con questo?
leggiti la risposta a Piergiorgio. Contiene tutto il mio pensiero 
sull'argomento e quello sono le motivazioni che mi spingono a trarre 
queste mie conclusioni, e non una inutile e avulsa critica nei confronti 
di Linux.
Dimmi cossa può essere sbagliato secondo quel punto di vista. Io lo trovo 
molto corretto.




Sono d'accordissimo con te. Un FS buggato è la cosa peggiore del mondo e 
bisogna andarci veramente con i piedi di piombo.
Una cosa del genere, se deve essere fatta, deve essere fatta non bene, ma 
benissimo.
Su XFS un tizio si era messo a scrivere un po' di patch per lo shrink, ma 
tutto è finito lì, perché evidentemente non è un gioco da ragazzi. Sugli 
altri FS non so qual è lo stato dell'arte.
Per quanto riguarda lo shrink offline, lo trovo più utile in ambienti di 
piccole dimensioni, che non in ambienti molto grandi.
In ambiente grandi, queste problematiche le puoi gestire anche con un 
netbackup e un successivo restore e ti ricrei le partizioni. Tanto il 
downtime lo avrai lo stesso.
p.s.: a quel che mi ricordo veritas non perdeva un colpo per fare queste 
operazioni.


 problema in linux.
E' un problema in qualsiasi sistema operativo, allora.
Vxfs a parte, di shrink online ce n'è pochino ovunque, eh.
E, come osservato altrove, lo shrink online è cosa molto
raramente richiesta, anche in ambito enterprise, checchè tu
ne dica.

 Vxfs a parte, di shrink online ce n'è pochino ovunque, eh.
btrfs e advfs supportano lo shrink online, e entrambi sono quasi
pronti per Linux.

 con una live?
Se hai spazio crei nuovi volumi logici, ci schiaffi tutto dentro e
cancelli i vecchi...
Io l'ho fatto un po' di hot resizing, ma solo con xfs e in crescendo,
non in calando.

ScriptJus ha scritto:

si ok, farò così. mi sembra meglio.
cmq per precauzione ho spostato /var/spool sulla /, così se si riempie 
log non mi inficia lo spool di stampa.