Fonds Linux
  1. Fonds Linux
  3. Comment Linux lit-il les "files réels" et les "files virtuels"?
Intereting Posts
Impossible de find le périphérique "eth0" comment envoyer des mots ftp natifs à un server ftp? Comment continuer un script après le redémarrage de la machine? Comment éviter la suppression inutile et la recopy des dossiers déplacés lors de l'utilisation de rsync? Le WiFi ne fonctionne pas avec le pilote Broadcom 43ba Pourquoi j'obtiens une erreur: "Impossible d'ouvrir '/ dev / st0'" lors de l'extraction d'une archive avec bsdtar? Comment find une balise contenant une validation? Comment itérer sur deux sets d'iterables dans un script shell? Comment installer / parsingr les dependencies de construction de debian / control? Comment créer une queue délimitée pour les tâches shell? Y a-t-il des shells qui supportent les variables typées et les arrays multidimensionnels? Impossible de find mon input dans une string en utilisant grep utilisant montre avec ssh Puis-je décompresser un file zip contenant une image disque, puis l'save en une seule fois sur une carte SD? Comment save des appels Skype (audio) sur Debian 6?

Comment Linux lit-il les "files réels" et les "files virtuels"?

Je suis nouveau sur Linux, j'ai découvert qu'il y a des "files réels" sous Linux et qu'il y a des "files virtuels", les files réels sont des files qui se trouvent sur le disque dur, alors que les files virtuels ne sont que des données représentées par le kernel sous forme de files .

Par exemple, les files du /proc sont des files virtuels.

Je veux comprendre comment une fonction comme read() sait comment lire un file réel et comment lire un file virtuel. J'ai créé le diagramme suivant pour montrer ma compréhension de ce sujet, s'il vous plaît corrigez-moi si j'ai tort de ma compréhension:

entrer la description de l'image ici

Dans la couche VFS, tous les files sont virtuels (ils ont été inventés par les ingénieurs SunOS pour lier les filesystems UFS (sur disque) et NFS (réseau)).

Chaque file ouvert a une table de fonctions f_op qui fournit des implémentations pour des routines communes (certaines peuvent être generics) et chaque inode a un object address_space attaché qui a aussi une table de fonctions C ( a_ops ) contenant les implémentations nécessaires. La séquence est la suivante:

  1. sys_read() : l'application lance la lecture de file à l'aide d'un appel système
  2. L'appel est passé à la couche supérieure de la stack VFS ( vfs_read() )
  3. L'appel est passé au pilote du système de files en utilisant file->f_op->read() ou do_sync_read() ou new_sync_read()
  4. Si le file est ouvert en mode de sortie d'input directe, la fonction appropriée ( a_ops->direct_IO() , ext4_direct_IO() pour ext4 ) est appelée et datatables sont renvoyées
  5. Si la page est trouvée dans le cache de page, datatables sont renvoyées file_get_page()
  6. Si la page n'a pas été trouvée dans le cache de page, elle est lue à partir du système de files en utilisant a_ops->readpage() , qui est implémenté par ext4_readpage() partir du pilote ext4
  7. La stack VFS crée une request d'input-sortie de bloc à l'aide de submit_bio()

De http://myaut.github.io/dtrace-stap-book/kernel/fs.html , il est un peu obsolète que la stack VFS a été refactorisée un peu après que j'aie écrit ceci

Je ne vais pas donner une réponse exhaustive à ce sujet par tous les moyens …

Vous êtes essentiellement correct, à l'exception d'une séparation importante: read () request au kernel ce qu'un descripteur de file contient, le kernel gère le rest. Qu'il s'agisse d'un système de files physique, d'un système de files réseau, d'un système de files virtuel (/ proc, / sys, …) n'est pas pertinent pour read () . Le kernel a un code sous-jacent pour traiter la requête (ou non), c'est ce que vous appelez un pilote.