Newsgroup: it.comp.os.linux.iniziare
Titolo: Consigli partizionamento 1TB

Ho un HD esterno da 1 TB.
Lo utilizzo per la maggiorparte da linux, ma non si sa mai che in
futuro mi serva anche accedervi o comunque utilizzarlo da
windows, comunque molto di rado in ogni caso...
Attualmente � partizionato in fat32, partizione unica.
A cosa mi serve:
- Dati principalmente.
- Come appoggio per compilazione: una dir la uso per chroot.
  Attualmente su fat32 ho fatto un file poi formattato in ext3
  che monto in /mnt/file e poi uso tale dir come chroot.
  Il problema � che il chroot � liitato a 4.3 GB perch� il file
  sta sempre su fat32 alla fine. Nulla vieta di fare due file ecc
  ecc, ma volevo ripartizionare meglio il disco.
Avete consigli?

JohnnyNewbie wrote:

perch� usi un file system di 15 anni fa?
-- 
have you tried turning off and on your computer?


perche' non ntfs ?

 Attualmente è partizionato in fat32, partizione unica.
Perchè non usi Ext3 installando uno dei diversi driver disponibili
Ext2/Ext3 per Windows ?

 Ext2/Ext3 per Windows ?
Quoto, appoggio e spingo con furore!
Un filesystem FAT32 da 1 tera mi fa venire il latte alle ginocchia, oltre
al fatto che ti porti il limite di 4G per la dimensione massima di ciascun
file.
Bud
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 file.
Beh, diciamo che Ext2 permette di superare i 2GB solo su sitemi a 64
bit, ma a parte questo proprio in questo momento sto cercando di
recuperare qualche cosa da una periferica USB che si è spenta mentre ci
stavo scrivendo sopra... risultato filesystem letteralmente scomparso...


NTFS....
Ma il limite a 4GB di fat32 � anche nella sotto cartella?
Perch� in root il limite � pi� definito mentre nella sotto cartella 
dovrebbe essere superato.

 dovrebbe essere superato.
Guarda, se parli di root e di cartelle nella stessa frase, mi
mandi un po' in crisi....se potessi spiegare meglio cosa hai in
mente...
La root del mio sistema � sul disco interno della macchina,
quindi nel mio caso /dev/hdc6. Il mio sistema ha una sola
partizione montata quindi unicamente su "/". Ovviamente visto che
ospita linux, � formattata in un filesystem opportuno, ext3 nello
specifico.
Ora, parlando di HD esterno, collegato via usb, questo � dotato
di una unica partizione in fat32 (c'era chi chiedeva perch�....io
giro la domanda alla western digital) e viene visto disolito come
/dev/sda, a volte come /dev/sdb se qualcosa era gi� attaccatoad
un'altra usb.
La partizione unica del disco � quindi /dev/sda1.
E come ho gi� detto la monto in /media/wd.
Quindi probabilmente per "root" intendi la directory "/media/wd".
Forse.... dimmi tu.

 stavo scrivendo sopra... risultato filesystem letteralmente scomparso...
Ovviamente la periferica era in FAT32...
Comunque off-topicamente aggiungo che sono riuscito a recuperare tutto
grazie a PhotoRec... 

 Beh, diciamo che Ext2 permette di superare i 2GB solo su sitemi a 64
Uh?
rpoggi@Portatile001:~/testfile$ uname -a
Linux Portatile001 2.6.26-2-686 #1 SMP Mon May 11 19:00:59 UTC 2009 i686 
GNU/Linux
rpoggi@Portatile001:~/testfile$ dd if=/dev/urandom of=bigfile bs=100M 
count=50
50+0 records in
50+0 records out
5242880000
 bytes (5,2 GB) copied, 1646,85 s, 3,2 MB/s
rpoggi@Portatile001:~/testfile$
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 NTFS....
Dunque, ricapitolando le risposte emerse sono 2:
- ntfs
Compatibile con windows, leggibile e scrivibile da linux con il
driver nonricordoilnome.
� un formato proprietario e questo non mi piace moltissmo. Ma va
b�.
- ext3
Compatibile con linux. Leggibile e scrivibile da windows con il
driver nonricordoilnome.
� uno standard maturo su linux e avrei il vantaggio che posso
utilizzarlo nativamente, visto che praticamente sempre uso linux.
Se queste sono le alternative direi quindi che ext3 dovrebbe
essere la scelta migliore.
Per�, cosa mi dite di una terza via del tipo:
- 700 GB in ext3
- 300 GB in ntfs
Col tempo se dovessi riscontrare che comunque quei 300 GB fossero
inutilizzati e inutili anche da windows, li potrei comunque
rimpiazzare con una nuova prtizione formattata in ext3...
D'altra parte se in futuro dovessi averne bisogno, per non saprei
quale motivo al momento, avrei a portata di mano una partizione
da 300 GB utilizzabile "nativamente" da windows...
Cosa ve ne pare?
Io non mi intendo tanto di questi aspetti...anche in termini di
prestazioni e simili. Vi pare una buona scelta?
Spezzereste tutto quello spazio in ancora pi� partizioni,
seguendo criteri che magari ignoro?
Vi ringrazio intanto per le numerose risposte.  :-)

 - 300 GB in ntfs
Ritratto, direi che 200 GB in ntfs sono d'avanzo.
Ora ricordo che l'HD � formattato in FAT.
E purtroppo non ho abbastanza spazio per fare un backup completo:
ho fatto quindi un backup essenzialmente dei dati veramente
importanti, ma alcuni restano scoperti....ho deciso quindi di
prendermi il rischio di perderli.
L'idea �:
1- ridimensiono l'attuale partizione FAT a circa 200 GB oppure a
800 GB.
2- nello spazio vuoto creo una nuova partizione da 800/200 GB e
la formatto in ext3/ntfs
3- prendo i dati rimasti nello spazio ridimensionato (ancora fat32)
e li trasferisco nella nuova partizione, al sicuro.
4- Converto la partizione ridimensionata, da fat32 a ntfs.
Il punto 1 richiederebbe per scrupolo alcune operazioni
preliminari che vorrei eseguire *da linux*.
a- check del filesytem
b- defrag del filesystem fat
c- ripeto b
d- riverifico il punto a
Ok.
La domanda a questo punto � semplice:
mi serve un'utility che giri su linux in grado di:
- esaminare e fare il check del filesiste fat
- eseguirne il defrag
In rete non riesco a trovare utility linux per deframmentare un
volume in fat32....a me pare strano, ma tant'� non ho ancora
trovato nulla.
Continuando a cercare, spero che possiate/sappiate darmi una
risposta.
Grazie in anticipo come al solito  :-)

 trovato nulla.
Perch� non esiste.
O meglio, esiste, e si chiama cp, o tar, o ...
Copi i file su in file system vuoto, e miracolosamente essi sono
deframmentati.


 check del filesiste fat - eseguirne il defrag
[...]
questo script può deframentare (naturalmente lo usi a tuo rischio e pericolo)
#!/bin/sh
# defrag v0.06 by Con Kolivas <
ker...@kolivas.org
# Braindead fs-agnostic defrag to rewrite files in order largest to smallest
# Run this in the directory you want all the files and subdirectories to be
# reordered. It will only affect one partition.
trap 'abort' 1 2 15
renice 19 $$ > /dev/null
abort()
{
   echo -e "\nAborting"
   rm -f tmpfile dirlist
   exit 1
}
fail()
{
   echo -e "\nFailed"
   abort
}
declare -i filesize=0
declare -i numfiles=0
#The maximum size of a file we can easily cache in ram
declare -i maxsize=`awk '/MemTotal/ {print $2}' /proc/meminfo`
(( maxsize-= `awk '/Mapped/ {print $2}' /proc/meminfo` ))
(( maxsize/= 2))
if [[ -a tmpfile || -a dirlist  ]] ; then
   echo dirlist or tmpfile exists
   exit 1
fi
# Sort in the following order:
# 1) Depth of directory
# 2) Size of directory descending
# 3) Filesize descending
echo "Creating list of files..."
#stupid script to find max directory depth
find -xdev -type d -printf "%d\n" | sort -n | uniq > dirlist
#sort directories in descending size order
cat dirlist | while read d;
do
   find -xdev -type d -mindepth $d -maxdepth $d -printf "\"%p\"\n" | \
      xargs du -bS --max-depth=0 | \
      sort -k 1,1nr -k 2 |\
      cut -f2 >> tmpfile
   if (( $? )) ; then
      fail
   fi
done
rm -f dirlist
#sort files in descending size order
cat tmpfile | while read d;
do
   find "$d" -xdev -type f -maxdepth 1 -printf "%s\t%p\n" | \
      sort -k 1,1nr | \
      cut -f2 >> dirlist
   if (( $? )) ; then
      fail
   fi
done
rm -f tmpfile
numfiles=`wc -l dirlist | awk '{print $1}'`
echo -e "$numfiles files will be reordered\n"
#copy to temp file, check the file hasn't changed and then overwrite original
cat dirlist | while read i;
do
   (( --numfiles ))
   if [[ ! -f $i ]]; then
      continue
   fi
   #We could be this paranoid but it would slow it down 1000 times
   #if [[ `lsof -f -- "$i"` ]]; then
   #   echo -e "\n File $i open! Skipping"
   #   continue
   #fi
   filesize=`find "$i" -printf "%s"`
   # read the file first to cache it in ram if possible
   if (( filesize < maxsize ))
   then
      echo -e "\r $numfiles files left                                                            \c"
      cat "$i" > /dev/null
   else
      echo -e "\r $numfiles files left - Reordering large file sized $filesize ...                \c"
   fi
   datestamp=`find "$i" -printf "%s"`
   cp -a -f "$i" tmpfile
   if (( $? )) ; then
      fail
   fi
   # check the file hasn't been altered since we copied it
   if [[ `find "$i" -printf "%s"` != $datestamp ]] ; then
      continue
   fi
   mv -f tmpfile "$i"
   if (( $? )) ; then
      fail
   fi
done
echo -e "\nSucceeded"
rm -f dirlist 
-- 
Puppy Linux wiki:  
http://puppylover.netsons.org/dokupuppy
Puppy Linux Forum: 
http://puppylinux.ilbello.com
Windows me genuit, Ubuntu rapuere / tenet nunc Puppy Linux...

 questo script può deframentare (naturalmente lo usi a tuo rischio e pericolo)
Hai detto bene: "può".
Non è per nulla detto che lo faccia.
Appena comincia a girare, il primo file lo mette nello spazio che
trova libero, e già questo non è detto che sia contiguo.
Poi, appena cominci a cancellare il file cha hai appena spostato,
ottieni dello spazio libero non contiguo, che il prossimo cp va ad
occupare.
L'unico modo _certo_ è spostare tutto su un'altra partizione e poi
riportare indietro il tutto dopo aver svuotato il file system.


 riportare indietro il tutto dopo aver svuotato il file system.
Si ma se non hai a disposizione un'altra partizione d'appoggio �
l'unico modo che cartamente non funge  ;-)
Scherzi a parte... a me pare parecchio strano, ma mi sa tanto che
aveteragione: il defrag di un'unita fat da linux non si pu�
deframmentare.   Sarebbe anche curioso capire perch� ma va b�.
Ad ogni modo, ho cercato di aggirare il problema con la creazione
di un archivio tar e successiva compressione con bzip2:
cd /media/ext-hd
mkdir backup
cp -a * backup
rm -r backup/backup
tar cvf backup.tar backup
Peccato che per� se ne esca dicendo:
tar: backup.tar: Wrote only 4095 of 10240 bytes
tar: Error is not recoverable: exiting now
Indagher�...
� possibile comprimere al volo l'archivio?
per esempio per scompattare si usa:
tar -xvjf nome.tar.bz2
esiste il corrispondente
tar -cvjf nome.tar nome
O qualcosa del genere?

 Indagher�...
Ovvio: scordavo di essere su fat...la dimensione dei files �
limitata a 4 GB circa, e quarda caso il file backup.tar
parzialmente creato � grosso proprio 4GB.
Mi pare ci fosse per� un'opzione di tar per creare tot archivi da
una directory impostandone la dimensione... in tal modo dovrei
cavarmela creando 6 o 7 archivi .tar ed in seguito comprimerli
con bzip2...se riuscissi a restare sotto i 14/15 GB dovrei
riuscire a spostare il tutto.
Saluti


 O qualcosa del genere?
Esiste sicuramente man tar.


 riuscire a spostare il tutto.
Continua ad esistere man tar.
Opzioni:
  -M per il multivolume.
  -L per indicare la dimensione del volume.
  -F per eseguire uno script che rinomina il tar ad ogni cambio volume.


 Esiste sicuramente man tar.
Forse ho cercato male io, ma di bzip2 dice:
 -j, --bzip2
     filter archive through bzip2, use to decompress .bz2 files
Quindi mi sembrava che servisse solo per decomprimere...non per
comprimere, mentre quando parla di gzip dice:
-z, --gzip, --ungzip
              filter the archive through gzip
Poi ci sarebbe anche:
--use-compress-program PROG
Ma non avendola mai usata....ed esempi nel man non ne vedo...
Ecco che ho chiesto: di solito chi � pratico di questi comandi li
ha aportata di rispsota  :-D
Per i miei scopi, faccio prima a farlo in due tempi, andando acomprimere
ora i vari tar....se dovessi cercare tutte le info precise andremmo per
lelunghe.
In ogni caso grazie mille...ogni intervento idea consiglio ecc � gradito :-)

 prestanti...
Usare direttamente tar, ad esempio, che � abbastanza intelligente
da non tentare di copiare il file di output nell'archivio. ;-)
tar cvjf pippo *
ti evita oltretutto la necessit� di raddoppiare lo spazio necessario.
S�, il -j o --bzip2 funziona in fase di archiviazione, non solo in
fase di estrazione.
Nel man hanno specificato che si usa per decoomprimere i file bz2 per
evitare che qualcuno usasse la vecchia sintassi -I.
Almeno, penso che sia per quello. ;-)


  -F per eseguire uno script che rinomina il tar ad ogni cambio volume.
Cercher� di pi� magari sull'opzione -F che mi pare interessante
in caso di automatismi.
Sinceramente penso che il man dovrebbe contenere qualche esempio
pratico in pi�...tante volte mi capita di leggerlo, trovare
l'opzione giusta, ma non avere conferme di come usarla se non
grazie ad una ricerca via google o al limite un post anche qui.

 E purtroppo non ho abbastanza spazio per fare un backup completo:
Beh, ma se i dati sono importanti tocca farlo. Forse la soluzione �
acquistare un hd gemello? :-)

 fase di estrazione.
Per questo spesso ritengo che il man sia una gran cosa per
ricordarsi rapidamente come si fa a fare qualcosa che si � gi�
fatto o che si fa spesso, ma quando invece si tratta di imparare
da zero un'operazione di cui non si sa nulla....per come la penso
io servono pi� esempi e puntualmente preferisco passare per
google.

 /media/ext-hd, giusto?
Giusto.
Oh, poi ci sarebbe da verificare i vari link, soft o hard, che
andrebbero gestiti, ma se si sta parlando di fat32, � un discorso
che al momento non serve.



Diciamo che L'HD in pi� c'� ma � tutt'altro che gemello:
si tratta di una chiavetta da 16 GB...il problema � che nell'HD
ci sono 26 GB...
Come avrai letto negli altri posts...b� alla fine per precauzione
sono ricorso alla archiviazione e compressione via tar+bzip2.
I 26 GB dovrebbero ridursi pesantemente.
Anche se sto notando che il processo di compressione � eterno...
Sono 2 o 3 ore che macina (pIV-3.2GHz, 512MB di ram), dopo aver
compresso il primo archivio, ho ben pensato di dare il seguente
comando:
# for i in 2 3 4 5 6 7; do echo compressing archive number $i \
                                   bzip2 backup-${i}.tar; done
compressing archive number 2
compressing archive number 3
Siamo ancora al pezzo numero 3....
Ogni archivio ricordo che pesa 4.2 GB circa.
Ma � normale... quasi quasi interrompo e provo a comprimere con
gzip gli archivi restanti dal 4 al 7....Facendo due conti e
sperando di stare sotto i 16 GB totali.
Cosa ne pensate?
Maledetto backup  :-\
Saluti!  :-D

 ci sono 26 GB...
Il discorso � che le uova in un paniere solo non ci possono stare.
Pensa se il paniere cadesse per terra: tu rimarresti senza uova.

 sperando di stare sotto i 16 GB totali.
Alla fine ho sforato di quasi 1.5 GB, comunque sono riuscito a
creare una backup compresso di quanto c'era nell'HD...alcuni
pezzi del backup li ho dovuti mettere in qualche GB che avanzava
sull'HD interno.
Bene...ora prima di procedere alla modifica dell'HD esterno avete
dei consigli circa accorgimenti per essere sicuri che in caso
qualcosa andasse storto, il backup sia completamente
ripristinabile?
Non so mi vengono in mante possibili corruzioni durante la
compressione/archiviazione...c'� un modo per verificare che sia
tutto in ordine, nonostante lo stato attuale del backup in forma
compressa e archiviata?
Grazie in anticipo.