Question / etc / exports & option de montage


Sur mon serveur Linux, j'ai les options suivantes dans / etc / exports 

/home *(rw,sync,no_subtree_check,no_root_squash)

Et je monte depuis un Mac en utilisant

mount -t nfs -o resvport,rw,noatime,soft,intr,rsize=32768,wsize=32768,timeo=900,retrans=3,proto=tcp,vers=3,async 192.168.1.121:/home /Volumes/home

Comme vous pouvez le voir, le serveur spécifie le sync mais mon option de montage utilise async, alors lequel sera utilisé?


5
2018-04-14 08:06


origine


Votre système de fichiers local utilisera la synchronisation (/ home) et la télécommande utilisera async, autant que possible. - Brigo
Mise à jour de ma question: mon paramètre local est défini dans / etc / exports *, pas * fstab - Ryan


Réponses:


sync et async ont des significations différentes pour les deux situations différentes.

sync dans le contexte client, toutes les écritures dans le fichier sont validées sur le serveur. async provoque toutes les écritures dans le fichier ne pas être transmis au serveur immédiatement, généralement seulement lorsque le fichier est fermé. Donc, un autre hôte qui ouvre le même fichier ne verra pas les modifications apportées par le premier hôte.

Notez que NFS offre une cohérence "proche à ouverte", ce qui signifie que les autres clients ne peuvent pas en tous cas supposons que les données d’un fichier ouvert par d’autres personnes soient cohérentes (ou franchement, elles le sont du tout si vous n’utilisez pas nfslock ajouter une forme de synchronisation entre les clients).

sync dans le contexte du serveur (valeur par défaut), le serveur ne répond que pour indiquer que les données ont été écrites lorsque le système de stockage l'informe réellement des données était écrit. async dans le contexte du serveur, le serveur répond simplement comme si le fichier avait été écrit sur le serveur, qu'il le soit ou non. Ceci est beaucoup plus rapide mais aussi très dangereux car les données peuvent avoir un problème de validation!

Dans la plupart des cas, async côté client et sync sur le côté serveur. Cela offre un comportement assez cohérent en ce qui concerne le fonctionnement supposé de NFS.


17
2018-04-18 11:28





Fondamentalement, ce que dit MIfe; ces options sont sensibles au contexte. La partie importante se trouve dans les pages de manuel:

exports(5)
async   This option allows the NFS server to violate the NFS protocol and reply to
        requests before any changes made by that request have been committed to 
        stable storage  (e.g. disc drive).

et sur le client (Mac):

mount_nfs(8)
async   Assume that unstable write requests have actually been committed to stable
        storage on the server, and thus will not require resending in the event
        that the server crashes.

Remarque: sur un Mac, mount_nfs(8) déclare que le async l'option ne sera honorée que si le nfs.client.allow_async option dans nfs.conf(5) est également activé (peut également être défini via sysctl(8))

Donc, vous pouvez demander async sur le client et les demandes d’écriture supposent simplement qu’ils ont atteint leur serveur. Depuis que vous avez spécifié sync sur le serveur, il répondra aux demandes du client lorsque les données ont été réellement écrites sur le disque. (Bien entendu, vos systèmes de fichiers locaux sur le serveur peuvent également être montés avec "sync", bien que "async" semble être la valeur par défaut)

Un mot sur vos options de montage sur le client: * taille & taille sont définis par défaut sur 32768 pour les montages TCP. * proto = tcp est la valeur par défaut, retombera sur udp s'il n'est pas supporté par le serveur * vers = 3 est la valeur par défaut, sera réduit à 2 s'il n'est pas supporté par le serveur


0
2018-04-21 03:16