Pulizia e ottimizzazione di Microsoft Windows Vista

[bist]

Originariamente inviato da -fidel-

Il fatto che la frammentazione di un filesystem come NTFS sia "coperta" dalla velocità di lettura dei nuovi hard disks (leggi SATA /SATA 2) non vuol dire che la framentazione non esista.

Che esista non c'è dubbio! Ma se non produce sti gran effetti, il problema dov'è?

Poi è da tanto che cerco in rete perché secondo i linuxari i loro FS non si frammentano, a me pare impossibile, che magari l'accesso sia più veloce e allora si senta meno la frammentazione è una cosa, ma non capisco come faccia a non frammentarsi un FS se lo si usa nel modo installo/cancello/scarico/cancello/ecc...

Francamente a me non accade questo. Dipende forse da che versione di reiserfs hai. Io sto usando l'ultima versione (non la reiser4, l'ultima della serie 3) e va benissimo, l'unico neo è appunto a velocità di cancellazione di molti files piccoli, ma siamo nell'ordine dei 5 secondi, non dei 1/2 minuti

Stessa versione mi pare, forse non l'ultimissima, cmq la cartella di cui parlo è quella dell'albero del Portage di Gentoo. Adesso però non ho più Linux nel PC quindi non posso ricontrollare.

[-fidel-]

Originariamente inviato da HenryTheFirst

spesso raggiungo i limiti di capacità degli HD, ma non noto nessun decadimento in termini di prestazioni.

Non me ne parlare, sono stato per 4 mesi con 50 mega di spazio libero sulla partizione home, su un totale di 67 giga di partizione
Il bello è che le prestazioni erano identiche ad ora che ho 16 giga liberi

[bist]

Decadimento di prestazioni? Io vorrei vedere dei test, perché mi sembrano dei gran luoghi comuni questi sul registro (che peraltro non mi piace, ma non certo per le prestazioni, piuttosto il rischio di incasinamenti se i gli installer dei programmi sono fatti male - il che non è raro).

Sinceramente non mi fido di questi programmi dopo averne passate di brutte con Win 98 (magari era colpa dell'OS e non dei registry cleaner ), se ci sono chiavi e dati inutilizzati nel registro andrà a gravare sullo spazio su HD, ma sulle prestazioni? In che modo?

[MiKeLezZ]

Ci avrei scommesso che i linuxari ce l'avevano più lungo :-)

In ogni caso questo è il mio disco dati, pieno al 99% da 5 mesi (78k files di cui molti sono spesso cancellati, spostati, rimpiazzati)

Uuuh.... che frammentazione incredibile... inutile dire che non l'ho mai deframmentato, essendo insufficiente lo spazio per farlo.

Ormai sembra che non si abbiano più argomenti per attaccare Windows, così ce li si inventa.
Mi ricordo all'uscita di XP che NTFS era elogiato come grossa innovazione, in cui la frammentazione non portava più con se grosse perdite prestazionali (in effetti è proprio così)... ora, è una merda.

[-fidel-]

Originariamente inviato da bist

Che esista non c'è dubbio! Ma se non produce sti gran effetti, il problema dov'è?

guarda, autoquoto una frase che ho detto prima:

Originariamente inviato da -fidel-

Troppo comodo poi affidarsi alla potenza hardware per colmare il gap prestazionale, questo è un trend dannoso (vedi anche in moltissimi videogiochi per esempio), poi ci lamentiamo che per far girare il nuovo gioco o il nuovo SO ci voglia un PC nuovo...

Ma poi non è solo quello il problema, ci metterei anche uno stress aggiuntivo per l'hardware, nel nostro caso l'apparato meccanico dell'hard disk che "trita" alla grande: non a caso su linux il pc è molto pià silenzioso (lo hanno subito notato anche tutti quelli a cui ho installato Suse sul loro PC/notebook.

Originariamente inviato da bist

Poi è da tanto che cerco in rete perché secondo i linuxari i loro FS non si frammentano, a me pare impossibile, che magari l'accesso sia più veloce e allora si senta meno la frammentazione è una cosa, ma non capisco come faccia a non frammentarsi un FS se lo si usa nel modo installo/cancello/scarico/cancello/ecc...

Non è impossibile, anzi è documentato. Un attimo che cerco la documentazione che ho salvato qualche tempo fa.

EDIT: puoi cominciare leggendo qui:

http://trieste.linux.it/node/13

[Khronos]

mh. ho 2 dischi. un Eide e un Sata1. entrambi NTFS. e sotto c'ho diskeeper, che mi deframmenta i dischi quando c'e' bisogno. prestazioni sempre le stesse. registro? ho provato a toccarlo con 3 software, tutti e 3 me l'hanno buttato a puttane. indi non lo tocco piu' tranne che con la manina.

[-fidel-]

Originariamente inviato da MiKeLezZ

Ci avrei scommesso che i linuxari ce l'avevano più lungo :-)

Ti sbagli. Qui si parla di fatti sulla framentazione di un FS.

Originariamente inviato da MiKeLezZ

In ogni caso questo è il mio disco dati, pieno al 99% da 5 mesi (78k files di cui molti sono spesso cancellati, spostati, rimpiazzati)

Uuuh.... che frammentazione incredibile... inutile dire che non l'ho mai deframmentato, essendo insufficiente lo spazio per farlo.

Ormai sembra che non si abbiano più argomenti per attaccare Windows, così ce li si inventa.
Mi ricordo all'uscita di XP che NTFS era elogiato come grossa innovazione, in cui la frammentazione non portava più con se grosse perdite prestazionali (in effetti è proprio così)... ora, è una merda.

Dal tuo screenshot si evince che, ad occhio, hai un buon 10/15% di patizione particolarmente frammentata, e comunque uno screenshot di quel tipo non dimostra assolutamente nulla, visto che non si sa nulla sull'uso dell'HD. Se, ad esempio, installo qualche gioco da diversi giga sul disco, oppure una raccolta di files grandi, e da lì non li tocco, la frammentazione non esiste in pratica.
Del resto, se con Vista la deframmentazione è di default pianificata 1 volta a settimana, un motivo ci sarà non credi? Infatti alla MS sanno (visto che lo hanno inizialmente copiato HPFS, poi "espanso") che la frammentazione della partizione è un problema esistente sul loro filesystem. ed è confermato dai vari test fatti su tale partizione (cercali con Google, non avrai problemi a trovarne).
Per qualche spiegazione più precisa, ti rimando a questo articolo:

http://users.dimi.uniud.it/~giorgio....cs/buffon.html

quoto la perti che più interessa a noi ora:

Il centro di comando del file system NTFS è la MFT. Essa è analoga alla file allocation table nel file system FAT perché MFT mappa tutti i file e le directory sul disco, inclusi i metadata files dell’NTFS stesso. La MFT è divisa in unità discrete chiamate records. In uno o più record, NTFS registra i metadati che descrivono un file o le caratteristiche di una direcory (informazioni sulla sicurezza e altri attributi come sola lettura o nascosto) e la loro locazione sul disco. Sorprendentemente la MFT è un file che NTFS mappa usando dei record all’interno della MFT stessa. Questa struttura lascia la possibilità alla MFT di espandersi oppure di restringersi.

NTFS internamente identifica i file e le directory usando la loro posizione del record che descrive l’inizio dei loro metadati all’interno della MFT. Per esempio, i file metadata che compaiono nella Tabella 1 hanno un preassegnato indirizzo di partenza (base) per il record che li identifica nella MFT.

I record sono solitamente di dimensione 1Kb in un disco formattato con Windows NT 4.0, ma possono essere anche più grandi.

Il file $MFTMIRR è un file di complemento, in caso di disastri al file system, per la prevenzione di perdita di dati. Esso contiene la copia dei primi 16 record della MFT. NTFS lo registra a metà del disco circa mentre la MFT è all’inizio dello stesso. Se NTFS ha un problema nella lettura di MFT, esso si riferisce ad un duplicato. La locazione della MFT e della sua copia sono registrate nel boot record del disco, un file da 512 bytes posto all’inizio del disco stesso.

L’accesso ai dati della MFT gioca un ruolo base sul discorso performance su un disco NTFS, così NTFS cerca delle soluzioni per accedere alla MFT in modo più rapido possibile. Dato che la MFT è un file residente su volume NTFS esso può ingrandirsi e rimpicciolirsi e quindi frammentarsi. Questa frammentazione si verifica perché NTFS non può allocare in anticipo lo spazio che la MFT occuperà. Quando la MFT cresce e qualche altro file occupa lo spazio oltre la sua fine, la MTF deve guardare altrove sul disco per avere dello spazio libero.

L’accesso più veloce si realizza quando vengono fatte delle operazioni sul disco in maniera sequenziale ma, una MFT frammentata significa che NTFS ha bisogno di più letture per accedere, ad esempio, ad un record e questo può portare ad un abbassamento delle performance. Per evitare questo, NTFS crea una regione di cluster attorno alla fine della MFT dove file e directory non possono essere memorizzati. In questo modo si dà la possibilità alla MFT di crescere e/o ridursi senza troppe difficoltà. Quando lo spazio libero sul disco comincia a scarseggiare, NTFS rilascia un po’ dello spazio attorno alla fine della MFT per altri usi. Questo però porta la MFT ad correre un grosso rischio di frammentazione in un disco che peraltro è già al limite delle sue capacità. C’è da dire inoltre che NTFS non lascia deframmentare a tool appositi la MFT.

EDIT: nessuno sta dicendo qui che NTFS è "una merda", quindi meglio non mettere in bocca agli altri cose mai dette, si sta parlando del problema frammentazione e quanto questo intacca le performance della partizione, l'usura meccanica dell'hard disk e, perchè no, l'impatto sul sistema di una deframmentazione automatica a settimana.
Non stiamo parlando invece della bontà o meno dell'intero filesystem.

EDIT 2: Se mastichi un po' di inglese, ti consiglio anche la seguente lettura:

http://www.digit-life.com/articles/ntfs/

Ti fa capire ancora meglio del pezzo quotato prima, come mai (anche dal tuo screenshot si evince bene) hai una parte iniziale (che è un buon 10/15%, ma la dimensione non è sempre la stessa su tutti gli HD, dipende da che tipo di files hai) così tanto frammentata ed il resto dell'HD quasi contiguo, inframezzato ogni tanto da una striscia rossa.
Ad occhio, penso che hai molti files di grandi dimensioni sulla tua partizione.

[patanfrana]

Originariamente inviato da simon71

Sono convinto che se si usasse MacOs come si usa Win pure lui diventerebbe moooltooo instabile

Mi dispiace, ma ti sbagli: da quando uso Tiger, avrò installato e disinstallato almeno 200 programmi, per provarli, decidere se mi servivano e poi spesso cancellarli: le prestazioni non sono mai calate di una virgola e non ho mai avuto la necessità di formattare e reinstallare da zero.
L'installazione/disinstallazione in MacOsX non lascia strascichi, quindi le prestazioni nel tempo non peggiorano.
Come dici tu, se facessi la stessa cosa con Xp (ma non credo che con Vista la cosa sia cambiata poi molto), avrei un SO decisamente appesantito dopo 6 mesi di utilizzo costante, con una discreta necessità di formattare per farlo tornare ad una resa umana.

[MiKeLezZ]

EDIT 2: Se mastichi un po' di inglese, ti consiglio anche la seguente lettura:
http://www.digit-life.com/articles/ntfs/
Ti fa capire ancora meglio del pezzo quotato prima.

Sì, infatti non ho avuto difficoltà a trovare queste due frasi:
- NTFS prevents fragmentation
- NTFS doesn't suffer from it

[-fidel-]

Originariamente inviato da MiKeLezZ

Sì, infatti non ho avuto difficoltà a trovare queste due frasi:
- NTFS prevents fragmentation
- NTFS doesn't suffer from it

?????

Leggi meglio, invece di cercare il testo "fragmentation" nella pagina...
Ah, poi citare 4 parole in un testo di diverse pagine non è una buona pratica.

Let's return to one interesting enough and important moment - NTFS fragmentation and defragmentation. The situation with these two concepts at the moment can not be called satisfactory in any way. At the very beginning it was said that NTFS is not subject to file fragmentation. It is not exactly so and the statement was changed - NTFS prevents fragmentation. It is not exactly so either. That is it certainly prevents but... It is already clear that NTFS is a system which is predisposed to fragmentation inspite of official statements. But it doesn't suffer from it. All internal structures are constructed in such way that fragmentation does not hinder to find data fragments fast. But it doesn't save from the physical effect of fragmentation - waste disk heads motions.

To the source of the problem...

As it is known the system fragments files the best way when the free space is being ended, when it is necessary to use small-sized unused space remained from other files. The first NTFS property which directly promotes serious fragmentation appears here.
NTFS disk is divided into two areas. In beginning of the disk there is MFT area - the area where MFT grows (Master File Table). The area occupies minimum 12% of the disk, and the data record in this area is impossible. It is made not to let MFT be fragmented. But when all remaining disk is being filled in - the area is reduced twice. And so on. Thus we have not single pass of the disk ending, but several. In result if NTFS works at the disk filled on about 90% - fragmentation grows greatly.
The incidental result - the disk filled more than on 88% is almost impossible to be defragmented - even defragmentation API cannot transfer the data in MFT area. It is possible that we will not have free space for a manoeuvre.
NTFS works and works and is fragmented - even in the case of free space is far from exhausting. This is promoted by the strange algorithm of finding free space for file storage - second serious omission. The action algorithm at any record is like this: some definite disk range is taken and filled in with a file. It is done by the very interesting algorithm: at first large unused space is filled in and then small one. I.e. the typical allocation of file fragments according to the size on fragmented NTFS looks so (sizes of fragments):
16 - 16 - 16 - 16 - 16 - [back] - 15 - 15 - 15 - [back] - 14 - 14 - 14.... 1 - 1 - 1 -1 - 1...
So the process goes up to most small-sized unused space in 1 cluster, in spite of the fact that on the disk there are also much larger pieces of free space.
Recall compressed files - at active overwriting of the large volumes compressed information on NTFS the huge quantity of "holes" are because of reallocation ñompressed cluster groups on the disk. If any file area began to be compressed better or worse, it is necessary either to take it from a continuous chain and to place in another place or to strap in size reserving unused space.
It is impossible to say that NTFS prevents file fragmentation. On the contrary it fragments them with pleasure. NTFS fragmentation can surprise any person familiar with file system operation in half a year of work. Therefore it is necessary to launch defragmentation. But here all our problems are not ended, they only start...

Questo è anche il motivo per cui l'hard disk con Win "trita" alla grande.
Certo, passi in avanti sono stati fatti (soprattutto comparati con Fat32), ma il problema della frammentazione è ancora molto presente (infatti, ripeto per l'ennesima volta, con Vista la deframmentazione è pianificata di default 1 volta a settimana).

EDIT: come si capisce bene da tutto il pezzo quotato (non dalle singole frasi da te bellamente estrapolate) la frammentazione non incide (la partizione "non soffre") sul seek time del blocco, ma essendo tali blocchi più "sparsi" di quello che ci si aspetterebbe, la testina dell'hard disk "saltella" più del dovuto, con tutte le conseguenze del caso (incluso il calo di performance ovviamente).
Certamente più l'HD è veloce a muovere la testina, più il calo di performances dovuto alla frammentazione si riduce, ma come detto prima non è buona prassi colmare il gap prestazionale con la potenza dell'hardware.

[shez]

Originariamente inviato da patanfrana

Mi dispiace, ma ti sbagli: da quando uso Tiger, avrò installato e disinstallato almeno 200 programmi, per provarli, decidere se mi servivano e poi spesso cancellarli: le prestazioni non sono mai calate di una virgola e non ho mai avuto la necessità di formattare e reinstallare da zero.
L'installazione/disinstallazione in MacOsX non lascia strascichi, quindi le prestazioni nel tempo non peggiorano.
Come dici tu, se facessi la stessa cosa con Xp (ma non credo che con Vista la cosa sia cambiata poi molto), avrei un SO decisamente appesantito dopo 6 mesi di utilizzo costante, con una discreta necessità di formattare per farlo tornare ad una resa umana.

Peccato che per Mac 200 programmi forse non esistono nemmeno

[213]

Avrei un apiccola domanda in merito all'installazione di Vista: attualmente ho installato su un raid 0 Windows XP come SO, vorrei formattare il Raid e ricrearlo (sempre Raid 0) e fare un'installazione pulita di Vista Home Premium. La procedura di installazione, ossia il caricamento tramite F6 dei driver per i controller e tutto il resto è uguale come per XP o ci sono novità? Ci sono accorgimenti speciali da seguire? Grazie per le eventuali risposte.

[trapanator]

windows vs linux vs macosx vs beos...

[bonzuccio]

Originariamente inviato da MiKeLezZ

Uuuh.... che frammentazione incredibile...

Secondo me quella zona tutta rossa all'inizio è proprio il registro.. il defragg pure lo salta a piè pari

[bist]

Non è impossibile, anzi è documentato. Un attimo che cerco la documentazione che ho salvato qualche tempo fa.

EDIT: puoi cominciare leggendo qui:

http://trieste.linux.it/node/13

Ora non ho il tempo di leggerlo tutto ma mi pare che si parli del modo in cui ReiserFS limiti la frammentazione interna, qui però stiamo parlando di frammentazione esterna.

[-fidel-]

Originariamente inviato da trapanator

windows vs linux vs macosx vs beos...

Naaa nessun flame, si stanno analizzando solo delle "peculiarità" di NTFS, almeno per quanto mi riguarda, non si sta dicendo "linux rulez" o roba simile, visto che nonc'entra nulla con la discussione.

[-fidel-]

Originariamente inviato da bist

Ora non ho il tempo di leggerlo tutto ma mi pare che si parli del modo in cui ReiserFS limiti la frammentazione interna, qui però stiamo parlando di frammentazione esterna.

No no si parla anche di quella esterna (si parla infatti tra l'altro di "extents", presenti anche in NTFS).
La frammentazione di NTFS infatti è critica per la MTF, visto che per quella esterna è organizzata con gli "extents".
Gli extens sono supportati in reiserfs dalla versione 4, peccato che la sua diffusione non sia molto alta, visto che il progetto reiserfs, dopo l'arresto di Hans Reiser per la vicenda della scomparsa della moglie, ha subito non solo un forte rallentamento, ma soprattuto ha perso il supporto da parte delle distro big che si affidavano da anni a questo filesystem (in primis Novell/Suse, dalla 10.2 viene proposto ext3 di default invece di reiserfs - ma è solo uno scenario di passaggio, visto che reiserfs è considerato ormai "in un vicolo cieco" per gli sviluppi futuri).
Grandi miglioramenti si avranno a breve con ext4 (sarà a 64 bit), mentre ottimi filesystems sono XFS e JFS, oltre ai più conosciuti ext3 (ormai però datato, si aspetta con impazienza la versione 4 a breve) e reiserfs (la 4 è davvero buona, la 3 è riconosciuta per la sua stabilità, ma è stata sorpassata in quanto a performance da XFS ad esempio e dalle prime beta di ext4, senza considerare che reiserfs ha un tempo di montaggio più lungo rispetto ai concorrenti, ed ecco spiegata la maggiore lentezza di avvio di una distro suse formattata tutta con reiserfs).
Comunque, ext4 penso sarà il filesystem più usato per linux (visto anche il supporto che sta avendo dalle distro "mainstream", ora ci si è messa anche Suse che aveva puntato (comunque a ragione IMHO) su reiserfs. Peccato per Hans Reiser...................

EDIT: per Suse, non si esclude in un prossimo futuro il passaggio al filesystem OCFS2 (Oracle Cluster File System). Vedremo...

EDIT 2: Al prossimo format passo sicuramente a XFS, è piuttosto impressionante come prestazioni:

http://www.debian-administration.org/articles/388

L'unico neo è una maggiore probabilità di perdita dati nel caso in cui il PC si spegne (es. calo di tensione sulla presa elettrica) mentre si sta scrivendo sul disco, ma è un problema più critico nei server (comunque normalmente evitato tramite l'uso di un gruppo di continuità), per l'uso domestico mi interessa poco (al peggio ricopio il file, ma francamente non mi è mai capitato di trovarmi in un simile scenario, se non per appositi test di affidabilità dei filesystems).
Del resto è molto consigliato per i server proprio per la sua velocità e scalabilità, penso quindi che andrà più che bene per il mio uso domestico, e poi XFS è presente nel formattatore di Suse, quindi vado sereno

[bist]

Originariamente inviato da -fidel-

No no si parla anche di quella esterna (si parla infatti tra l'altro di "extents", presenti anche in NTFS).
La frammentazione di NTFS infatti è critica per la MTF, visto che per quella esterna è organizzata con gli "extents".

Ma ancora non capisco perché ReiserFS/ext3/ext2 e tutti gli altri FS usati su Linux non debbano soffrire di frammentazione esterna, o meno rispetto a NTFS! Oltre a una certa soglia è inevitabile che il disco si frammenti. Ad esempio se ci sono 10 MB liberi, si cancellano 30 files da 10 MB messi a caso, poi si alloca un file da 300 MB... come fa questo file a non essere frammentato? E così via.

EDIT 2: Al prossimo format passo sicuramente a XFS, è piuttosto impressionante come prestazioni:

A me ispira ZFS ma tanto rimarrò con NTFS tutta la vita, non usando altro che Win ormai

[-fidel-]

Originariamente inviato da bist

Ma ancora non capisco perché ReiserFS/ext3/ext2 e tutti gli altri FS usati su Linux non debbano soffrire di frammentazione esterna, o meno rispetto a NTFS! Oltre a una certa soglia è inevitabile che il disco si frammenti. Ad esempio se ci sono 10 MB liberi, si cancellano 30 files da 10 MB messi a caso, poi si alloca un file da 300 MB... come fa questo file a non essere frammentato? E così via.

Mi pareva di averlo detto un po' di post fa
Con reiserfs, ad esempio, la frammentazione si mantiene sempre sotto il 5%, a meno che si ha meno del 3% (circa, non ricordo di preciso) di spazio libero disponibile, in questo caso la frammentazione sale oltre il 5% (per poi tornare sotto la soglia dopo che si è liberato spazio)
Per quanto riguarda la frammentazione esterna, NTFS si comporta bene grazie agli extents (come del resto gli altri filesystems moderni), i problemi di frammentazione nascono con la MTF e con la frammentazione interna.
Come detto nell'articolo che ho postato prima nella risposta a Mikelezz, quello non è un problema da poco: per quanto il seek time del blocco non è praticamente affetto da quella frammentazione, la testina del'HD inizia presto a "saltare" da una parte all'altra passando da un extents all'altro, causando tra l'altro il "grattugiamento" tipico dei sistemi Win (l'HD viene stressato più del dovuto, ed il calo di performance è inevitabile se non si effettua una deframmentazione della MTF, poi se hai un HD particolarmente veloce te ne accorgi poco - a parte il casino che fa l'HD in lettura/scrittura in continuazione - ma come detto non è bello riempire i gap prestazionali con la potenza hardware, se ancora vogliamo parlare di ottimizzazione ovviamente).

Inoltre, NTFS non ha grandissime prestazioni rispetto ad esempio ad XFS, ma certamente ha i suoi vantaggi (del tipo essere un filesystem "pluggable", come reiserfs 4 - ma quest'ultimo è arrivato dopo - quindi ad esempio il modulo di cifratura del FS è un semplice plugin ed è presente di default).
Come prestazioni, penso che XFS sia tra i migliori (se non il migliore) considerando tutti gli aspetti d'uso di un filesystem.

[213]

Originariamente inviato da 213

Avrei un apiccola domanda in merito all'installazione di Vista: attualmente ho installato su un raid 0 Windows XP come SO, vorrei formattare il Raid e ricrearlo (sempre Raid 0) e fare un'installazione pulita di Vista Home Premium. La procedura di installazione, ossia il caricamento tramite F6 dei driver per i controller e tutto il resto è uguale come per XP o ci sono novità? Ci sono accorgimenti speciali da seguire? Grazie per le eventuali risposte.

nessuno sa rispondermi?