Newsgroup: it.comp.os.amiga
Titolo: RAM Disk

Vorrei che qualcuno mi spiegasse come fa AmigaOS a gestire una RAM Disk con
dimensione dinamica, a seconda della quantita' disponibile, a quanto pare
fregandosene della frammentazione dei blocchi di memoria libera.
L'unica soluzione che mi balza in mente e' di strutturare la RAM Disk come
una lista concatenata, ma in tal caso sarebbe piu' simile ad un tape,
sequenziale, che ad un disco, ad accesso casuale, quindi troppo lenta e
inefficiente. Al contrario, il disco RAM e' molto veloce...
Grazie in anticipo.

inefficiente. Al contrario, il disco RAM e' molto veloce...
se non dico una stronzata la Ram disk è la ram fisica presenti nel
sistema e le prestazioni della ram disk dipendeono dalle prestazioni
della ram fisica :)

Seiya ha scritto:



Lui voleva sapere qualcosa di più specifico.....
Mi spiace ma ancora non sono arrivato a questa parte nel RKRM ;-)
Cmq teoricamente in questo NG non sono tutti alle prime armi come me, anzi
sono io l'unico, dunque tra poco dovrebbe arrivarti una bella spiegazione
;-*
ShInKurO 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sono io l'unico, dunque tra poco dovrebbe arrivarti una bella spiegazione
purtroppo come funziona in dettaglio la ram disk, onestamente, non me ne è
importata un granchè, l'importante che fosse sufficientemente veloce :)

 lenta e inefficiente. Al contrario, il disco RAM e' molto veloce...
PRESUMO che venga sfruttata proprio come una lista concatenata.
In pratica credo vengano allocati blocchi di 512 byte (o piu'). Dal KS
2.x credo si usino i memory pools per ridurre la frammentazione della
memoria e aumentare le prestazioni.
Come prestazioni non confronterei la RAM con i dischi. In ogni caso
l'accesso alla memoria e' un migliaio di volte piu' veloce dell'accesso
al disco, e il transfer rate qualche decina di volte piu' alto.
Bye.

 memoria e aumentare le prestazioni.
Se viene gestita come lista concatenata, la riduzione della frammentazione
non migliora le prestazioni, a meno di altre sovrastrutture.
--
Retrocensitevi! Su:
http://valis.di.uniba.it/projects/retrocensimento
http://www.retrocensimento.cjb.net

 non migliora le prestazioni, a meno di altre sovrastrutture.
La gestion del ram disk è estremamente semplice in verità: un albero 
n-ario la cui radice è la directory genitrice di tutte le altre, 'RAM:' 
per intenderci, ed i nodi sono o sottodirectory o normali file.
Ora, il tutto si riduce a come gestire i file, visto che la gestione del 
contenuto delle directory è, come visto sopra, semplicissima. I file 
sono semplicemnte visti come un insieme di blocchi di una certa 
dimensione. Aggiungere dati al file comporta l'aggiunta di zero, uno o 
più blocchi a questo insieme, e troncare il file necessariamente di 
traduce nell'eliminare zero, uno o più blocchi da questo insieme. Ora, 
come venga gestito questo insieme (lista, albero, tabella hash...) poco 
importa ai fini dell'implementazione, l'unica differenza si avrà dal 
punto di vista prestazionale, e scegliere una struttura dati piuttosto 
che un'altra comporta prestazioni migliori o peggiori a seconda dell'uso 
tipico che si fa dei file: una lista concatenata è perfetta per accessi 
sequenziali, per esempio, non tanto perfetta per accessi casuali. Quello 
che si potrebbe fare, per avere il meglio da ambo le parti, è mantenere 
i blocchi in una lista, e parallelamente mantenere un array di indici ai 
blocchi, da ridimensionare ogni volta che si aggiunge o toglie qualche 
blocco (non necessariamente un solo blocco): in questo modo sia seek() 
che write() che read() sarebbero O(1) (ridimensionare l'array, 
specialmente su AmigaOS, non è O(1), ma se si riduce la probabilità che 
il ridimensionamento avvenga, allora la sua complessità è trascurabile).
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                 |     Bertrand Russell
falemagn (AT) aros (DOT) org    |     The Philosophy of Logical Atomism

 [...]
Grazie mille per la precisa, dettagliata e chiara spiegazione.
