RFC 1813 - Specifica del protocollo NFS Versione 3 (NFS Version 3 Protocol Specification)
- Stato: Informational
- Pubblicato: June 1995
- Stream: Legacy
- Errata: Nessun errata
Sommario (Abstract)
Questo documento descrive il protocollo NFS versione 3. Questo documento è fornito affinché le persone possano scrivere implementazioni compatibili.
Indice (Table of Contents)
- 1. Introduction (Introduzione)
- 1.1 Scope of the NFS version 3 protocol (Ambito del protocollo NFS versione 3)
- 1.2 Useful terms (Termini utili)
- 1.3 Remote Procedure Call (Chiamata di procedura remota)
- 1.4 External Data Representation (Rappresentazione esterna dei dati)
- 1.5 Authentication and Permission Checking (Autenticazione e controllo dei permessi)
- 1.6 Philosophy (Filosofia)
- 1.7 Changes from the NFS version 2 protocol (Modifiche rispetto al protocollo NFS versione 2)
- 2. RPC Information (Informazioni RPC)
- 2.1 Authentication (Autenticazione)
- 2.2 Constants (Costanti)
- 2.3 Transport address (Indirizzo di trasporto)
- 2.4 Sizes (Dimensioni)
- 2.5 Basic Data Types (Tipi di dati di base)
- 2.6 Defined Error Numbers (Numeri di errore definiti)
- 3. Server Procedures (Procedure del server)
- 3.1 General comments on attributes (Commenti generali sugli attributi)
- 3.2 General comments on filenames (Commenti generali sui nomi dei file)
- 3.3.0 NULL: Do nothing (Non fare nulla)
- 3.3.1 GETATTR: Get file attributes (Ottenere gli attributi del file)
- 3.3.2 SETATTR: Set file attributes (Impostare gli attributi del file)
- 3.3.3 LOOKUP: Lookup filename (Cercare il nome del file)
- 3.3.4 ACCESS: Check access permission (Verificare i permessi di accesso)
- 3.3.5 READLINK: Read from symbolic link (Leggere da un link simbolico)
- 3.3.6 READ: Read from file (Leggere da un file)
- 3.3.7 WRITE: Write to file (Scrivere su un file)
- 3.3.8 CREATE: Create a file (Creare un file)
- 3.3.9 MKDIR: Create a directory (Creare una directory)
- 3.3.10 SYMLINK: Create a symbolic link (Creare un link simbolico)
- 3.3.11 MKNOD: Create a special device (Creare un dispositivo speciale)
- 3.3.12 REMOVE: Remove a file (Rimuovere un file)
- 3.3.13 RMDIR: Remove a directory (Rimuovere una directory)
- 3.3.14 RENAME: Rename a file or directory (Rinominare un file o una directory)
- 3.3.15 LINK: Create link to an object (Creare un link a un oggetto)
- 3.3.16 READDIR: Read From directory (Leggere da una directory)
- 3.3.17 READDIRPLUS: Extended read from directory (Lettura estesa da una directory)
- 3.3.18 FSSTAT: Get dynamic file system information (Ottenere informazioni dinamiche sul file system)
- 3.3.19 FSINFO: Get static file system information (Ottenere informazioni statiche sul file system)
- 3.3.20 PATHCONF: Retrieve POSIX information (Recuperare informazioni POSIX)
- 3.3.21 COMMIT: Commit cached data on a server to stable storage (Confermare i dati memorizzati nella cache su un server in storage stabile)
- 4. Implementation issues (Problemi di implementazione)
- 4.1 Multiple version support (Supporto di più versioni)
- 4.2 Server/client relationship (Relazione server/client)
- 4.3 Path name interpretation (Interpretazione dei nomi di percorso)
- 4.4 Permission issues (Problemi di permessi)
- 4.5 Duplicate request cache (Cache delle richieste duplicate)
- 4.6 File name component handling (Gestione dei componenti del nome del file)
- 4.7 Synchronous modifying operations (Operazioni di modifica sincrone)
- 4.8 Stable storage (Storage stabile)
- 4.9 Lookups and name resolution (Ricerche e risoluzione dei nomi)
- 4.10 Adaptive retransmission (Ritrasmissione adattativa)
- 4.11 Caching policies (Politiche di caching)
- 4.12 Stable versus unstable writes (Scritture stabili vs instabili)
- 4.13 32 bit clients/servers and 64 bit clients/servers (Client/server a 32 bit e client/server a 64 bit)
- 5. Appendix I: Mount protocol (Appendice I: Protocollo di mount)
- 5.1 RPC Information (Informazioni RPC)
- 5.2 Server Procedures (Procedure del server)
- 6. Appendix II: Lock manager protocol (Appendice II: Protocollo del gestore di lock)
- 6.1 RPC Information (Informazioni RPC)
- 6.2 NLM Procedures (Procedure NLM)
- 6.3 Implementation issues (Problemi di implementazione)
- 7. Appendix III: Bibliography (Appendice III: Bibliografia)
- 8. Security Considerations (Considerazioni sulla sicurezza)
- 9. Acknowledgements (Ringraziamenti)
- 10. Authors' Addresses (Indirizzi degli autori)
Risorse correlate (Related Resources)
- RFC ufficiale: RFC 1813
- DataTracker: RFC 1813 on IETF
1. Introduzione (Introduction)
Il protocollo NFS (NFS Protocol) di Sun fornisce accesso remoto trasparente ai file system condivisi attraverso le reti. Il protocollo NFS è progettato per essere indipendente dalla macchina, dal sistema operativo, dall'architettura di rete e dal protocollo di trasporto. Questa indipendenza è ottenuta attraverso l'uso di primitive Remote Procedure Call (RPC) costruite sopra una rappresentazione esterna dei dati (eXternal Data Representation, XDR). Esistono implementazioni del protocollo NFS versione 2 per una varietà di macchine, dai personal computer ai supercomputer. La versione iniziale del protocollo NFS è specificata nella Network File System Protocol Specification [RFC1094]. Una descrizione dell'implementazione iniziale può essere trovata in [Sandberg].
Il protocollo MOUNT di supporto esegue le funzioni specifiche del sistema operativo che consentono ai client di collegare alberi di directory remoti a un punto all'interno del file system locale. Il processo di mount consente inoltre al server di concedere privilegi di accesso remoto a un insieme limitato di client tramite il controllo delle esportazioni.
Il Lock Manager fornisce supporto per il blocco dei file quando utilizzato nell'ambiente NFS. Il protocollo Network Lock Manager (NLM) isola gli aspetti intrinsecamente stateful del blocco dei file in un protocollo separato.
Una descrizione completa dei protocolli sopra menzionati e della loro implementazione si trova in [X/OpenNFS].
Lo scopo di questo documento è:
-
Specificare il protocollo NFS versione 3.
-
Descrivere la semantica del protocollo attraverso annotazioni e descrizione dell'implementazione prevista.
-
Specificare il protocollo MOUNT versione 3.
-
Descrivere brevemente le modifiche tra il protocollo NLM versione 3 e il protocollo NLM versione 4.
Il testo normativo è la descrizione delle procedure RPC e degli argomenti e risultati, che definisce il protocollo over-the-wire e la semantica di tali procedure. Il materiale che descrive la pratica di implementazione aiuta a comprendere la specifica del protocollo e descrive alcuni possibili problemi di implementazione e soluzioni. Non è possibile descrivere tutte le implementazioni e l'implementazione del sistema operativo UNIX del protocollo NFS versione 3 è più spesso utilizzata per fornire esempi. Dato ciò, la discussione sull'implementazione non ha l'autorità della descrizione del protocollo over-the-wire stesso.
1.1 Ambito del protocollo NFS versione 3 (Scope of the NFS version 3 protocol)
Questa revisione del protocollo NFS affronta nuovi requisiti. La necessità di supportare file e file system più grandi ha portato a estensioni per consentire dimensioni e offset di file a 64 bit. La revisione migliora la sicurezza aggiungendo supporto per un controllo di accesso da eseguire sul server. Le modifiche alle prestazioni sono di tre tipi:
-
Il numero di pacchetti over-the-wire per un dato insieme di operazioni su file è ridotto restituendo gli attributi del file ad ogni operazione, diminuendo così il numero di chiamate per ottenere gli attributi modificati.
-
Il collo di bottiglia del throughput di scrittura causato dalla definizione sincrona di scrittura nel protocollo NFS versione 2 è stato affrontato aggiungendo supporto affinché il server NFS possa eseguire scritture non sicure (unsafe writes). Le scritture non sicure sono scritture che non sono state confermate su storage stabile prima che l'operazione ritorni. Questa specifica definisce un metodo per confermare queste scritture non sicure su storage stabile in modo affidabile.
-
Le limitazioni sulle dimensioni di trasferimento sono state allentate.
La capacità di supportare più versioni di un protocollo in RPC consentirà agli implementatori del protocollo NFS versione 3 di definire client e server che forniscono retrocompatibilità con la base installata esistente di implementazioni del protocollo NFS versione 2.
Le estensioni qui descritte rappresentano un'evoluzione del protocollo NFS esistente e la maggior parte delle caratteristiche di progettazione del protocollo NFS descritte in [Sandberg] persistono. Vedere Modifiche rispetto al protocollo NFS versione 2 a pagina 11 per un riepilogo più dettagliato delle modifiche introdotte da questa revisione.
1.2 Termini utili (Useful terms)
In questa specifica, un "server" è una macchina che fornisce risorse alla rete; un "client" è una macchina che accede alle risorse tramite la rete; un "utente (user)" è una persona connessa a un client; un'"applicazione (application)" è un programma che viene eseguito su un client.
1.3 Remote Procedure Call
La specifica Sun Remote Procedure Call fornisce un'interfaccia orientata alle procedure ai servizi remoti. Ogni server fornisce un programma, che è un insieme di procedure. Il servizio NFS è uno di questi programmi. La combinazione di indirizzo host, numero di programma, numero di versione e numero di procedura specifica una procedura di servizio remoto. I server possono supportare più versioni di un programma utilizzando numeri di versione del protocollo diversi.
Il protocollo NFS è stato progettato per non richiedere alcun livello specifico di affidabilità dai suoi livelli inferiori, in modo che possa essere potenzialmente utilizzato su molti protocolli di trasporto sottostanti. Il servizio NFS è basato su RPC che fornisce l'astrazione sopra i protocolli di rete e trasporto di livello inferiore.
Il resto di questo documento presume che l'ambiente NFS sia implementato sopra Sun RPC, che è specificato in [RFC1057]. Una discussione completa si trova in [Corbin].
1.4 Rappresentazione esterna dei dati (External Data Representation)
La specifica eXternal Data Representation (XDR) fornisce un modo standard di rappresentare un insieme di tipi di dati su una rete. Questo risolve il problema di diversi ordini di byte, allineamento delle strutture e rappresentazione dei tipi di dati su diverse macchine comunicanti.
In questo documento, il linguaggio RPC Data Description Language viene utilizzato per specificare i parametri e i risultati in formato XDR per ciascuna delle procedure di servizio RPC che un server NFS fornisce. Il linguaggio RPC Data Description Language è simile alle dichiarazioni nel linguaggio di programmazione C. Sono stati aggiunti alcuni nuovi costrutti. La notazione:
string name[SIZE];
string data<DSIZE>;
definisce name, che è un blocco di dimensione fissa di SIZE byte, e data, che è un blocco di dimensione variabile fino a DSIZE byte. Questa notazione indica array di lunghezza fissa e array con un numero variabile di elementi fino a un massimo fisso. Una definizione di lunghezza variabile senza dimensione specificata significa che non c'è una dimensione massima per il campo.
La definizione di union discriminata:
union example switch (enum status) {
case OK:
struct {
filename file1;
filename file2;
integer count;
}
case ERROR:
struct {
errstat error;
integer errno;
}
default:
void;
}
definisce una struttura in cui la prima cosa sulla rete è un tipo di enumerazione chiamato status. Se il valore di status è OK, la cosa successiva sulla rete sarà la struttura contenente file1, file2 e count. Altrimenti, se il valore di status è ERROR, la cosa successiva sulla rete sarà una struttura contenente error e errno. Se il valore di status non è né OK né ERROR, non ci sono altri dati nella struttura.
Il tipo XDR hyper è una quantità di 8 byte (64 bit). Viene utilizzato nello stesso modo del tipo integer. Per esempio:
hyper foo;
unsigned hyper bar;
foo è un valore con segno di 8 byte, mentre bar è un valore senza segno di 8 byte.
Sebbene esistano compilatori RPC/XDR per generare stub client e server dall'input del linguaggio RPC Data Description Language, le implementazioni NFS non richiedono il loro utilizzo. Qualsiasi software che fornisca codifica e decodifica equivalenti all'ordine di rete canonico dei dati definiti da XDR può essere utilizzato per interoperare con altre implementazioni NFS.
XDR è descritto in [RFC1014].
1.5 Autenticazione e controllo dei permessi (Authentication and Permission Checking)
Il protocollo RPC include uno slot per i parametri di autenticazione ad ogni chiamata. Il contenuto dei parametri di autenticazione è determinato dal tipo di autenticazione utilizzato dal server e dal client. Un server può supportare diversi tipi di autenticazione contemporaneamente. Il tipo AUTH_NONE fornisce autenticazione nulla, cioè non vengono passate informazioni di autenticazione. Il tipo AUTH_UNIX fornisce ID utente, ID gruppo e gruppi in stile UNIX ad ogni chiamata. Il tipo AUTH_DES fornisce parametri di autenticazione crittografati DES basati su un nome a livello di rete, con chiavi di sessione scambiate tramite uno schema a chiave pubblica. Il tipo AUTH_KERB fornisce parametri di autenticazione crittografati DES basati su un nome a livello di rete con chiavi di sessione scambiate tramite chiavi segrete Kerberos.
Il server NFS controlla i permessi prendendo le credenziali dalle informazioni di autenticazione RPC in ogni richiesta remota. Per esempio, utilizzando il tipo di autenticazione AUTH_UNIX, il server ottiene l'ID utente effettivo, l'ID gruppo effettivo e i gruppi dell'utente ad ogni chiamata e li utilizza per controllare l'accesso. L'uso di ID utente e ID gruppo implica che il client e il server condividano lo stesso elenco di ID o eseguano il mapping locale degli ID utente e gruppo. I server e i client devono concordare sul mapping da utente a uid e da gruppo a gid, per quei siti che non implementano uno spazio di ID utente e ID gruppo coerente. In pratica, tale mapping viene tipicamente eseguito sul server, seguendo uno schema di mapping statico o un mapping stabilito dall'utente da un client al momento del mount.
Lo stile di autenticazione AUTH_DES e AUTH_KERB si basa su un nome a livello di rete. Fornisce maggiore sicurezza attraverso l'uso della crittografia DES e delle chiavi pubbliche nel caso di AUTH_DES, e della crittografia DES e delle chiavi segrete Kerberos (e ticket) nel caso di AUTH_KERB. Ancora una volta, il server e il client devono concordare sull'identità di un particolare nome sulla rete, ma il mapping da nome a identità è più indipendente dal sistema operativo rispetto al mapping uid e gid in AUTH_UNIX. Inoltre, poiché i parametri di autenticazione sono crittografati, un utente malintenzionato deve conoscere la password di rete o la chiave privata di un altro utente per impersonare quell'utente. Allo stesso modo, il verificatore restituito dal server è anch'esso crittografato, quindi impersonare un server richiede la conoscenza di una password di rete.
La procedura NULL tipicamente non richiede autenticazione.
1.6 Filosofia (Philosophy)
Questa specifica definisce il protocollo NFS versione 3, cioè il protocollo over-the-wire attraverso il quale un client accede a un server. Il protocollo fornisce un'interfaccia ben definita alle risorse di file di un server. Un client o un server implementa il protocollo e fornisce un mapping della semantica e delle azioni del file system locale a quelle definite nel protocollo NFS versione 3. Le implementazioni possono differire in varia misura, a seconda del grado in cui un dato ambiente può supportare tutte le operazioni e la semantica definite nel protocollo NFS versione 3. Sebbene esistano implementazioni e vengano utilizzate per illustrare vari aspetti del protocollo NFS versione 3, la specifica del protocollo stessa è la descrizione finale di come i client accedono alle risorse del server.
Poiché il protocollo NFS versione 3 è progettato per essere indipendente dal sistema operativo, non corrisponde necessariamente alla semantica di alcun sistema esistente. Ci si aspetta che le implementazioni server facciano del loro meglio per supportare il protocollo. Se un server non può supportare una particolare procedura del protocollo, può restituire l'errore NFS3ERR_NOTSUP, che indica che l'operazione non è supportata. Per esempio, molti sistemi operativi non supportano il concetto di hard link. Un server che non può supportare gli hard link dovrebbe restituire NFS3ERR_NOTSUP in risposta a una richiesta LINK. FSINFO descrive le procedure più comunemente non supportate nella bitmap delle proprietà. In alternativa, un server potrebbe non supportare nativamente una data operazione, ma può emularla nell'implementazione del protocollo NFS versione 3 per fornire maggiore funzionalità.
In alcuni casi, un server può supportare la maggior parte della semantica descritta dal protocollo ma non tutta. Per esempio, il campo ctime nella struttura fattr fornisce il tempo in cui gli attributi di un file sono stati modificati l'ultima volta. Molti sistemi non mantengono queste informazioni. In questo caso, piuttosto che non supportare l'operazione GETATTR, un server potrebbe simularla restituendo il tempo dell'ultima modifica al posto di ctime. I server devono essere cauti quando simulano informazioni sugli attributi a causa di possibili effetti collaterali sui client. Per esempio, molti client utilizzano i tempi di modifica dei file come base per il loro schema di coerenza della cache.
I server NFS sono stupidi e i client NFS sono intelligenti. Sono i client che svolgono il lavoro necessario per convertire l'accesso ai file generalizzato che i server forniscono in un metodo di accesso ai file utile per le applicazioni e gli utenti. Nell'esempio LINK dato sopra, un client UNIX che ha ricevuto un errore NFS3ERR_NOTSUP da un server eseguirebbe il recupero necessario per far apparire all'applicazione che la richiesta di link è riuscita o restituire un errore ragionevole. In generale, è l'onere del client recuperare.
Il protocollo NFS versione 3 assume un'implementazione server stateless. Stateless significa che il server non ha bisogno di mantenere lo stato su nessuno dei suoi client per funzionare correttamente. I server stateless hanno un vantaggio distinto rispetto ai server stateful in caso di crash. Con i server stateless, un client deve solo riprovare una richiesta fino a quando il server risponde; il client non ha nemmeno bisogno di sapere che il server si è arrestato. Vedere commenti aggiuntivi in Duplicate request cache a pagina 99.
Per essere utile, un server mantiene stato non volatile: dati memorizzati nel file system. Le assunzioni di progettazione nel protocollo NFS versione 3 riguardanti lo svuotamento dei dati modificati su storage stabile riducono il numero di modalità di guasto in cui può verificarsi la perdita di dati. In questo modo, le implementazioni del protocollo NFS versione 3 possono tollerare guasti transitori, inclusi guasti transitori della rete. In generale, le implementazioni server del protocollo NFS versione 3 non possono tollerare un guasto non transitorio dello storage stabile stesso. Tuttavia, esistono implementazioni fault-tolerant che tentano di affrontare tali problemi.
Ciò non significa che un server del protocollo NFS versione 3 non possa mantenere stato non critico. In molti casi, i server manterranno stato (cache) sulle operazioni precedenti per aumentare le prestazioni. Per esempio, una richiesta READ del client potrebbe attivare una lettura anticipata del blocco successivo del file nella cache dati del server in previsione che il client stia eseguendo una lettura sequenziale e che la successiva richiesta READ del client sarà soddisfatta dalla cache dati del server invece che dal disco. La lettura anticipata sul server aumenta le prestazioni sovrapponendo l'I/O del disco del server con le richieste del client. Il punto importante qui è che il blocco di lettura anticipata non è necessario per un comportamento corretto del server. Se il server si arresta e perde la sua cache in memoria dei buffer di lettura, il recupero al riavvio è semplice - i client continueranno le operazioni di lettura recuperando i dati dal disco del server.
La maggior parte delle operazioni di modifica dei dati nel protocollo NFS sono sincrone. Cioè, quando una procedura di modifica dei dati ritorna al client, il client può assumere che l'operazione sia stata completata e che tutti i dati modificati associati alla richiesta siano ora su storage stabile. Per esempio, una richiesta WRITE sincrona del client può causare l'aggiornamento da parte del server di blocchi di dati, blocchi di informazioni sul file system e informazioni sugli attributi del file - queste ultime informazioni sono solitamente chiamate metadati (metadata). Quando l'operazione WRITE è completata, il client può assumere che i dati di scrittura siano al sicuro e scartarli. Questa è una parte molto importante della natura stateless del server. Se il server non svuotasse i dati sporchi su storage stabile prima di ritornare al client, il client non avrebbe modo di sapere quando è sicuro scartare i dati modificati. Le seguenti procedure di modifica dei dati sono sincrone: WRITE (con flag stabile impostato su FILE_SYNC), CREATE, MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK e COMMIT.
Il protocollo NFS versione 3 introduce scritture asincrone sicure sul server, quando la procedura WRITE viene utilizzata in combinazione con la procedura COMMIT. La procedura COMMIT fornisce un modo per il client di svuotare i dati dalle precedenti richieste WRITE asincrone sul server su storage stabile e di rilevare se è necessario ritrasmettere i dati. Vedere le descrizioni delle procedure di WRITE a pagina 49 e COMMIT a pagina 92.
La procedura LOOKUP viene utilizzata dal client per attraversare nomi di file multi-componente (pathname). Ogni chiamata a LOOKUP viene utilizzata per risolvere un segmento di un pathname. Ci sono due ragioni per limitare LOOKUP a un singolo segmento: è difficile standardizzare un formato comune per i nomi di file gerarchici e il client e il server possono avere mapping diversi di pathname a file system. Ciò implicherebbe che o il client deve spezzare il pathname ai punti di attacco del file system, o il server deve conoscere i punti di attacco del file system del client. Nelle implementazioni del protocollo NFS versione 3, è il client che costruisce lo spazio dei nomi di file gerarchico utilizzando i mount per costruire una gerarchia. Le utility di supporto, come l'Automounter, forniscono un modo per gestire un'immagine condivisa e coerente dello spazio dei nomi di file pur essendo guidate dal processo di mount del client.
I client possono eseguire il caching in modo vario. La pratica generale con il protocollo NFS versione 2 era di implementare un meccanismo di coerenza della cache client-server basato sul tempo. Si prevede che le implementazioni del protocollo NFS versione 3 utilizzeranno un meccanismo simile. Il protocollo NFS versione 3 ha un supporto esplicito, sotto forma di informazioni sugli attributi aggiuntive per eliminare i controlli espliciti degli attributi. Tuttavia, il caching non è richiesto, né è definita alcuna politica di caching dal protocollo. Né il protocollo NFS versione 2 né il protocollo NFS versione 3 forniscono un mezzo per mantenere una coerenza stretta client-server (e, per implicazione, coerenza tra le cache dei client).
1.7 Modifiche rispetto al protocollo NFS versione 2 (Changes from the NFS Version 2 Protocol)
Le procedure ROOT e WRITECACHE sono state rimosse. È stata definita una procedura MKNOD per consentire la creazione di file speciali, eliminando il sovraccarico di CREATE. Il caching sul client non è definito né dettato dal protocollo NFS versione 3, ma sono state aggiunte informazioni e suggerimenti aggiuntivi al protocollo per consentire ai client che implementano il caching di gestire le loro cache in modo più efficace. Le procedure che influenzano gli attributi di un file o directory possono ora restituire i nuovi attributi dopo il completamento dell'operazione per ottimizzare un successivo GETATTR utilizzato nella validazione delle cache degli attributi. Inoltre, le operazioni che modificano la directory in cui risiede l'oggetto target restituiscono i vecchi e nuovi attributi della directory per consentire ai client di implementare procedure di invalidazione della cache più intelligenti. La procedura ACCESS fornisce il controllo dei permessi di accesso sul server, la procedura FSSTAT restituisce informazioni dinamiche su un file system, la procedura FSINFO restituisce informazioni statiche su un file system e un server, la procedura READDIRPLUS restituisce handle di file e attributi oltre alle voci di directory, e la procedura PATHCONF restituisce informazioni POSIX pathconf su un file.
Di seguito è riportato un elenco delle modifiche importanti tra il protocollo NFS versione 2 e il protocollo NFS versione 3.
Dimensione dell'handle del file (File handle size)
L'handle del file è stato aumentato da un array fisso di 32 byte a un array di lunghezza variabile di massimo 64 byte. Questo affronta alcuni requisiti noti per una dimensione dell'handle del file leggermente più grande. L'handle del file è stato convertito da lunghezza fissa a lunghezza variabile per ridurre i requisiti di storage locale e larghezza di banda di rete per i sistemi che non utilizzano i 64 byte completi di lunghezza.
Dimensioni massime dei dati (Maximum data sizes)
La dimensione massima di un trasferimento di dati utilizzato nelle procedure READ e WRITE è ora impostata dai valori nella struttura di ritorno FSINFO. Inoltre, le dimensioni di trasferimento preferite vengono restituite da FSINFO. Il protocollo non impone alcun limite artificiale sulle dimensioni massime di trasferimento.
I nomi di file e i pathname sono ora specificati come stringhe di lunghezza variabile. Le restrizioni di lunghezza effettive sono determinate dalle implementazioni client e server in modo appropriato. Il protocollo non impone alcun limite artificiale sulla lunghezza. L'errore NFS3ERR_NAMETOOLONG è fornito per consentire al server di restituire un'indicazione al client che ha ricevuto un pathname troppo lungo per essere gestito.
Restituzione degli errori (Error return)
Le restituzioni degli errori in alcuni casi ora restituiscono dati (per esempio, attributi). nfsstat3 ora definisce l'insieme completo di errori che possono essere restituiti da un server. Non sono consentiti altri valori.
Tipo di file (File type)
Il tipo di file ora include NF3CHR e NF3BLK per i file speciali. Gli attributi per questi tipi includono sottocampi per i numeri di device maggiori e minori UNIX. NF3SOCK e NF3FIFO sono ora definiti per i socket e i fifo nel file system.
Attributi del file (File attributes)
Il campo blocksize (la dimensione in byte di un blocco nel file) è stato rimosso. Il campo mode non contiene più informazioni sul tipo di file. I campi size e fileid sono stati ampliati a interi senza segno a otto byte da interi a quattro byte. Le informazioni sui numeri di device maggiori e minori sono ora presentate in una struttura distinta. Il nome del campo blocks è stato cambiato in used e ora contiene il numero totale di byte utilizzati dal file. È anche un intero senza segno a otto byte.
Impostazione degli attributi del file (Set file attributes)
Nel protocollo NFS versione 2, gli attributi impostabili erano rappresentati da un sottoinsieme della struttura degli attributi del file; il client indicava quali attributi non dovevano essere modificati impostando il campo corrispondente a -1, sovraccaricando alcuni campi senza segno. La struttura di impostazione degli attributi del file ora utilizza un'union discriminata per ogni campo per indicare se o come impostare quel campo. I campi atime e mtime possono essere impostati sul tempo corrente del server o su un tempo fornito dal client.
LOOKUP
La struttura di ritorno LOOKUP ora include gli attributi per la directory cercata.
ACCESS
È stata aggiunta una procedura ACCESS per consentire un controllo esplicito dei permessi over-the-wire. Questo affronta problemi noti con la funzionalità di mapping dell'ID del superutente in molte implementazioni server (dove, a causa del mapping dell'utente root, potevano verificarsi errori imprevisti di permesso negato durante la lettura o la scrittura in un file). Questo rimuove anche l'assunzione che è stata fatta nel protocollo NFS versione 2 che l'accesso ai file fosse basato esclusivamente sui bit di modalità in stile UNIX.
READ
La struttura di risposta include un booleano che è TRUE se è stata incontrata la fine del file durante la READ. Questo consente al client di rilevare correttamente la fine del file.
WRITE
I campi beginoffset e totalcount sono stati rimossi dagli argomenti WRITE. La risposta ora include un conteggio in modo che il server possa scrivere meno della quantità di dati richiesta, se necessario. È stato aggiunto un indicatore agli argomenti per istruire il server sul livello di sincronizzazione della cache richiesto dal client.
CREATE
Un flag esclusivo e un verificatore di creazione sono stati aggiunti per la creazione esclusiva di file regolari.
MKNOD
Questa procedura è stata aggiunta per supportare la creazione di file speciali. Questo evita il sovraccarico di CREATE come è stato fatto in alcune implementazioni del protocollo NFS versione 2.
READDIR
Gli argomenti READDIR ora includono un verificatore per consentire al server di validare il cookie. Il cookie è ora un intero senza segno a 64 bit invece dell'array di 4 byte utilizzato nel protocollo NFS versione 2. Questo aiuterà a ridurre i problemi di interoperabilità.
READDIRPLUS
Questa procedura è stata aggiunta per restituire handle di file e attributi in un elenco di directory esteso.
FSINFO
FSINFO è stato aggiunto per fornire informazioni non volatili su un file system. La risposta include la dimensione di trasferimento di lettura preferita e massima, la dimensione di trasferimento di scrittura preferita e massima, e flag che indicano se sono supportati i link o i link simbolici. Vengono anche restituite la dimensione di trasferimento preferita per le risposte della procedura READDIR, la granularità temporale del server e se i tempi possono essere impostati in una richiesta SETATTR.
FSSTAT
FSSTAT è stato aggiunto per fornire informazioni volatili su un file system, per l'uso da parte di utility come il comando df del sistema Unix. La risposta include la dimensione totale e lo spazio libero nel file system specificato in byte, il numero totale di file e il numero di slot di file liberi nel file system, e una stima del tempo tra le modifiche del file system (per l'uso negli algoritmi di controllo della coerenza della cache).
COMMIT
La procedura COMMIT fornisce il meccanismo di sincronizzazione da utilizzare con le operazioni WRITE asincrone.
2. Informazioni RPC (RPC Information)
2.1 Autenticazione (Authentication)
Il servizio NFS utilizza AUTH_NONE nella procedura NULL. AUTH_UNIX, AUTH_DES o AUTH_KERB sono utilizzati per tutte le altre procedure. Altri tipi di autenticazione potrebbero essere supportati in futuro.
2.2 Costanti (Constants)
Queste sono le costanti RPC necessarie per chiamare il servizio NFS versione 3. Sono fornite in decimale.
PROGRAM 100003
VERSION 3
2.3 Indirizzo di trasporto (Transport address)
Il protocollo NFS è normalmente supportato sui protocolli TCP e UDP. Utilizza la porta 2049, la stessa del protocollo NFS versione 2.
2.4 Dimensioni (Sizes)
Queste sono le dimensioni, espresse in byte decimali, di varie strutture XDR utilizzate nel protocollo NFS versione 3:
NFS3_FHSIZE 64
- La dimensione massima in byte dell'handle di file opaco.
NFS3_COOKIEVERFSIZE 8
- La dimensione in byte del verificatore di cookie opaco passato da READDIR e READDIRPLUS.
NFS3_CREATEVERFSIZE 8
- La dimensione in byte del verificatore opaco utilizzato per CREATE esclusivo.
NFS3_WRITEVERFSIZE 8
- La dimensione in byte del verificatore opaco utilizzato per WRITE asincrono.
2.5 Tipi di dati di base (Basic Data Types)
Le seguenti definizioni XDR sono definizioni di base utilizzate in altre strutture.
uint64
typedef unsigned hyper uint64;
int64
typedef hyper int64;
uint32
typedef unsigned long uint32;
int32
typedef long int32;
filename3
typedef string filename3<>;
nfspath3
typedef string nfspath3<>;
fileid3
typedef uint64 fileid3;
cookie3
typedef uint64 cookie3;
cookieverf3
typedef opaque cookieverf3[NFS3_COOKIEVERFSIZE];
createverf3
typedef opaque createverf3[NFS3_CREATEVERFSIZE];
writeverf3
typedef opaque writeverf3[NFS3_WRITEVERFSIZE];
uid3
typedef uint32 uid3;
gid3
typedef uint32 gid3;
size3
typedef uint64 size3;
offset3
typedef uint64 offset3;
mode3
typedef uint32 mode3;
count3
typedef uint32 count3;
nfsstat3
enum nfsstat3 {
NFS3_OK = 0,
NFS3ERR_PERM = 1,
NFS3ERR_NOENT = 2,
NFS3ERR_IO = 5,
NFS3ERR_NXIO = 6,
NFS3ERR_ACCES = 13,
NFS3ERR_EXIST = 17,
NFS3ERR_XDEV = 18,
NFS3ERR_NODEV = 19,
NFS3ERR_NOTDIR = 20,
NFS3ERR_ISDIR = 21,
NFS3ERR_INVAL = 22,
NFS3ERR_FBIG = 27,
NFS3ERR_NOSPC = 28,
NFS3ERR_ROFS = 30,
NFS3ERR_MLINK = 31,
NFS3ERR_NAMETOOLONG = 63,
NFS3ERR_NOTEMPTY = 66,
NFS3ERR_DQUOT = 69,
NFS3ERR_STALE = 70,
NFS3ERR_REMOTE = 71,
NFS3ERR_BADHANDLE = 10001,
NFS3ERR_NOT_SYNC = 10002,
NFS3ERR_BAD_COOKIE = 10003,
NFS3ERR_NOTSUPP = 10004,
NFS3ERR_TOOSMALL = 10005,
NFS3ERR_SERVERFAULT = 10006,
NFS3ERR_BADTYPE = 10007,
NFS3ERR_JUKEBOX = 10008
};
Il tipo nfsstat3 viene restituito con i risultati di ogni procedura, eccetto la procedura NULL. Un valore di NFS3_OK indica che la chiamata è stata completata con successo. Qualsiasi altro valore indica che si è verificato un errore nella chiamata, identificato dal codice di errore. Si noti che deve essere seguita la codifica numerica precisa. Nessun altro valore può essere restituito da un server. I server sono tenuti a fare il miglior sforzo possibile per mappare le condizioni di errore all'insieme di codici di errore definiti. Inoltre, questa specifica non specifica alcuna precedenza di errore. Le precedenze di errore determinano il valore di errore che dovrebbe essere restituito quando più errori si applicano in una determinata situazione. La precedenza di errore sarà determinata dall'implementazione individuale del server. Se il client richiede precedenze di errore specifiche, dovrebbe controllare autonomamente gli errori specifici.
2.6 Numeri di errore definiti (Defined Error Numbers)
Segue una descrizione di ciascun errore definito:
NFS3_OK
- Indica che la chiamata è stata completata con successo.
NFS3ERR_PERM
- Non proprietario. L'operazione non è stata consentita perché il chiamante non è un utente privilegiato (root) o non è il proprietario del target dell'operazione.
NFS3ERR_NOENT
- File o directory inesistente. Il nome del file o della directory specificato non esiste.
NFS3ERR_IO
- Errore di I/O. Si è verificato un errore hardware (ad esempio, un errore del disco) durante l'elaborazione dell'operazione richiesta.
NFS3ERR_NXIO
- Errore di I/O. Nessun dispositivo o indirizzo di questo tipo.
NFS3ERR_ACCES
- Permesso negato. Il chiamante non ha il permesso corretto per eseguire l'operazione richiesta. Confronta questo con NFS3ERR_PERM, che si limita ai fallimenti di permesso del proprietario o dell'utente privilegiato.
NFS3ERR_EXIST
- Il file esiste. Il file specificato esiste già.
NFS3ERR_XDEV
- Tentativo di creare un hard link tra dispositivi diversi.
NFS3ERR_NODEV
- Nessun dispositivo di questo tipo.
NFS3ERR_NOTDIR
- Non è una directory. Il chiamante ha specificato una non-directory in un'operazione di directory.
NFS3ERR_ISDIR
- È una directory. Il chiamante ha specificato una directory in un'operazione non-directory.
NFS3ERR_INVAL
- Argomento non valido o argomento non supportato per un'operazione. Due esempi sono il tentativo di eseguire un READLINK su un oggetto diverso da un link simbolico o il tentativo di eseguire un SETATTR di un campo temporale su un server che non supporta questa operazione.
NFS3ERR_FBIG
- File troppo grande. L'operazione avrebbe causato la crescita di un file oltre il limite del server.
NFS3ERR_NOSPC
- Nessuno spazio rimasto sul dispositivo. L'operazione avrebbe causato il superamento del limite del file system del server.
NFS3ERR_ROFS
- File system di sola lettura. È stata tentata un'operazione di modifica su un file system di sola lettura.
NFS3ERR_MLINK
- Troppi hard link.
NFS3ERR_NAMETOOLONG
- Il nome del file in un'operazione era troppo lungo.
NFS3ERR_NOTEMPTY
- È stato tentato di rimuovere una directory che non era vuota.
NFS3ERR_DQUOT
- Limite rigido della risorsa (quota) superato. Il limite di risorse dell'utente sul server è stato superato.
NFS3ERR_STALE
- Handle di file non valido. L'handle di file fornito negli argomenti non era valido. Il file a cui fa riferimento quell'handle di file non esiste più o l'accesso ad esso è stato revocato.
NFS3ERR_REMOTE
- Troppi livelli di remoto nel percorso. L'handle di file fornito negli argomenti faceva riferimento a un file su un file system non locale sul server.
NFS3ERR_BADHANDLE
- Handle di file NFS illegale. L'handle di file ha fallito i controlli di coerenza interna.
NFS3ERR_NOT_SYNC
- Rilevata mancata corrispondenza della sincronizzazione dell'aggiornamento durante un'operazione SETATTR.
NFS3ERR_BAD_COOKIE
- Il cookie READDIR o READDIRPLUS è obsoleto.
NFS3ERR_NOTSUPP
- L'operazione non è supportata.
NFS3ERR_TOOSMALL
- Il buffer o la richiesta è troppo piccola.
NFS3ERR_SERVERFAULT
- Si è verificato un errore sul server che non corrisponde a nessuno dei valori di errore legali del protocollo NFS versione 3. Il client dovrebbe tradurlo in un errore appropriato. I client UNIX possono scegliere di tradurlo in EIO.
NFS3ERR_BADTYPE
- È stato tentato di creare un oggetto di un tipo non supportato dal server.
NFS3ERR_JUKEBOX
- Il server ha avviato la richiesta, ma non è stato in grado di completarla in modo tempestivo. Il client dovrebbe attendere e quindi riprovare la richiesta con un nuovo ID di transazione RPC. Ad esempio, questo errore dovrebbe essere restituito da un server che supporta l'archiviazione gerarchica e riceve una richiesta di elaborazione di un file che è stato migrato. In questo caso, il server dovrebbe avviare il processo di immigrazione e rispondere al client con questo errore.
ftype3
enum ftype3 {
NF3REG = 1,
NF3DIR = 2,
NF3BLK = 3,
NF3CHR = 4,
NF3LNK = 5,
NF3SOCK = 6,
NF3FIFO = 7
};
L'enumerazione ftype3 fornisce il tipo di un file. Il tipo NF3REG è un file regolare, NF3DIR è una directory, NF3BLK è un file dispositivo a blocchi speciale, NF3CHR è un file dispositivo a caratteri speciale, NF3LNK è un link simbolico, NF3SOCK è un socket e NF3FIFO è una pipe con nome. Si noti che deve essere seguita la codifica enum precisa.
specdata3
struct specdata3 {
uint32 specdata1;
uint32 specdata2;
};
L'interpretazione delle due parole dipende dal tipo di oggetto del file system. Per un file speciale a blocchi (NF3BLK) o a caratteri (NF3CHR), specdata1 e specdata2 sono rispettivamente i numeri di dispositivo major e minor. (Questa è ovviamente un'interpretazione specifica di UNIX.) Per tutti gli altri tipi di file, questi due elementi dovrebbero essere impostati su 0 oppure i valori dovrebbero essere concordati tra client e server. Se il client e il server non concordano sui valori, il client dovrebbe trattare questi campi come se fossero impostati su 0. Questo campo dati viene restituito come parte della struttura fattr3 ed è quindi disponibile da tutte le risposte che restituiscono attributi. Poiché questi campi sono altrimenti inutilizzati per oggetti che non sono dispositivi, informazioni fuori banda possono essere passate dal server al client. Tuttavia, ancora una volta, sia il server che il client devono concordare sui valori passati.
nfs_fh3
struct nfs_fh3 {
opaque data<NFS3_FHSIZE>;
};
Il nfs_fh3 è l'oggetto opaco a lunghezza variabile restituito dal server nelle operazioni LOOKUP, CREATE, SYMLINK, MKNOD, LINK o READDIRPLUS, che viene utilizzato dal client nelle operazioni successive per fare riferimento al file. L'handle di file contiene tutte le informazioni di cui il server ha bisogno per distinguere un singolo file. Per il client, l'handle di file è opaco. Il client memorizza gli handle di file per l'uso in una richiesta successiva e può confrontare due handle di file dallo stesso server per l'uguaglianza eseguendo un confronto byte per byte, ma non può interpretare altrimenti il contenuto degli handle di file. Se due handle di file dallo stesso server sono uguali, devono fare riferimento allo stesso file, ma se non sono uguali, non si possono trarre conclusioni. I server dovrebbero cercare di mantenere una corrispondenza uno-a-uno tra handle di file e file, ma questo non è richiesto. I client dovrebbero utilizzare i confronti di handle di file solo per migliorare le prestazioni, non per un comportamento corretto.
I server possono revocare l'accesso fornito da un handle di file in qualsiasi momento. Se l'handle di file passato in una chiamata fa riferimento a un oggetto del file system che non esiste più sul server o se l'accesso per quell'handle di file è stato revocato, deve essere restituito l'errore NFS3ERR_STALE.
nfstime3
struct nfstime3 {
uint32 seconds;
uint32 nseconds;
};
La struttura nfstime3 fornisce il numero di secondi e nanosecondi dalla mezzanotte del 1° gennaio 1970, ora media di Greenwich. Viene utilizzata per passare informazioni su data e ora. I tempi associati ai file sono tutti tempi del server, tranne nel caso di un'operazione SETATTR in cui il client può impostare esplicitamente l'ora del file. Un server converte da e verso l'ora locale durante l'elaborazione dei valori temporali, preservando la maggior precisione possibile. Se la precisione dei timestamp memorizzati per un file è inferiore a quella definita dal protocollo NFS versione 3, può verificarsi una perdita di precisione. Si raccomanda un protocollo ausiliario di manutenzione del tempo per ridurre lo scostamento temporale tra client e server.
fattr3
struct fattr3 {
ftype3 type;
mode3 mode;
uint32 nlink;
uid3 uid;
gid3 gid;
size3 size;
size3 used;
specdata3 rdev;
uint64 fsid;
fileid3 fileid;
nfstime3 atime;
nfstime3 mtime;
nfstime3 ctime;
};
Questa struttura definisce gli attributi di un oggetto del file system. Viene restituita dalla maggior parte delle operazioni su un oggetto; nel caso di operazioni che influenzano due oggetti (ad esempio, un MKDIR che modifica gli attributi della directory di destinazione e definisce nuovi attributi per la directory appena creata), gli attributi di entrambi possono essere restituiti. In alcuni casi, gli attributi vengono restituiti nella struttura wcc_data, definita di seguito; in altri casi gli attributi vengono restituiti da soli. Le principali modifiche rispetto al protocollo NFS versione 2 sono che molti dei campi sono stati ampliati e le informazioni sul dispositivo major/minor sono ora presentate in una struttura distinta anziché essere impacchettate in una parola.
La struttura fattr3 contiene gli attributi di base di un file. Tutti i server dovrebbero supportare questo insieme di attributi anche se devono simulare alcuni dei campi. Type è il tipo del file. Mode sono i bit della modalità di protezione. Nlink è il numero di hard link al file, cioè il numero di nomi diversi per lo stesso file. Uid è l'ID utente del proprietario del file. Gid è l'ID del gruppo del file. Size è la dimensione del file in byte. Used è il numero di byte di spazio su disco che il file utilizza effettivamente (che può essere inferiore alla dimensione perché il file può avere buchi o può essere maggiore a causa della frammentazione). Rdev descrive il file del dispositivo se il tipo di file è NF3CHR o NF3BLK - vedi specdata3 a pagina 20. Fsid è l'identificatore del file system per il file system. Fileid è un numero che identifica univocamente il file all'interno del suo file system (su UNIX questo sarebbe l'inumber). Atime è il momento in cui i dati del file sono stati acceduti per l'ultima volta. Mtime è il momento in cui i dati del file sono stati modificati per l'ultima volta. Ctime è il momento in cui gli attributi del file sono stati modificati per l'ultima volta. La scrittura nel file modifica il ctime oltre al mtime.
I bit della modalità sono definiti come segue:
0x00800 Imposta ID utente all'esecuzione.
0x00400 Imposta ID gruppo all'esecuzione.
0x00200 Salva testo scambiato (non definito in POSIX).
0x00100 Permesso di lettura per il proprietario.
0x00080 Permesso di scrittura per il proprietario.
0x00040 Permesso di esecuzione per il proprietario su un file. O permesso di ricerca (lookup) per il proprietario nella directory.
0x00020 Permesso di lettura per il gruppo.
0x00010 Permesso di scrittura per il gruppo.
0x00008 Permesso di esecuzione per il gruppo su un file. O permesso di ricerca (lookup) per il gruppo nella directory.
0x00004 Permesso di lettura per altri.
0x00002 Permesso di scrittura per altri.
0x00001 Permesso di esecuzione per altri su un file. O permesso di ricerca (lookup) per altri nella directory.
post_op_attr
union post_op_attr switch (bool attributes_follow) {
case TRUE:
fattr3 attributes;
case FALSE:
void;
};
Questa struttura viene utilizzata per restituire attributi in quelle operazioni che non sono direttamente coinvolte nella manipolazione degli attributi. Uno dei principi di questa revisione del protocollo NFS è restituire il valore reale dall'operazione indicata e non un errore da un'operazione accessoria. La struttura post_op_attr è stata progettata per consentire al server di recuperare da errori riscontrati durante l'ottenimento degli attributi.
Questo sembra rendere opzionale la restituzione degli attributi. Tuttavia, gli implementatori di server sono fortemente incoraggiati a fare il miglior sforzo per restituire gli attributi quando possibile, anche quando si restituisce un errore.
wcc_attr
struct wcc_attr {
size3 size;
nfstime3 mtime;
nfstime3 ctime;
};
Questo è il sottoinsieme di attributi di pre-operazione necessari per supportare meglio la semantica della coerenza della cache debole. Size è la dimensione del file in byte dell'oggetto prima dell'operazione. Mtime è il momento dell'ultima modifica dell'oggetto prima dell'operazione. Ctime è il momento dell'ultima modifica degli attributi dell'oggetto prima dell'operazione. Vedi la discussione in wcc_attr a pagina 24.
L'uso di mtime da parte dei client per rilevare le modifiche agli oggetti del file system che risiedono su un server dipende dalla granularità della base temporale sul server.
pre_op_attr
union pre_op_attr switch (bool attributes_follow) {
case TRUE:
wcc_attr attributes;
case FALSE:
void;
};
wcc_data
struct wcc_data {
pre_op_attr before;
post_op_attr after;
};
Quando un client esegue un'operazione che modifica lo stato di un file o di una directory sul server, non può determinare immediatamente dagli attributi di post-operazione se l'operazione appena eseguita è stata l'unica operazione sull'oggetto dall'ultima volta che il client ha ricevuto gli attributi per l'oggetto. Questo è importante, perché se un'operazione intermedia ha modificato l'oggetto, il client dovrà invalidare tutti i dati memorizzati nella cache per l'oggetto (tranne i dati che ha appena scritto).
Per gestire questo, viene introdotta la nozione di dati di coerenza della cache debole o wcc_data. Una struttura wcc_data consiste di alcuni campi chiave degli attributi dell'oggetto prima dell'operazione, insieme agli attributi dell'oggetto dopo l'operazione. Queste informazioni consentono al client di gestire la propria cache in modo più accurato rispetto alle implementazioni del protocollo NFS versione 2. Il termine coerenza della cache debole sottolinea il fatto che questo meccanismo non fornisce la stretta coerenza server-client che un protocollo di coerenza della cache fornirebbe.
Per supportare il modello di coerenza della cache debole, il server dovrà essere in grado di ottenere gli attributi di pre-operazione dell'oggetto, eseguire l'operazione di modifica prevista e quindi ottenere gli attributi di post-operazione in modo atomico. Se esiste una finestra per la modifica dell'oggetto tra l'operazione e una delle operazioni di ottenimento degli attributi, allora il client non sarà in grado di determinare se era l'unica entità a modificare l'oggetto. Alcune informazioni saranno andate perse, indebolendo così le garanzie di coerenza della cache debole.
post_op_fh3
union post_op_fh3 switch (bool handle_follows) {
case TRUE:
nfs_fh3 handle;
case FALSE:
void;
};
Uno dei principi di questa revisione del protocollo NFS è restituire il valore reale dall'operazione indicata e non un errore da un'operazione accessoria. La struttura post_op_fh3 è stata progettata per consentire al server di recuperare da errori riscontrati durante la costruzione di un handle di file.
Questa è la struttura utilizzata per restituire un handle di file dalle richieste CREATE, MKDIR, SYMLINK, MKNOD e READDIRPLUS. In ogni caso, il client può ottenere l'handle di file emettendo una richiesta LOOKUP dopo un ritorno riuscito da una delle operazioni elencate. La restituzione dell'handle di file è un'ottimizzazione in modo che il client non sia costretto a emettere immediatamente una richiesta LOOKUP per ottenere l'handle di file.
sattr3
enum time_how {
DONT_CHANGE = 0,
SET_TO_SERVER_TIME = 1,
SET_TO_CLIENT_TIME = 2
};
union set_mode3 switch (bool set_it) {
case TRUE:
mode3 mode;
default:
void;
};
union set_uid3 switch (bool set_it) {
case TRUE:
uid3 uid;
default:
void;
};
union set_gid3 switch (bool set_it) {
case TRUE:
gid3 gid;
default:
void;
};
union set_size3 switch (bool set_it) {
case TRUE:
size3 size;
default:
void;
};
union set_atime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 atime;
default:
void;
};
union set_mtime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 mtime;
default:
void;
};
struct sattr3 {
set_mode3 mode;
set_uid3 uid;
set_gid3 gid;
set_size3 size;
set_atime atime;
set_mtime mtime;
};
La struttura sattr3 contiene gli attributi del file che possono essere impostati dal client. I campi sono gli stessi dei campi con nome simile nella struttura fattr3. Nel protocollo NFS versione 3, gli attributi impostabili sono descritti da una struttura contenente un insieme di unioni discriminate. Ogni unione indica se l'attributo corrispondente deve essere aggiornato e, in tal caso, come.
Vengono utilizzate due forme di unioni discriminate. Nell'impostazione di mode, uid, gid o size, l'unione discriminata viene commutata su un booleano, set_it; se è TRUE, viene quindi codificato un valore del tipo appropriato.
Nell'impostazione di atime o mtime, l'unione viene commutata su un tipo di enumerazione, set_it. Se set_it ha il valore DONT_CHANGE, l'attributo corrispondente rimane invariato. Se ha il valore SET_TO_SERVER_TIME, l'attributo corrispondente viene impostato dal server alla sua ora locale; nessun dato viene fornito dal client. Infine, se set_it ha il valore SET_TO_CLIENT_TIME, l'attributo viene impostato all'ora passata dal client in una struttura nfstime3. (Vedi FSINFO a pagina 86, che affronta la questione della granularità temporale).
diropargs3
struct diropargs3 {
nfs_fh3 dir;
filename3 name;
};
La struttura diropargs3 viene utilizzata nelle operazioni di directory. L'handle di file, dir, identifica la directory in cui manipolare o accedere al file, name. Vedi commenti aggiuntivi in Gestione dei componenti del nome file a pagina 101.