defrag

[mrwolf1981]

ciao ragazzi,

prima di tutto volevo farvi tanti auguri

poi volevo chiedervi se c'è un modo x fare manualmente il defrag all'hd del mio ibook, senza aspettare che lo faccia lui in automatico. X' a mio avviso l'avvio si è un pò rallentato

[INeDiA]

ah lo fa in automatico?

[matteos]

si viene fatto in automatico con i file minori di 20MB se non ricordo male;per velocizzare le prestazioni lasciate il mac acceso di notte azionando così gli script di manutenzione,se non volete lasciarlo acceso potete usare onyx lo trovate su versiontracker.
le prestazioni migliorano sensibilmente.
ciao

[Marxaid]

frammentazione dei file sul system os x di derivazione *nix ???????

suvvia ragazzi siamo seri...

[mrwolf1981]

potreste essere più precisi pls, nn ho capito niente ricordatevi che sono un noob con il mac, l'ho preso da poco

[toshiman]

quoto in un 3d che avevo aperto un mese fa si arrivò alla conclusione che il defrag non si fa o non ce n'è bisogno... però sembra che non tutti siano daccordo...

[Marxaid]

allora lo spiegherò con parole semplici, un aneddotto.

"Durante uno dei miei viaggi mi sono ritrovato a fianco di un gentilissimo signore, giovane e dinamico funzionario d'impresa, che si apprestava ad eseguire sulla sua macchina il famigerato (vedremo presto perché) programma DeFrag. Questo programma mostra una bella matrice riempita di piccoli quadrati di tanti colori che si muovono in tutte le direzioni mentre il disco lavora intensamente e rumorosamente.

Non ho potuto resistere alla tentazione (questo signore non me ne vorrà troppo, spero, se si riconosce in questo articolo): dopo essermi complimentato per il suo bel portatile, gli ho chiesto, fingendo la più grande ignoranza, che cosa fosse quel bellissimo programma che io non avevo sul mio portatile. Con un'aria di superiorità mista a compassione ("il poveretto non ha il mio superbo programma") mi ha risposto che si trattava di uno strumento essenziale che bisogna lanciare di tanto in tanto per "fare andare la macchina più veloce", "deframmentando il disco". Ha proseguito ripetendomi a memoria gli argomenti che si ritrovano nei manuali Windows: più si utilizza il disco, più questo si "frammenta", e più il disco è frammentato più la macchina è lenta, ed è per questo motivo che egli fa coscienziosamente girare DeFrag ogni volta che può.

A questo punto ho tirato fuori il mio computer portatile, che non utilizza Windows ma GNU/Linux (una versione libera gratuita e molto efficace di Unix sviluppata grazie agli sforzi congiunti di migliaia di persone su Internet), e gli ho detto, con un'aria molto stupita, che tutto quello che mi aveva detto mi sorprendeva enormemente: sul mio portatile il disco è molto poco frammentato e più si utilizza, meno si frammenta. Il nostro funzionario, un po' meno a suo agio, ha ribattuto che il suo portatile utilizzava l'ultima versione di Windows, prodotto dalla più grande azienda di software al mondo, e che dovevo ben sbagliarmi da qualche parte.

A questo punto, ho cercato di fargli dimenticare per un istante la propaganda che l'aveva intossicato fino ad allora spiegandogli semplicemente il problema della deframmentazione: quello che segue è un breve riassunto di una piacevole conversazione che è durata una buona mezzora.
Voi sapete probabilmente che i vostri dati sono conservati in archivi, ormai universalmente chiamati "file'', memorizzati sul disco rigido del calcolatore. Questo disco rigido è come un gigantesco armadio a cassetti: ogni cassetto ha la stessa capienza (di solito 512 byte) e ciascun disco contiene, ai giorni nostri, alcuni milioni di cassetti. Se i dati che vi interessano sono sistemati in cassetti contigui, vi si può accedere più rapidamente che se sono sparpagliati (si dice allora frammentati) un po' dappertutto all'interno dell'armadio. Non c'è nulla di strano, in questo, ci succede ogni giorno quando dobbiamo trovare un paio di calzini: si fa prima se sono tutti e due nello stesso cassetto. Siamo dunque d'accordo che è meglio un armadio ben ordinato che un armadio nel caos. Adesso il problema è di sapere come fare per mantenere l'armadio ben ordinato quando lo utilizziamo.

Immaginiamo un ministero che conserva i suoi dossiers in un enorme armadio con milioni di cassetti: per le stesse ragioni che si dicevano prima, sarà meglio che i documenti riguardanti uno stesso dossier si trovino, per quanto possibile, ordinati in cassetti contigui. Ora voi dovete assumere una segretaria e vi si presentano due candidate dalle abitudini molto diverse fra loro: la prima, quando un dossier va eliminato si limita a vuotare i cassetti, e quando un nuovo dossier arriva lo separa in piccoli fascicoli della misura di un cassetto e sistema ogni fascicolo a caso nel primo cassetto vuoto che trova nell'armadio. Quando le fate notare che così è molto difficile ritrovare subito tutti i documenti di uno stesso dossier, risponde che in effetti lei prevede di ingaggiare una dozzina di ragazzi che ogni fine settimana vengano per rimettere tutto in ordine. La seconda segretaria, invece, conserva sulla sua scrivania una lista dei cassetti vuoti contigui, e aggiorna la lista tutte le volte che una pratica viene chiusa e viene tolta dai cassetti; quando un nuovo dossier arriva, cerca nella sua lista una serie di cassetti vuoti contigui di capacità sufficiente ed è lì che mette il nuovo dossier. Cosí facendo, anche se c'è molto movimento, l'armadio rimarrà sempre ben ordinato. Non c'è dubbio che è la seconda segretaria che bisogna assumere, e il nostro giovane funzionario fin qui è d'accordissimo.

A quel punto, fu facile fargli osservare che Windows si comportava come la prima segretaria, ed aveva bisogno dei ragazzi che riordinano l'armadio (il programma DeFrag), mentre GNU/Linux, comportandosi come la segretaria brava, non ne aveva alcun bisogno. All'arrivo in stazione, il nostro gentile signore non era per niente contento: gli avevano insegnato che DeFrag "fa andare più veloce la macchina", mentre avevamo visto insieme che è piuttosto Windows che la rallenta!

In effetti, il problema della gestione efficace dei dischi è molto vecchio ed è da tempo che si sa bene come trattarlo (la prova è che Unix è molto più vecchio di Microsoft). E c'è ben peggio di DeFrag: purtroppo non c'è tempo per raccontarvi qui tutti gli aneddoti che lo riguardano, ma il programma ScanDisk, che è fatto per "riparare" i dischi, vi propone scelte incomprensibili il cui risultato è, troppo spesso, la distruzione pura e semplice della struttura del file system, mentre, prima del suo passaggio, i dati erano ancora recuperabili. Non soltanto questo è impossibile sotto Unix, a meno di prendere il disco a martellate, ma le tecniche corrette di gestione vengono insegnate nei corsi di base di informatica in università da più di un decennio. La semplice esistenza di un programma come DeFrag o peggio, i misfatti di ScanDisk in Window dovrebbero essere sufficienti a radiare Microsoft dalla lista dei suoi fornitori.

*****************


Come forse sapete, MacOS X ama molto l'ordine, al punto che periodicamente esegue alcune operazioni automatiche di "pulizia" del sistema sulla cui reale natura spesso aleggia un alone di mistero. Cerchiamo di vedere brevemente in che cosa consistono tali operazioni periodiche di pulizia e come siano configurabili.

MacOS X è dotato di tre procedure (script) automatiche di pulizia del sistema, denominate daily, weekly e monthly che, per i non anglofoni, significano "giornaliera", "settimanale" e "mensile". Tali script sono pensati per essere eseguiti periodicamente da cron, una utility di sistema (accessibile tramite il Terminale o con una comoda interfaccia grafica denominata CronniX) che attiva a scadenze regolari script e comandi ad essa segnalati. Di default, lo script daily viene eseguito tutte le mattine alle 2, lo script weekly ogni sabato mattina alle 3 e lo script monthly ogni primo giorno del mese alle 5 del mattino. Per chi fosse curioso, tali script si trovano, in una qualche forma, all'interno della cartella /etc/periodic.
Essi eseguono una certa serie di operazioni riguardanti la rotazione dei file di log, la cancellazione di file temporanei e cose del genere che sono in parte modificabili. Inoltre generano un output che può essere visionato dall'utente al fine di verificare se, nel corso di queste operazioni periodiche di manutenzione, ci siano stati dei problemi.
Per capire un po' bene come fare, esaminiamo da Terminale il file di configurazione di periodic, il comando che esegue all'atto pratico questi tre script periodici: tale file si chiama periodic.conf e si trova nella cartella /etc/defaults. Digitiamo pertanto

more /etc/defaults/periodic.conf

e sfogliamo il file usando i tasti freccia in su e in giù. Tutte le righe che iniziano con un # sono dei commenti e sono pertanto istruttive per il lettore ma non vengono eseguite.
La prima riga non commentata è la seguente:

periodic_conf_files="/etc/periodic.conf /etc/periodic.conf.local"

Essa stabilisce che il file /etc/defaults/periodic.conf che stiamo esaminando ora verrà ignorato qualora esista un file denominato /etc/periodic.conf, che a sua volta verrà ignorato se esiste un file denominato /etc/periodic.conf.local. Come mai questa bizzarria? Se per qualche ragione volete apportare delle modifiche alla configurazione del comando periodic non dovete assolutamente agire sul file /etc/defaults/periodic.conf, che anzi lascerete intonso, ma creerete un file /etc/periodic.conf oppure /etc/periodic.conf.local che modificherete a piacere e, in caso di problemi, cancellerete senza rimpianti, sicuri che il file originale di configurazione è sempre lì, immutato e funzionante, al suo posto.
La seconda riga non commentata recita

local_periodic="/usr/local/etc/periodic"

ed indica la cartella in cui andrete a piazzare eventuali script di "pulizia" realizzati da voi (se mai ne sentiste il bisogno). Così, se decidete di realizzare uno script di pulizia che chiamate "tutti_i_giorni_feriali" (e che faccia qualche cosa di utile per voi), lo salverete come /usr/local/etc/periodic/tutti_i_giorni_feriali e lo richiamerete, a mano da Terminale o tramite cron, digitando periodic tutti_i_giorni_feriali (esattamente come richiamate lo script daily digitando periodic daily ecc.). Naturalmente bisognerà impostare cron così che tale comando sia eseguito tutti i giorni dal lunedì al venerdì.
Le 12 righe non commentate successive appartengono, a blocchi di 4, ai tre script di pulizia di sistema (i famosi daily, weekly e monthly) e consentono di impostare il livello di prolissità della risposta di questi script. Mi spiego. Quando uno di questi script viene eseguito, al termine dell'esecuzione comunica l'esito di ciò che ha fatto, secondo uno schema a tre livelli. Il livello più basso (0) comunica che lo script ha eseguito i suoi compiti senza incontrare problemi. Se la riga

daily_show_success="YES"

(oppure le righe equivalenti per gli altri due script) sono impostate per l'appunto a "YES", lo script comunicherà che tutto si è svolto regolarmente. Se sono impostate a "NO", l'esecuzione senza difficoltà di uno script di pulizia periodica del sistema sarà passata sotto silenzio (una specie di "silenzio-assenso"), e nessun rapporto verrà generato. Al livello successivo (1), lo script ha terminato le sue operazioni con successo, ma ha ritenuto necessario rendere noto che qualche cosa di anormale o comunque di interessante è successo. Impostare a "NO" la riga normalmente impostata come

daily_show_info="YES"

significa decidere di rinunciare a venire avvisati di quanto di anomalo sia stato riscontrato dallo script (naturalmente, anche qui un discorso analogo vale per gli altri due script, quello settimanale e quello mensile). Infine, al livello 2 vengono segnalate tutte quelle condizioni (di errata configurazione) che hanno causato un'esecuzione non corretta dello script di pulizia periodica. Anche in questo caso, la riga

daily_show_badconfig="NO"

consente di ignorare tali avvertimenti.
Qualunque script di pulizia periodica realizzato dall'utente (ad esempio il famoso "tutti_i_giorni_feriali") dovrà, in base alle condizioni che incontra, segnalare se si è concluso al livello 0, 1 oppure 2, e a seconda delle circostanze riportare le ragioni che l'hanno portato a livello 1 oppure 2.
In ogni caso, le informazioni che abbiamo scelto di non ignorare (quelle marcate con "YES" nelle righe di configurazione commentate prima) verranno memorizzate in un file di testo a nostra scelta. Di default, come si vede dalle righe daily_output, weekly_output e monthly_output, si tratta di file contenuti nella cartella /var/log e comodamente visualizzabili con l'applicazione Console (che si trova in /Applicazioni/Utility) o con qualunque altro editor di testi. Potete naturalmente scegliere di indirizzare l'output di questi script periodici verso un altro file, che scriverete, con tutto il suo percorso, in queste righe del file /etc/defaults/periodic.conf o, meglio, come dicevamo prima, in /etc/periodic.conf oppure /etc/periodic.conf.local.
Per finire, 5 righe configurano alcune delle operazioni effettuate dallo script daily (e solo da esso). La prima:

daily_clean_logs_enable="YES"

stabilisce se le cartelle di log di sistema vadano "ripulite" ogni giorno. La seconda,

daily_clean_logs_dirs="/Library/Logs/CrashReporter"

stabilisce quali siano le cartelle di log da ripulire (nel caso la prima istruzione fosse impostata a "YES"). La terza

daily_clean_logs_days="60"

stabilisce per quanti giorni un file contenuto in una cartella di log da ripulire venga comunque mantenuto sull'hard disk prima di essere definitivamente cancellato. La quarta

daily_clean_logs_ignore=""

elenca i file contenuti nelle cartelle di log da ripulire che si vogliono comunque preservare. Infine la quinta

daily_clean_logs_verbose="NO"

stabilisce se riportare o meno (di default non lo fa) l'elenco dei file di log cancellati nel file di testo daily.out o in quello che avete scelto voi come destinatario dell'output dello script daily.
Al termine di /etc/defaults/periodic.conf ci sono alcune righe di codice che, ovviamente, non vanno assolutamente toccate.
Dicevamo che le operazioni periodiche di pulizia sono governate automaticamente da cron o dalla sua interfaccia grafica CronniX, grazie alla quale potete impostarle automaticamente ad orari diversi da quelli di default qualora il vostro Mac fosse sistematicamente spento in tali occasioni. Inoltre, molte utility come Onyx, MacJanitor e altre consentono di effettuare "a comando manuale" le operazioni periodiche di pulizia.
Tutte le informazioni riportate qui, ed altre ancora, si trovano nelle pagine di manuale di periodic e periodic.conf, per cui vi basta digitare da Terminale

man periodic

e

man periodic.conf

o usare utility come ManOpen o Xmanview per accedere a questa documentazione. (fonte tevac)

****************
Spero di essere stato esauriente..
..provate a chiedere del defrag sulla sezione linux....

[mrwolf1981]

ti ringrazio sei stato veramente preciso

[whitearrow]

Complimenti Marxaid per l'utilissimo post, l'ho letto con grande interesse!
Dato per buono il fatto che in sistemi unix non esistono utility di deframmentazione vorrei però precisare che, almeno secondo le mie elementari nozioni di sistemi operativi, la frammentazione esiste sempre e comunque in ogni tipo di filesystem.
Inoltre bisogna distinguere tra frammentazione interna ed esterna: la prima è dovuta alla dimensione fissa dei blocchi logici e allo spazio che rimane vuoto (inutilizzabile) se un file non occupa tutto il blocco. Quella esterna è invece dovuta alla posizione sul disco nella quale vengono scritti i dati, che non è sempre consecutiva (per fortuna, altrimenti se non ci fosse abbastanza spazio contiguo non si potrebbe scrivere un file grande).
Sta poi all'implementazione del filesystem gestire attraverso opportune strutture di indicizzazione i file memorizzati. Quindi senza conoscere nel dettaglio ext2 ne tantomeno il fs mac, mi sento di affermare che se di deframmentazione non c'è bisogno è perchè il fs riesce a gestire in modo efficiente il disco anche con i file sparsi in vari settori.
Ora sinceramente non credo che ntfs sia da buttare via, mi sembra un ottimo progetto (infatti ms non rilascia la specifiche e ce lo dobbiamo montare read only) quindi io personalmente non deframmento neanche su windows. E non ne ho mai sentito il bisogno. Ho provato diskeeper server edition che lancia un processo sempre attivo e deframmenta in continuazione tenendo l'hd il più ordinato possibile. Tutti questi miglioramenti non li ho visti. Forse la pratica winzzozziana del defrag è più una cosa psicologica, voler tenere tutto più ordinato possibile.
Poi da un punto di vista algoritmico è inevitabile che una disposizione dei files in blocchi contigui sia preferibile. Mi viene quindi in mente che in sistemi unix destinati a fare da file server sia forse utile prevedere qualche forma di deframmentazione. Ma probabilmente il sistema in fase di allocazione dello spazio per la scrittura su disco tiene già conto di fattori legati all'efficienza. Se qualcuno ne sa di più su questo argomento sarei curioso di sapere come funziona.