Skip to topic | Skip to bottom
Home
Minfo
Minfo.Tp6r1.2 - 13 Oct 2007 - 21:48 - NicolasNobelistopic end

Start of topic | Skip to actions

Problème de montage NFS

Lors du précédent TD, vous êtes nombreux à ne pas avoir pu monter le partage NFS dans le QEmu client. Le problème vient du client qui essaye d'effectuer un "remote locking" auprès du serveur.

Vous avez deux solutions pour contourner ce problème :

  • utiliser l'option nolock dans la commande mount.
  • lancer le démon portmap également sur le client.

Retours sur NFS

Suppression de fichier ouvert

Sous Unix, les fichiers ont un compteur de référence qui est incrémenté à chaque fois qu'un lien vers le fichier est créé et décrémenté quand les liens sont supprimés. Le fichier est supprimé du disque lorsque son compteur de référence atteint 0. Le compteur de référence est aussi incrémenté/décrementé lorsque le fichier est ouvert/fermé. Ceci permet de supprimer (commande rm) un fichier ouvert en sachant qu'il ne sera définitivement supprimé que lorsque le processus ayant ouvert le fichier le fermera.

Vous pouvez tester ce comportement sur le /tmp de votre machine physique :

  • Consultez l'espace disque restant (commande df).

  • Créez un gros fichier, puis vérifiez que l'espace disque restant a diminué.

  • Arrangez-vous pour qu'un processus garde le fichier ouvert, puis supprimez le fichier.

  • L'espace disque ne doit pas avoir diminué.

  • Récupérez l'espace disque.

La situation se complique sur NFS. Dans ce cas, lorsqu'un fichier est supprimé la commande de suppression est envoyée au serveur, qui l'exécute. Pour pouvoir continuer à travailler avec le fichier, le client NFS renomme le fichier en .nfsXXXXXXXXXXXXXXX avec un XXXXXXXXXXXXXXX unique, qui sera utilisé à la place du fichier supprimé. Ce fichier sera supprimé par le client selon les mêmes conditions que sur un système de fichier local.

Expérimentez cette fonctionnalité sur NFS. Les aventuriers pourront la tester sur leur NFS entre deux QEmu(s), les autres pourront utiliser leur compte normal qui est sur NFS pour cette manipulation.

Protection root

Les permissions des fichiers entre les clients et le serveur se basent sur les UID. Le cas du root est géré différemment: déterminez la protection à mettre en place pour se protéger des root sur les clients. Remarquez que cette manipulation ne pourra être effectuée que sur un montage NFS entre 2 QEmu.

Allocation dynamique et listes chaînées

L'objectif de cet exercice est d'implémenter une zone mémoire sous la forme d'un périphérique en mode caractère.

Cette mémoire est un FIFO avec buffer circulaire de grande capacité : 10 blocs (!). Étant donnée la taille du buffer, il ne s'agit pas d'allouer statiquement la mémoire une fois pour toutes, mais au contraire de l'allouer et de la désallouer dynamiquement par blocs. Pour simplifier, chaque bloc ne fera qu'un caractère.

Le buffer circulaire sera géré comme une liste chaînée de blocs de taille 1. Ces blocs seront alloués dynamiquement en utilisant kmalloc (fonctionnement similaire à malloc() : #include <linux/slab.h> kmalloc(taille, GFP_KERNEL*), retourne NULL en cas d'erreur) et libérés en utilisant kfree. La liste chaînée sera celle fournie par Linux dans include/linux/list.h. Vous l'avez vu en cours, et sa structure est rappelée dans ces liens : http://isis.poly.edu/kulesh/stuff/src/klist/ et http://wiki.kldp.org/wiki.php/LinkedList (recommandé).

Pensez bien à désallouer toute la mémoire allouée, dans la lecture (voir ci-dessous) et surtout au déchargement du module.

Pour que le debugging soit plus aisé, vous écrirez une fonction dump_list qui affichera avec printk le contenu de la liste et le nombre de bloc alloués.

Chaque écriture dans le fichier spécial correspond à la création de nouveaux blocs dans la liste. Quand la liste (donc le buffer) est pleine, les nouvelles données écrasent les anciennes (comportement FIFO).

Les opérations de lecture consultent le buffer en le vidant au fur et à mesure. La condition de fin de fichier est donc un buffer vide.

Bien sûr si vous avez fini, vous ajouterez la gestion adéquate des offsets...

HELP Vous pouvez passer deux valeurs à la seconde option de kmalloc : GFP_ATOMIC vous garantie que l'allocation sera atomique (i.e. faîte sur le moment sans bloquage), GFP_KERNEL n'est pas atomique mais cherche de la mémoire dans des endroits supplémentaires et a globalement moins de chance d'échouer que GFP_ATOMIC.

-- NicolasNobelis - 13 Oct 2007
to top


You are here: Minfo > ApprofondissementSysteme > Tp6

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WIKIDeptinfo? Send feedback