Newsgroup: it.comp.os.win.windows7
Titolo: Auslogics disk defrag vs windows 7 defrag

Ciao.
Avevo intenzione di provare ad usare l'auslogics disk defrag perché ho
notato un leggero degrado si prestazioni in quanto la partizione di
windows 7 è un bel po' piena, anche se ho eseguito una
deframmentazione con l'utility di windows.
Anche se mi hanno sconsigliato di usare deframmentatori differenti.
Però ho notato anche che l'auslogics ha un bel po di opzioni in più
per ottimizzare il suo compito, sicuramente è più avanzato.
Secondo voi?
Grazie.

"kj82"   ha scritto nel messaggio

Certamente sai che Windows 7 ha una deframmentazione in background 
pianificata e programmabile.
Se viene usato un altro software di deframmentazione (non importa quale dato 
che io ho una mia personale opinione in merito...) occorre disabilitare la 
pianificazione del defrag di Windows 7 altrimenti tu deframmenti con un 
algoritmo di un altro software , poi scatta il defrag di Windows 7 e 
deframmenta con il suo algoritmo ....e via ... si crea una 
sovrapposizione/incongruenza tra i dati.
Occorre scegliere.
Ma scegliere sapendo che , nella deframmentazione , non ci sono magie o 
segreti.
I dati coerenti vengono cercati con gli indici e messi in sequenza , semmai 
con un'approssimazione + 0 - alta o con una coerenza + 0 - alta.
Ma questa differenza di "impostazione" cosa pensi ti faccia guadagnare?
Da test miei le differenze tra i vari software portano a forbici 
differenziali dell'ordine dei decimi di secondo.....+ 0 -
Punto.
Nel file system NTFS inoltre questa grande deframmentazione non esiste.
C'è ma non è drammatica come lo era per il Fat/Fat32.
Ciao
-- 
Franco Leuzzi
Microsoft ® MVP
Windows Desktop Experience
franco...@mvps.org
http://blogs.dotnethell.it/franco/
 


Ciao,
appena una curiosit�.
Tralasciando l'algoritmo impiegato per la deframmentazione del disco; 
essendo l'obiettivo finale quello di rendere contigui i cluster cui sono 
allocate le parti del file; l'uso di un metodo o dell'altro non dovrebbe 
risentirne dal momento che i file gi� deframmentati non verrebbero pi� presi 
in esame; � cosi o sbaglio?
Ammesso che sia cosi, il conflitto fra i due algoritmi effettivamente dove 
starebbe? Io personalmente lo individuerei per quanto riguarda i file non 
ancora deframmentati; per� se � vero che l'handle del file quando � in uso 
non pu� essere usato da altri processi � anche vero che il programma di 
deframmentazione (se fatto bene) vedendo che quel handle non � disponibile 
passerebbe oltre ignorando il file che nel frattempo viene deframmentato 
dall'altro programma.
Bisognerebbe valutare se il software usato tiene conto di questi casi 
critici e si comporta quindi di conseguenza, non pensi anche tu?
-- 
http://www.blueware.it
bluewarewebstudio (skype) 

 critici e si comporta quindi di conseguenza, non pensi anche tu?
Tu, tecnicamente, poni delle basi sensate ma parti dal presupposto che tutti 
i tool di deframmentazione siano scritti in modo "sensato".
Quanti lo sono?
Ecco perchè , ovviamente senza scendere in dettagli troppo tecnici , ho 
affermato che si cerca un deframmentatore valido , lo si prova da solo e ci 
si attiene.
Usandone due sarebbe come avere due treni ed un solo binario.
Anche se i treni sono ben guidati e non si tamponano dovranno per forza 
procedere con attenzione e uno dietro l'altro.
IMHO.


 critici e si comporta quindi di conseguenza, non pensi anche tu?
la logica di questi software varia nel "posizionare" i file in un modo o 
nell'altro e nella scelta di quali file deframmentare o no.
 


Non credo; lo scopo di un deframmentatore � individuare la posizione del 
file e fare in modo che tutti i suoi cluster siano contigui, in modo tale da 
evitare che la testina di lettura/scrittura del disco salti qua e la per 
recuperare tutti i frammenti che compongono il file.
Un file deframmentato � contiguo; la testina di lettura/scrittura del disco 
non ha bisogno di saltare qua e la e di conseguenza la lettura del file non 
solo risulta lineare ma anche pi� veloce.
Se poi altri programmi fanno delle porcherie come quelle da te appena citate 
� un altro discorso. Fatto sta che un deframmentatore non ha alcun motivo di 
spostare un file da una posizione a un altra, a che pro poi? dal momento che 
l'accesso al file � uguale per tutti, in termini ti reperibilit� e non solo.


 reperibilità e non solo.
Ma quando la finirai di sparare IMMENSE cazzate?
 

 ha scritto nel messaggio 
news:hpfase$ttl$1...@tdi.cu.mi.it...

Definisci "cazzate"; motiva "cazzate".
PS: A scanso di equivoci (vedasi post iniziale), con l'espressione: "Fatto 
sta che un deframmentatore non ha alcun motivo di spostare un file da una 
posizione a un altra", si fa riferimento naturalmente a un file già 
deframmentato, di cui non ha motivo di essere processato.


 ha scritto nel messaggio 
news:AEGun.43269$Ua....@twister2.libero.it...

Un buon deframmentatore non si limita a deframmentare ma anche a compattare
i files in modo da lasciare il piu' possibile spazio libero "contiguo".
Questo lo fa anche il defrag MS.
Quindi un buon deframmentatore, se del caso, sposta i files e come se li 
sposta.
 

 ha scritto nel messaggio 
news:4bbb825a$0$820$4faf...@reader5.news.tin.it...

Definisci "compattare".


 ha scritto nel messaggio 
news:U7Mun.43421$Ua....@twister2.libero.it...

Puoi cercarlo sul dizionario se non ti e' chiaro.
 


Ti ho fatto una domanda, se questa è la tua risposta allora tutto quello che 
hai scritto poco sopra è privo di valore e assume un tono molto prossimo al 
polemico; tutto ciò dal momento che non sei in grado ne di argomentare, ne 
di motivare, ne di spiegare.
Ciò premesso: l'algoritmo di deframmentazione si limita a deframmentare il 
file: compattare un file, nel senso che intendo, non ha nessun legame con la 
deframmentazione.
Se ti rifiuti di fornirmi la tua definizione di "compattare" mi induci a 
ritenere che con compattare intendi la riduzione dello spazio occupato del 
disco da parte del file quindi comprimere il file (es algoritmo di 
compressione come zip).
La mia domanda quindi non aveva un tono prossimo alla polemica; la tua 
risposta purtroppo si, che ti piaccia o no.


 ha scritto nel messaggio 
news:CjNun.154860$9f6.2...@twister1.libero.it...

Non hai capito una beata fava, ho scritto compattare i files (s plurale)
significa che li mette uno affianco all'altro finche' ci riesce per liberare
spazio vuoto e QUINDI LI SPOSTA.
Dopo questa non argomentare piu', non ne vale la pena
parla delle cose che conosci.
 


Non sono in vena di polemica credimi; ma ti consiglio spassionatamente di 
mettere da parte quel tono da sapientone.
In primo luogo mettere affianco ciascun file come dici tu, (in modo contiguo 
aggiungo io) significa deframmentare; in secondo luogo SPOSTANDO I FILE non 
recuperi lo spazio sul disco; se i file occupato tot KB continueranno ad 
occupare tot KB anche dopo.
Compattare significa ridurre lo spazio su disco;  ma poichè lo spazio su 
disco è una costante; per ridurre lo spazio su disco devi COMPATTARE 
(=COMPRIMERE, ZIPPARE) i files.
Ma il processo di compressione, di "zippaggio" di un file non è compito di 
un deframmentatore.
Detto questo se vuoi continuare a fare il sapientone e avere aria da 
"superiore, superbo etc", fallo pure, ma non con me, perchè in caso 
contrario non esiterò a ignorare i tuoi post nei limiti e nelle modalità 
consentite dalla netiquette per i newsgroup.


 ha scritto nel messaggio 
news:DwOun.154893$9f6.2...@twister1.libero.it...

Prova a rileggere i miei post e trova dove ho scritto che libera dello 
spazio
su disco.
HO SCRITTO che aumenta lo spazio libero contiguo non lo spazio libero in 
assoluto.
Ed in ogni caso contestavo la tua affermazione che non sposta i files,
li sposta e come se li sposta.
 


Ok


 ha scritto nel messaggio 
news:AEGun.43269$Ua....@twister2.libero.it...

allora come funzione un deframmentatore:
1 - legge il layout.ini di windows
2 - identifica quali file sono i più usati
3- crea posto all'inzio del disco (ergo sposta i file alla fine o a metà)
4 - unisce i frammenti dei file da caricare più velocemente (più usati + 
boot) e li posiziona all'inizio del disco.
5 - fa lo stesso con il resto
6 - sposta i grossi file (diversi giga) DOPO il blocchi di file normali 
ormai deframmentati.
6bis - i deframmentatori intelligenti come mydefrag, lasciano tra queste 
zone (file di avvio, file usati, file nn usati, file grossi ecc) delle zone 
"vuote" in modo da diminuire la frammentazione generale man mano che si usa 
il pc.
e tu mi vinei a dire che un deframmentatore non ha nessun motivo di spostare 
file, anzi.. sopratutto GIA' deframmentato????
deframmentazione è sotto insieme si ottimizzazione, in un pc si cerca 
l'ottimizzazione, non la pure deframmentazione.
Neppure il defrag liscio di win evita di spostare i file... ANZI!!! legge 
tantissimo i layout.ini su cui basa appunto l'ottimizzazione!
 

 "AUMENTA lo spazio libero contiguo" (poni l'attenzione su AUMENTA).
Perdincibacco, io ho fatto tutte le scuole dell'obbligo, pero' adesso
mi sorge il dubbio che :
1: non sono piu' capace di parlare l'italiano
2: sto parlando con un extracomunitario
3: sto parlando con un italiano che pur avendo fatto le scuole dell'obbligo
    non conosce la lingua italiana.
Se un valora aumenta significa che prima era A e dopo diventa B dove B>A.
Prima del defrag il mio spazio libero contiguo era A,
dopo il defrag e' B.
E' chiaro a tutti, ma proprio a tutti e spero quindi anche a te che lo 
spazio libero
totale non cambia.
Se non e' chiaro ancora provo a scrivertelo nella lingua che comprendi,
dimmi pero' qual'e'.



Non vorrei sembrare improvvido a cimentarmi in una discussione che piu' 
che computeristica sta' diventando semantico-linguistica... ma - se 
posso - direi che avete ragione entrambi.
Cerco di spiegare il perche'.
Definiamo T come la quantita' di spazio totale nell'hd, con T=A+B+C, 
dove A e' lo spazio libero contiguo, B e' lo spazio occupato contiguo e 
C e' lo spazio occupato dai file frammentati... sarebbe piu' corretto 
definirle sommatorie di spazi, ma non complichiamo ulteriormente la 
faccenda.
E' abbastanza ovvio e ragionevole che ha ragione chi asserisce che prima 
e dopo la deframmentazione T deve rimanere costante; quindi, definendo 
con 1 e 2 gli stadi pre e post deframmentazione, vale A1+B1+C1=A2+B2+C2, 
con C2 uguale a zero nel caso di un software che deframmenti in maniera 
perfetta.
In questo senso IMHO ha ragione anche chi sostiene che lo spazio libero 
contiguo aumenta dopo la deframmentazione, in quanto e' ragionevole 
pensare che A1<A2, che B1<B2 e che C1>C2... altrimenti piu' che un 
software di deframmentazione avremmo a che a fare con un software 
incasinatore di hd!
Comunque riga'... state a discute del sesso degli angeli!! ;-)
Ciao!
Baio
-- 
Thermaltake Spedo A. P. - AMD Deneb 965 C3@4GHz 1.52v
MSI 790FX-GD70 - 4x2Gb Crucial Ballistix 7-7-7-24 13333
Sapphire 5870 Vapor-X - X-Fi Titanium Fatal1ty Pro
Crucial RealSSD C300 128Gb - Corsair TX750W


I file non deframmentati non vengono spostati! Non hanno motivo di essere 
spostati. Per inciso; se un hard disk ha 500.000 files non frammentati  e 
2000 frammentati; io non vado a spostare i 500.000 files che non sono 
frammentati; piuttosto vado a lavorare solo ed esclusivamente sui 2000 che 
lo sono; risparmiando fra l'altro anche tempo.
L'obiettivo finale è:  FARE IN MODO CHE TUTTI I FILE SIANO NON-FRAMMENTATI.


 NON-FRAMMENTATI.
sta roba è un deframmentazione oldstyle che sotto NTFS è I N U T I L E
L'unica cosa utile è quale file deve essere INTERO e dove!
ripeto: non capisci un cazzo.
il tuo obiettivo finale è non capire un cazzo di come funzioni un PC.
e lo dimostri in ogni tuo post. Ridicolo. Come il thread su MS-dos.... è ora 
che te ne stai zitto almento!!!!
mio dio i tuoi ragionamenti si basano su concetti di deframmentazione e 
ottimizzazione vecchi di 10 anni. 

 è un file di systema attivo se usi il prefetch.
LOL :D