Le regioni di memoria virtuale (VM) vengono spesso utilizzate come spazi di indirizzi condivisibili nelle applicazioni VOS. Si tratta di un metodo molto efficiente per consentire a più processi di accedere allo stesso insieme di indirizzi. Lo svantaggio principale è che lo spazio è limitato a ben meno di 2 GB a causa dei limiti della memoria virtuale di VOS, e questo utilizzo riduce la memoria virtuale disponibile per altri scopi.
Lo spazio di indirizzamento può essere condiviso anche tramite il file system, mappando gli indirizzi su un file binario e accedendo a tali indirizzi tramite operazioni di I/O su file. Ciò elimina le limitazioni relative alle dimensioni delle regioni della macchina virtuale e libera risorse della macchina virtuale che altrimenti sarebbero dedicate. Consente inoltre il coordinamento tramite il blocco delle regioni, ma è molto più dispendioso rispetto all'accesso diretto alla macchina virtuale condivisa, in particolare se sono coinvolte operazioni di I/O su disco.
Le applicazioni POSIX utilizzano talvolta file di flusso in modalità binaria a questo scopo, definendo la dimensione desiderata dello spazio di indirizzamento tramite ftruncate (utilizzato per la sua capacità di estendere la posizione dell'EOF) e posizionandosi poi in aree all'interno del file da cui vengono letti o scritti i dati. In questo modo, il file funge da memoria di supporto per lo spazio di indirizzamento e i processi condividono lo spazio utilizzando interfacce orientate ai file come fseek/fread/fwrite.
Prima dell'introduzione dei file di flusso a 64 bit (nella versione 17.2), questa operazione poteva risultare molto onerosa su VOS, poiché i normali file di flusso non possono essere sparsi e l'estensione dell'EOF comporta l'allocazione e la scrittura esplicita di blocchi di zeri binari. Ad esempio, se lo spazio di indirizzamento desiderato fosse, diciamo, 2 GB, allora VOS richiederebbe 524.288 blocchi di spazio su disco, anche se solo una piccola parte di quello spazio potrebbe mai contenere valori diversi da zeri binari. Con i file di flusso a 64 bit, questo tipo di applicazioni può ora funzionare in modo efficiente su VOS, richiedendo solo lo spazio su disco effettivamente necessario. Le applicazioni Posix ottengono automaticamente il vantaggio dei file di flusso a 64 bit quando sono compilate per il supporto di file di grandi dimensioni; è consigliabile farlo per ottenere questi vantaggi in termini di prestazioni, anche se non si prevede che i file superino i 2 GB. (Per ulteriori informazioni, consultare il manuale di riferimento OpenVOS POSIX.1, R502, “Porting Existing Applications to the 64-bit Stream File Environment”).
Un utilizzo analogo dello spazio di indirizzamento condiviso supportato da file è possibile nelle applicazioni VOS native, ovvero quelle che utilizzano le interfacce s$. VOS offre una serie di funzionalità in grado di ridurre notevolmente l'I/O su disco quando si utilizza questa tecnica, rendendo di fatto l'utilizzo della CPU il costo principale. L'introduzione dei file di flusso sparsi a 64 bit nella versione 17.2 rende questo approccio allo spazio di indirizzamento condiviso ancora più interessante.
File residenti in memoria e file RAM
Un file residente in memoria viene identificato tramite il comando `set_open_options`. Una porzione configurabile della cache su disco viene riservata ai file residenti in memoria. A seconda della memoria fisica disponibile e degli altri utilizzi della cache, tale spazio può arrivare fino a 9-10 GB. Una volta inseriti nella cache, i blocchi dei file residenti in memoria non comporteranno ulteriori letture dal disco fintantoché il loro numero totale non superi tale porzione della cache. In caso contrario, i blocchi a cui si è fatto riferimento più di recente mantengono questo vantaggio.
I file RAM sono file contenenti dati non persistenti e risultano utili quando il file contiene dati che non devono essere salvati su disco una volta che l'applicazione ha terminato di utilizzarli. È possibile utilizzare il comando `set_ram_file`, ma qualsiasi file per il quale viene chiamato `s$delete_file_on_close` viene automaticamente trattato come file RAM da quel momento in poi.
Sebbene i file residenti in memoria non comportino successive letture dal disco, i blocchi vengono comunque scritti a intervalli regolari e il numero di blocchi modificati consentiti nella cache è limitato proprio come per qualsiasi altro file. I limiti dei blocchi modificati impediscono che si verifichi una situazione in cui potrebbero essere necessari milioni di blocchi da scrivere quando il file viene chiuso o svuotato: un file da 4 GB occupa un milione di blocchi. Questa limitazione può rallentare un'applicazione che modifica i dati più velocemente di quanto sia possibile scriverli. I file RAM evitano questo tipo di rallentamento poiché i loro dati non devono mai essere scritti su disco, anche quando il file è disattivato.
L'utilizzo di file RAM residenti in memoria garantisce uno spazio di indirizzamento nella memoria cache che evita la maggior parte delle operazioni di I/O su disco; tale spazio è limitato solo dalla dimensione della cache, che a sua volta dipende dalla memoria fisica disponibile e non dalla memoria virtuale (il gestore della cache condivide gli indirizzi della memoria virtuale per accedere alla memoria fisica). Nota: un singolo spazio di indirizzamento basato su file può crescere fino a 512 GB, ma quando supera la porzione residente in memoria della cache, perde i vantaggi di I/O, almeno per quei blocchi a cui non è stato fatto riferimento di recente.
Esempio
È possibile accedere al contenuto di un file di flusso utilizzando s$seq_position con codici operativi orientati ai byte e quindi esaminarlo o modificarlo tramite s$read_raw/s$write_raw. I file di flusso a 64 bit possono raggiungere una dimensione massima di 512 GB senza richiedere uno spazio su disco significativo, ad eccezione delle regioni del file effettivamente utilizzate, ovvero quelle impostate su un valore diverso da zero.
Ad esempio,
crea_file scratch -organizzazione stream64 -dimensione_estensione 256
Questo crea un file DAE-256 denominato «scratch»
file di memoria temporanea
Ciò consente al file di avere accesso illimitato alla cache, evitando qualsiasi limitazione legata al numero di blocchi modificati, ed evita del tutto le operazioni di scrittura su disco, tranne che in background o quando la cache è esaurita e necessaria per altri scopi. Ciò può essere fatto anche a livello di programmazione tramite s$set_ram_file. Quando l'ultimo utente che ha aperto il file lo chiude, i dati presenti nella cache vengono eliminati e non comportano mai operazioni di scrittura su disco. Il file deve essere vuoto quando si utilizza questo comando.
set_open_options scratch -cache_mode memory_resident
Ciò fa sì che il maggior numero possibile di blocchi di questo file venga mantenuto nella cache a tempo indeterminato. Il numero effettivo dipende dalle dimensioni della cache e dalla percentuale di permanenza in memoria, come impostato nel comando set_tuning_parameters.
La sequenza seguente mostra un esempio di utilizzo a livello di programmazione (illustrato utilizzando test_system_calls):
tsc: s$attach_port p scratch
tsc: s$open p -io_type update
Ora, assegna uno spazio di indirizzamento di circa 512 GB:
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
e utilizzarlo per memorizzare dati:
tsc: s$seq_position_x p bwd_by_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_by_bytes 2000
tsc: s$write_raw p 2000
Nota: s$seq_position supporta anche gli opcode per posizionarsi su offset di byte assoluti.
Il risultato è il seguente: il file occupa solo due blocchi di dati sul disco:
..dump_file scratch -brief
%swsle#Raid4>otto>d-3>nuovo>scratch 25-02-15 16:04:17 EST
Blocco numero 1
000 53544152 54000000 00000000 00000000 |START………..|
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
Numero di blocco 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |………….END|
Nota: i blocchi 1 e 131870736 si trovano nella cache e in genere non vengono scritti su disco, sebbene sia stato riservato loro dello spazio su disco nel caso in cui fosse necessario farlo qualora le risorse della cache fossero insufficienti. Il comando `dump_file` sopra riportato rileva i blocchi presenti nella cache, senza leggere il disco.
Quando un file RAM viene disattivato (non è più aperto in alcun processo), VOS tronca il file (evitando di scrivere i blocchi modificati su disco) e libera tutto lo spazio su disco. In circostanze normali, la sequenza sopra descritta non comporterebbe alcun I/O su disco, ad eccezione delle operazioni di scrittura dei due blocchi della mappa del file, che vengono infine eliminati.
tsc: s$close p
Ora il file è vuoto e non occupa spazio su disco:
tsc: ..dump_file scratch
%swsle#Raid4>otto>d-3>nuovo>scratch 25-02-15 16:07:12 EST