Le regioni VM sono spesso utilizzate come spazi di indirizzo condivisibili nelle applicazioni VOS. Questo è un modo molto efficiente per consentire a più processi di accedere allo stesso set di indirizzi. Lo svantaggio principale è che lo spazio è limitato a ben meno di 2 GB a causa dei limiti di memoria virtuale di VOS, e questo uso taglia in VM disponibili per altri scopi.
Lo spazio degli indirizzi può anche essere condiviso tramite il file system mappando gli indirizzi su un file binario e accedendo a tali indirizzi tramite operazioni di File I/O. In questo modo si eliminano le restrizioni di dimensione della regione della VM e si liberano le VM altrimenti dedicate. Permette anche il coordinamento tramite il blocco della regione, ma è molto più costoso dell'accesso diretto alla VM condivisa, in particolare se è coinvolto l'effettivo I/O del disco.
Le applicazioni Posix utilizzano a volte i file di flusso in modalità binaria per questo scopo, stabilendo la dimensione desiderata dello spazio dell'indirizzo tramite ftruncate (utilizzato per la sua capacità di estendere la posizione di EOF) e quindi la posizione alle aree all'interno del file da cui vengono letti o scritti i dati. In questo modo, il file serve da archivio di supporto per lo spazio degli indirizzi e i processi condividono lo spazio utilizzando interfacce orientate ai file come fseek/fread/fread/fwrite.
Prima dei file di stream a 64 bit (introdotti nella Release 17.2), questo poteva essere molto costoso su VOS perché i normali file di stream non possono essere scarsi, e l'estensione di EOF comporta l'assegnazione e la scrittura esplicita di blocchi di zeri binari. Per esempio, se lo spazio di indirizzo desiderato fosse diciamo 2 GB, allora VOS richiederebbe 524.288 blocchi di memoria su disco, anche se solo una piccola quantità di tale memoria potrebbe mai contenere valori diversi dagli zeri binari. Con i file di flusso a 64 bit, questo tipo di applicazioni può ora essere eseguito in modo efficiente su VOS, richiedendo solo la quantità di spazio su disco effettivamente necessaria. Le applicazioni Posix ottengono automaticamente il beneficio dei file di flusso a 64 bit quando sono costruite per la consapevolezza dei file di grandi dimensioni; si dovrebbe fare questo per ottenere questi benefici di prestazioni, anche se non ci si aspetta che i file crescano fino a più di 2 GB. (Vedere il manuale di riferimento OpenVOS POSIX.1, R502, "Porting Existing Applications to the 64-bit Stream File Environment" per maggiori informazioni).
Un uso simile dello spazio di indirizzi condivisi su file è possibile nelle applicazioni VOS native, cioè quelle che utilizzano interfacce s$. VOS fornisce una serie di caratteristiche che possono ridurre notevolmente l'I/O del disco quando si usa questa tecnica, facendo essenzialmente dell'uso della CPU il costo primario. L'introduzione di scarsi file di stream a 64 bit nella release 17.2 rende questo approccio allo spazio di indirizzi condiviso ancora più attraente.
Residente di memoria e file RAM
Un file residente in memoria viene identificato con il comando set_open_options. Una porzione impostabile della cache del disco è riservata ai file residenti in memoria. A seconda della memoria fisica disponibile e degli altri usi della cache, questa può essere fino a 9-10 GB. I blocchi di file residenti in memoria una volta in cache non incorreranno in successive letture del disco, a condizione che il numero totale non superi quella porzione di cache. In tal caso, i blocchi di riferimento più recenti mantengono questo vantaggio.
I file RAM sono file che contengono dati non persistenti e sono utili se il file contiene dati che non devono essere impegnati su disco quando l'applicazione ha finito di utilizzarlo. Si può usare il comando set_ram_file, ma qualsiasi file per il quale s$delete_file_on_close è chiamato viene automaticamente trattato come un file RAM da quel punto in poi.
Mentre i file residenti in memoria non subiscono successive letture del disco, i blocchi sono ancora scritti a intervalli regolari, e il numero di blocchi modificati ammessi nella cache è limitato come per qualsiasi altro file. I limiti di blocco modificati impediscono la situazione in cui milioni di blocchi potrebbero dover essere scritti quando il file viene chiuso o lavato - un file da 4 GB occupa un milione di blocchi. Questa limitazione può rallentare un'applicazione che modifica i dati più velocemente di quanto possa essere scritto. I file RAM evitano questo tipo di strozzamento poiché i loro dati non devono mai essere scritti su disco, anche quando il file è disattivato.
L'utilizzo di file RAM residenti in memoria fornisce uno spazio di indirizzo nella memoria cache evitando la maggior parte degli I/O del disco, uno spazio di indirizzo che è limitato solo dalla dimensione della cache che a sua volta si basa sulla memoria fisica disponibile, non sulla memoria virtuale (il gestore della cache condivide gli indirizzi VM per accedere alla memoria fisica). Nota: uno spazio di indirizzo basato su un singolo file può crescere fino a 512 GB, ma quando è più grande della porzione di cache residente nella memoria, perde i vantaggi di I/O, almeno per quei blocchi che non sono stati recentemente referenziati.
Esempio
Si può accedere al contenuto di un file di flusso utilizzando s$seq_position con opcode orientati ai byte e quindi esaminarlo o modificarlo utilizzando s$read_raw/s$write_raw. I file di stream a 64 bit possono essere fino a 512 GB senza richiedere uno spazio su disco significativo, ad eccezione delle regioni del file che vengono utilizzate, cioè impostate in modo da essere non zero.
Per esempio,
create_file scratch -organization stream64 -extent_size 256
Questo crea un file DAE-256 chiamato "scratch".
set_ram_file scratch
Questo permette a questo file di avere un accesso illimitato alla cache evitando qualsiasi strozzatura legata al numero di blocchi modificati, e di evitare del tutto le scritture su disco tranne che in background o quando la cache è esaurita e necessaria per altri scopi. Questo può essere fatto anche in modo programmatico tramite s$set_ram_file. Quando l'ultimo apritore chiude il file, i dati in cache vengono scartati e non comportano mai la scrittura su disco. Il file deve essere vuoto quando si usa questo comando.
set_open_options_options scratch -cache_mode memoria_residente
Questo fa sì che il maggior numero possibile di blocchi di questo file venga mantenuto in cache a tempo indeterminato. Il numero effettivo è un fattore della dimensione della cache e della percentuale di residenza della memoria, come impostato nel comando set_tuning_parameters.
La seguente sequenza mostra un esempio di utilizzo programmatico (illustrato utilizzando test_system_calls):
tsc: s$attach_port p scratch
tsc: s$open p -io_type update
Ora, fornire uno spazio per gli indirizzi di circa 512 GB:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
e usarlo per memorizzare i dati:
tsc: s$seq_position_x p bwd_bytes 3 (la posizione corrente dopo l'estensione è EOF)
tsc: s$write_raw p END
tsc: s$seq_position_x p bof
tsc: s$write_raw p START
tsc: s$seq_position_x p fwd_bytes 2000
tsc: s$write_raw p 2000
Nota: s$seq_position supporta anche gli opcode per la posizione agli offset di byte assoluti.
Il risultato è questo, con il file che occupa solo due blocchi di dati su disco:
..dump_file scratch -brief
%swsle#Raid4>otto>d-3>nuovo>graffio 15-02-25 16:04:17 est
Blocco numero 1
000 53544152 540000000000 00000000 00000000 00000000 |INIZIO.......................
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 0000000000 |..................................................
Numero di blocco 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 000000000000 000000000000 0000000000 00454E44 |............................FINE|
Nota: i blocchi 1 e 131870736 sono in cache e tipicamente non saranno stati scritti su disco, anche se lo spazio su disco è riservato a loro, se necessario, se le risorse della cache sono tese. Il comando dump_file di cui sopra è vedere i blocchi in cache, non leggere il disco.
Quando un file RAM viene disattivato (non è più aperto in nessun processo), VOS tronca il file (evitando di scrivere blocchi modificati su disco) e rilascia tutto lo spazio su disco. In circostanze tipiche, la sequenza di cui sopra non comporterebbe alcun I/O su disco, ad eccezione della scrittura dei due blocchi della mappa del file, che alla fine vengono scartati.
tsc: s$close p
Ora il file è vuoto e non occupa spazio su disco:
tsc: ..dump_file scratch
%swsle#Raid4>otto>d-3>nuovo>graffio 15-02-25 16:07:12 est