Newsgroup: it.comp.os.linux.iniziare
Titolo: domanda concettuale

Salve, sempre io.
In Windows, se carico tanta roba dopo un po' il sistema si appesantisce 
credo a colpa delle DLL .
Corro lo stesso rischio su Linuz ?
Mi sto mettendo su tanta roba, compreso il Cedega .. non vorrei 
ritrovarmi punto e daccapo e formattare tutto..
Ciao e grazie

 Corro lo stesso rischio su Linuz ?
No, programmini in autostart a parte.
-- 
Windows 7 RTFM: Versione di Windows 7 per il *downgrade da Linux*

ted wrote:

Troppa roba (secondo me) non f� molto bene, da parte mia ho lo stretto 
necessario e fila tutto liscio.
-- 
'Non nobis Domine, non nobis sed nomini tuo da gloriam'
'Ex cha.o.s. non in corpo veritas est.'
"Noi creiamo idoli dai nostri concetti, ma la saggezza nasce dallo stupore" 
'S.G.'

 Mi sto mettendo su tanta roba, compreso il Cedega ..
non ha importanza quello che installi, ma quello che gira;
r
-- 
per snellire i processi non servirebbe annullare la prescrizione una 
volta iniziati? gli imputati non avrebbero motivi di tirarla per le 
lunghe (gli avvocati sï¿œ ;-P
Un Minuto Per Favore:
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net

 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)


Uso una Debian 64 bit su ext4.
Al boot ogni tot accessi mi fa` un check del filesystem che si conclude
positivamente dicendomi che e` frammentato allo 0.2% .
E' vero che sono pochi mesi che ho installato e che cancello pochi file,
ma mi dava l'idea che mentre controllava facesse anche una specie di
defrag, perche 0.2% e` proprio poco. Puo` essere?

 defrag, perche 0.2% e` proprio poco. Puo` essere?
No, non esistono ancora tool di defrag per ext4. L'unico defragger open 
source per Linux di cui sono a conoscenza ï¿œ per ext2 e non ï¿œ attivamente 
sviluppato da una vita. Il fatto ï¿œ che finchï¿œ un filesystem viene usato 
sotto il 60% della sua capacitï¿œ molto difficilmente verrï¿œ frammentato perchï¿œ 
le politiche di allocazione dei file possono operare al meglio.
La frammentazione si comincia a vedere quando il filesystem si riempie oltre 
al 100% e si eseguono numerose operazioni di scrittura e cancellazione.
Puoi fare la prova creandoti un filesystem di test su un file da 10MB e 
varie operazioni. Per esempio se vuoi vedere un filesystem molto frammentato 
puoi fare cosï¿œ:
zipmantp:~# cd /tmp/
zipmantp:/tmp# dd if=/dev/zero of=test bs=1024k count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0165754 s, 633 MB/s
zipmantp:/tmp# mkfs -t ext4 -T news test
mke2fs 1.41.9 (22-Aug-2009)
test is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2560 inodes, 2560 blocks
128 blocks (5.00%) reserved for the super user
First data block=0
1 block group
32768 blocks per group, 32768 fragments per group
2560 inodes per group
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
zipmantp:/tmp# mkdir mnt
zipmantp:/tmp# mount -o loop test mnt
zipmantp:/tmp# df
Filesystem           1K-blocks      Used Available Use% Mounted on
...
/dev/loop0                9584      4120      4952  46% /tmp/mnt
zipmantp:/tmp# COUNT=0; while touch $COUNT^C
zipmantp:/tmp# cd mnt/
zipmantp:/tmp/mnt# COUNT=0; while touch $COUNT ; do COUNT=$(($COUNT+1)); done
touch: cannot touch `2549': No space left on device
zipmantp:/tmp/mnt# rm *[02468]
zipmantp:/tmp/mnt# COUNT=0; while cp /bin/true $COUNT ; do 
COUNT=$(($COUNT+2)); done
cp: writing `372': No space left on device
zipmantp:/tmp/mnt# rm *[13579]
zipmantp:/tmp/mnt# dd if=/dev/zero of=temp
dd: writing to `mnt/temp': No space left on device
1881+0 records in
1880+0 records out
962560 bytes (963 kB) copied, 0.0108113 s, 89.0 MB/s
zipmantp:/tmp/mnt# df
Filesystem           1K-blocks      Used Available Use% Mounted on
...
/dev/loop0                9584      9584         0 100% /tmp/mnt
zipmantp:/tmp/mnt# rm [357]*
zipmantp:/tmp/mnt# while dd if=/dev/urandom of=pil$COUNT bs=64k count=1 ; do 
COUNT=$(($COUNT+1)) ; done
zipmantp:/tmp/mnt# cd ..
zipmantp:/tmp# umount mnt/
zipmantp:/tmp# fsck.ext4 -f -v test
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
      167 inodes used (6.52%)
       17 non-contiguous files (10.2%)
        1 non-contiguous directory (0.6%)
          # of inodes with ind/dind/tind blocks: 0/0/0
          Extent depth histogram: 156/1
     2548 blocks used (99.53%)
        0 bad blocks
        1 large file
      156 regular files
        2 directories
        0 character device files
        0 block device files
        0 fifos
        0 links
        0 symbolic links (0 fast symbolic links)
        0 sockets
--------
      158 files


 oltre al 100% e
   ^^^^^^^^^^^^^
Sicuro sicuro di quello che dici? :-P
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Sicuro sicuro di quello che dici? :-P
Beh, con Linux sai che anche questo ï¿œ possibile... se dai un df da utente e 
ti da il filesystem al 100%, con root si puï¿œ ancora scrivere, quindi 
tecnicamente sto scrivendo oltre al 100%...
Uno Zippo che fa free-climbing sugli specchi...


 
Dove le compri le ventose?
Quelle che uso io scricchiolano da matti, e non le posso
usare la notte per non disturbare la famiglia.
