Newsgroup: it.comp.os.linux.sys
Titolo: grow/shrink ext3

Ciao, ho scoperto che 10 macchine che uso hanno un disco partizionato
cosi':
# fdisk -lu
Disk /dev/sda: 73.5 GB, 73543163904 bytes
255 heads, 63 sectors/track, 8941 cylinders, total 143638992 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      401624      200781   83  Linux
/dev/sda2          401625    16048934     7823655   82  Linux swap /
Solaris
/dev/sda3        16048935   143637164    63794115    5  Extended
/dev/sda5        16048998    22314284     3132643+  83  Linux
/dev/sda6        22314348    41865389     9775521   83  Linux
/dev/sda7        41865453    71184014    14659281   83  Linux
/dev/sda8        71184078    80967599     4891761   83  Linux
/dev/sda9        80967663   143637164    31334751   83  Linux
La cosa buffa (che ho realizzato) e' che la sda9 non e' montata su
nessuna delle 10 macchine e che quindi mi sto perdendo praticamente
meta' disco per macchina.
Ora, non posso mettere offline le macchine e riformattare e
reinstallare... ext3 supporta il ridimensionamento non distruttivo? La
mia idea era quella di eliminare sda9, spostare sda8 (/var) alla fine
del disco, far crescere sda7 (/opt) e le altre fino ad occupare tutto il
disco... 
consigli? idee?
d

 consigli? idee?
domanda scema: hai chiesto a chi ha installato le macchine? magari su
sda9 ha messo su il "ghost" della macchina in caso qualcuno
sputtani /, per ripristinarla in poco tempo.
Ciao Jack

 wrote:

Confermo che la partizione e' vuota.
A questo punto, secondo voi, e' fattibile tirare su LVM per unire la
sda9 con la sda7 (unica in cui potrei aver bisogno di piu' spazio...)
senza dover andare in single user mode?
d

 reinstallare... 
Formattare... reinstallare... e che e' windous???
Smonti la partizione, mke2fs, rimonti la partizione ed ecco nuovo spazio a 
disposizione.

 Troppo tardi. Non puoi tirare su un VM senza distruggere le partizioni.
La partizione rimane intatta, è il contenuto che viene cancellato.
Dawe potrebbe, in ordine:
- creare un LVM su sda9
- copiarci i dati da sda7
- aggiungere sda7 al nuovo LVM (cancellando il contenuto di sda7)
Fermo restando che /opt sia smontabile, non saprei.. altrimenti dovrebbe 
usare il livecd o entrare in runlevel 1
Alessandro

Alessandro <nos...@nospam.nospam> wrote:

/opt e' smontabile in effetti... Mmm, la cosa si fa interessante!
d

 disposizione.
E perdere i dati?
d

 - aggiungere sda7 al nuovo LVM (cancellando il contenuto di sda7)
Premessa: non sono un sistemista (magari questa domanda vi farà ridere).
"Purtroppo" il mio disco è diviso in due partizioni reiserfs [1]: / da 6,6G
e /home da 68G. Mi sono pentito dopo l'installazione di non aver dato
qualcosina in più a / (tipo arrivare a 10G) -- perché a quanto ne so, reiserfs
non è "ridimensionabile"... è vero?
Se sì, penso che anche con LVM non potrei far nulla (-- se anche fosse solo
"riducibile", ridurrei /home, e nello spazio libero farei un'altra partizione
-- però poi dovrei seguire la stessa procedura di cui sopra... e non mi fido a
cancellare i dati da /...)
David
[1] scelto consapevolmente: mai perso un dato con reiserfs, che sia un bit; e
poi non c'è la "camurrìa" (come diremmo dalle mie parti) del fsck ogni tot
mount/giorni...
-- 
 . ''`.  Debian maintainer | 
http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- 
http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- 
http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 ogni tot mount/giorni...
tune2fs -c 0 -i 0 /dev/quelchee`
man tune2fs
Bye.



Sì, d'accordissimo, sapevo già. :)
Quello che mi dà fastidio di ext3 (mi pare anche ext2 faccia così, ma non
ricordo) è che _comunque_ devi fare lo fsck ogni tot. Questo comportamento
potevo capirlo con ext2, ma ext3 ha il journalling, perché sprecare tempo
prezioso? :)
Poi, forse, è questione di filosofia...
David


 sprecare tempo prezioso? :)
No, non lo devi fare comunque. Puoi disattivarlo.
L'opzione e` rimasta solo per paranoia, perche` capita, soprattutto con 
dischi IDE, che il controller ogni tanto sballi un bit. Siccome e` il 
controller a farlo, non torna errore al S.O., che quindi non si accorge 
che c'e` un errore sul disco.
Un e2fsck rileva una inconsistenza e, se puo`, la corregge prima che 
diventi grave o irrecuperabile.
Bye.

 prezioso? :)
Leggi man tune2fs e scoprirai il perche' e' utile proprio con il
journal.
[*]  You  should  strongly consider the consequences of disabling
mount-count-dependent checking entirely.  Bad disk drives, cables,
memory, and kernel bugs could all corrupt a filesystem without marking
the filesystem dirty or in error.  If you are using journaling  on  your
filesystem,  your filesystem will never be marked dirty, so it will not
normally be checked.  A filesystem error detected by the kernel will
still force an fsck on the next reboot, but it may already be too late
to prevent data loss at that point.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net


Se hai dei dati che non puoi perdere, hai il backup, percio' i dati
li ricarichi al volo. :-P


 
In nessun caso fai il resizing senza backup. 

 ricarichi al volo. :-P
E' formidabile pensare che oggigiorno, con 1TB di disco, per di piu' 
velocissimo a meno di 150 neuri la gente si rifiuti sistematicamente di 
fare il backup dei dati importanti.
Fa tanto kamikaze.

 non è "ridimensionabile"... è vero?
Non conosco reiserfs, ma non capisco:
/ => reiser
/home => reiser
..poi? non c'e' altro spazio e/o partizioni?
Supponendo che /home sia ridimensionabile, o che tu riesca a ottenere 
10Gb da altre parti, potresti operare in due modi:
- più "dirty": tramite livecd formatti e copi il contenututo di "/" 
(senza /home) nella nuova partizione, rimetti a posto il menu.lst sotto 
/boot/grub e, previo chroot, con grub imposti il boot nella nuova 
partizione.
- più pulito: fai un chroot nella nuova partizione e istalli nuovamente 
il sistema operativo da zero. Dopodichè, tramite grub, imposti il boot 
nella nuova partizione.
Comunque, andasse male, avresti la vecchia radice a posto e basterebbe 
impostare il boot (salvando l'mbr?)
Poi ti avanzerebbero 6.6Gb della vecchia radice...
Alessandro

 - più pulito: [..]
Avevo pensato piuttosto a quello che avevi detto in un altro post
(chiamiamo /dev/sda7 la partizione ottenuta da /home):
- creare /dev/sda7 :)
- andare di live [1], e copiare / (/dev/sda1) in /dev/sda7
- creare LVM su /dev/sda1
- ricopiare /dev/sda7 in / (/dev/sda1)
- estendere LVM su /dev/sda7
[1] è necessario? Credo di sì :)
David


 
Alessandro
PS: io chiacchero, ma considera che sebbene sia riuscito a estendere 
varie volte il mio volume LVM su molti hd.. non sono mai riuscito a 
ridurlo! E se un giorno si dovesse bruciare qualche settore..

 Insomma, ogni FS javi i so camurrie :)
(di dove sei?)
Ma dico io, non si possono unire tutti quanti e fare "il FileSystem
perfetto"? ;)
David


 Questo non lo sapevo... vado di google.
...ma anche di man: man 8 resize_reiserfs
Mi sa che qualche giorno (dopo adeguati backup, e con mezza giornata libera)
provo...


 filesystem: btrfs
Cercherò anche su questo.
Grazie,


 perfetto"?
ZFS? :-)

 XFS ha un tool di defrag, usa gli extent, tool per il backup, tool per il 
Ho sentito parlare solo bene di reiser
Qui se ne elenca un po' i pro e i contro
http://en.wikipedia.org/wiki/ReiserFS
Ma non capisco una cosa: dopo la vicenda Hans R., il suo fs è ancora 
pienamente supportato e in fase di sviluppo?
E un altra domanda: tu (ma la domanda è rivolta a tutti) l'hai istallato 
su un server in produzione?
Mi alletta parecchio :-)
Grazie
Alessandro

 pienamente supportato e in fase di sviluppo?
Sì, perché non dovrebbe? :)
Che io sappia non era un "one-man-project" (beh, almeno formalmente) -- c'era
(e c'è) un'azienda dietro -- la NameSys. Che, appunto, Hans Reiser sta tentando
di vendere, per garantire lo sviluppo di reiserfs :)


 Sì, perché non dovrebbe? :)
Ok, arrivo :-) ho una partizione libera
apt-get install reiser4progs reiserfsprogs
A pro:
dpkg -s reiserfsprogs
Description: User-level tools for ReiserFS filesystems
  This package contains utilities to create, check, resize, and debug
  ReiserFS filesystems.
Quindi il resize c'è
Alessandro

 Quindi il resize c'è
Come avevo già detto prima, man resize_reiserfs :)


 pienamente supportato e in fase di sviluppo?
Dipende dalla versione di cui parli. ReiserFS 3.x attualmente si trova
in uno stato vegetativo (ovvero, niente feature aggiuntive, ma solo
bugfix), mentre Reiser4 attualmente non e` ancora considerato stabile
(e, tra l'altro, a causa della sua natura, non e` nemmeno nel kernel
tree). Tra l'altro, ReserFS 3 e Reiser4 non sono compatibili
Enrico

 shrink.
Oddio, ext3 ti permette piu` tuning, e ext4 implementera` quelle parti
che mancano a ext3. Personalmente la cosa che mi piace di piu` di XFS e`
il supporto nativo alle quota
Enrico

 - estendere LVM su /dev/sda7
Non puoi, Linux (o GRUB? Non saprei) non supporta  il boot da volumi su
LVM. Puttosto, ti conviene spostare sullo spazio guadagnato dal
ripartizionamento di /home, o /usr o /var (la prima e` piu`
consigliabile)
Enrico

 anni e montarlo sedicimilavolte senza che si lamenti.
E` un numero sparato a caso o ha una sua fondatezza?
Enrico
P.S. comunque, personalmente sto seriamente pensando di disabilitare il
check sulla partizione ext3 di /home (e` 289GB, caspio!)

 ho mai provato.
No, /boot deve essere separato.
-- 
Fr3ddie
fr3...@fr3ddie.it
Home Page: 
http://www.fr3ddie.it
PGP Public Key available on my website
«Due cose sono infinite: l'Universo e la stupidità umana.
Ma sull'Universo ho ancora dei dubbi»
Albert Einstein

 
http://grub.enbug.org/LVMandRAID
Interessante, ma è ancora una beta, o sbaglio?
Su un server non mi sembra il caso per 500 MiB di /boot (ci ficchi 100 
kernel il 500 MiB, stai tranquillo una vita intera).....
-- 
Fr3ddie
fr3...@fr3ddie.it
Home Page: 
http://www.fr3ddie.it
PGP Public Key available on my website
Non c'è niente di più pericoloso di un cretino che ha ragione per caso

 Sul desktop io tengo solo l'ultimo kernel e il tutto mi occupa 10 MB.
Su un desktop è tutto un altro paio di maniche, anche io tengo solo gli 
ultimi due kernel, ma giusto perché sono paranoico ;)
-- 
Fr3ddie
fr3...@fr3ddie.it
Home Page: 
http://www.fr3ddie.it
PGP Public Key available on my website
Io non so se Dio esiste.
Ma se esiste, spero che abbia una buona scusa

 E` un numero sparato a caso o ha una sua fondatezza?
Tanto quanto 42.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Abbandonero' XFS non appena btrfs diventera' stabile.
Ottimo. Non vedo pero` cosa c'entri con quello che ho detto sopra
Enrico

 Tanto quanto 42.
Sei un demonio :)
Enrico

 A ext3 manca praticamente di tutto.
Sara`. Obiettivamente, a parte i file system sperimentali ed in via di
sviluppo, ext e` l'unico file system attivamente sviluppato:
- XFS: da quando e` stato introdotto per la prima volta su Linux, non
  ha avuto alcuna aggiunta di funzionalita` (e.g. come dici, tra le
  altre cose manca lo shrink), anzi, durante il port alcune cose sono
  state tolte a causa delle differenze tra Irix e Linux.
- ReiserFS 3.x: oramai e` un progetto morto, le cui uniche attivita`
  sono relative al bugfix.
- Reiser4, oltre ad essere completamente incompatibile con ReiserFS
  3.x, da quando e` nato promette di distruggere il mondo, ma
  effettivamente ancora non se lo fila nessuno (se sia un problema di
  mancato rispetto di standard od un problema politico, non e` rilevante
  ai fini del discorso).
- JFS: e` praticamente congelato a causa del fatto che non se lo fila
  proprio nessuno (probabilmente a causa anche che nelle prime versioni
  per Linux non era molto stabile), nonostante anch'egli abbia
  delle ottime carte (il solo fatto che per per fare il grow del file
  system basta fare il remount lo ritengo spettacolare).
Insomma, a guardarla la situazione non sembra affatto rosea. Capisco
che mettere mano ad un file system e` una operazione delicata e
rischiosa, ma qua si rischia di perdere un indubbio vantaggio rispetto
agli sistemi, visto che ogni file system ha i suoi punti di forza (e.g.
JFS risulta quello che ha un minor impatto sulla CPU, rendendolo
quindi ottimo in ambienti virtualizzati e poveri di risorse). Da questo
punto di vista il fatto che ext si dimostri attivo a sviluppare sempre
e comunque nuove funzionalita` non puo` essere che visto come una cosa
positiva, dato che cerca di evolversi continuamente. Tra l'altro, e`
interessante notare che ext e` l'unico file system che non ha dietro
un'azienda (a parte una minima partecipazione di Red Hat)
Enrico
P.S. per una comparazione tra i file system di Linux questo puo` essere
un ottimo punto di partenza:
http://www.debian-administration.org/articles/388