La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: corrector le 03 septembre 2016 à 22:40:04
-
Edit Vivien : Hors-jet où l'on parle des inode sous inux, et notamment de atime :
Tout fichier possède son unique inode. L'inode contient la totalité des informations sur le fichier, sauf le nom. Les inodes sont tous de même taille.
Les informations des inodes
- Type de fichier : -,d, l, c, p, b.
- Droits d'accès : par exemple : rwxr-x---
- Nombre de liens (physiques) : correspond au nombre de références c'est à dire au nombre de noms.
- UID : effectif du processus créateur ou affecté par chown.
- GID : effectif du processus créateur, affecté par chgrp ou hérité du répertoire.
- Taille du fichier.
- atime :date de la dernière lecture.
- mtime :date de la dernière modification.
- ctime :date de la dernière connexion.
- Adresse du fichier.
La problématique de atime est de générer des écritures d'inode pour chaque lecture.
Lors du montage d'un système de fichier EXT2 / EXT3/ EXT4, on a 3 choix :
- atime : mettre à jour les dates de dernier accès à un fichier sur le disque
- noatime : ne pas mettre à jour les date de dernier accès
- relatime : mettre à jour la date de dernier accès seulement si elle est plus ancienne que la date de modification
Cela se trouve dans /etc/fstab et defaults = prendre l'option par défault qui est relatime si j'ai bien compris
$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sdb3 during installation
UUID=36298b2e-ae80-42fe-b175-01437ef1620b / ext4 errors=remount-ro 0 1
# /home was on /dev/sdb6 during installation
UUID=e693ccd1-670f-497b-b6ef-d67f7fcfa6a3 /home ext4 defaults 0 2
# swap was on /dev/sdb5 during installation
UUID=2f0703f8-e5ec-4e0a-87d2-db62d56f650b none swap sw 0 0
Message de corrector ci-dessous :
Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !
Je n'ai jamais pensé que tu voudrais "préserver" le atime évidemment, d'ailleurs je ne comprends pas ce que ça veut dire!
Recopier un fichier ou une hiérarchie de fichiers, c'est recopier les attributs pertinents de ces fichiers.
. (avec les options qui vont bien, ça va de soi)
Foutaise. Ce que tu décris n'existe pas en Unix, quelles que soient les options, c'est juste impossible en général.
Chez un précédent client, il est utilisé pour déplacer les données peu accédées sur des unités de stockage "lentes", voire de les archiver sur bandes, afin de réduire le coût de conservation de ces données sur le long terme.
Et donc si un fichier n'est jamais lu par un logiciel en fonctionnement typique, tu penses que tu peux te permettre rendre inaccessible ce fichier? Et que donc un processus qui ne trouverait dans le cas particulier d'avoir besoin d'y accéder soit bloqué?
Bizarre.
Chez mon client actuel, il est utilisé par les gestionnaires d'une arborescence tampon afin d'y faire du ménage.
C'est en effet l'usage traditionnel de cet attribut sous Unix.
Tu n'as pas idée du nombre d'entreprises qui utilisent des données en mode WORM et pour lesquelles l'information utile n'est pas de savoir quand le fichier a été modifié pour la dernière fois (puisqu'il est créé sans plus jamais être modifié par la suite), mais quand il a été effectivement utilisé pour la dernière fois.
atime ne permet pas de connaitre la fréquence d'utilisation d'un fichier, sauf à collecter très régulièrement les atime de tous les fichiers pour faire des stats.
Cet attribut est très rarement utilisé, sa gestion entraîne donc un surcoût inutile dans 99% des cas, et le surcoût peut être considérable. C'est donc une misfeature de Unix. Je ne suis pas le seul à le dire.
De toute manière, c'est une donnée d'audit choisie certainement pour sa simplicité, mais qui reste arbitraire (pourquoi pas le nombre de modifications par pas de 1 h, 1 j...). Si on veut des fonctions d'audit sur la fréquence d'utilisation des fichiers, on devrait pouvoir le faire via les options d'audit/sécurisation du système.
Bref, j'en ai assez de tes absurdités.
-
Et donc si un fichier n'est jamais lu par un logiciel en fonctionnement typique, tu penses que tu rendre inaccessible ce fichier? Et que donc un processus qui ne trouverait dans le cas particulier d'avoir besoin d'y accéder soit bloqué?
Qui a dit qu'il était question de le rendre inaccessible ?
Pas moi.
atime ne permet pas de connaitre la fréquence d'utilisation d'un fichier, sauf à collecter très régulièrement les atime de tous les fichiers pour faire des stats.
Qui a dit qu'il était question de connaître la fréquence d'utilisation ?
Pas moi.
Cet attribut est très rarement utilisé, sa gestion entraîne donc un surcoût inutile dans 99% des cas, et le surcoût peut être considérable. C'est donc une misfeature de Unix. Je ne suis pas le seul à le dire.
Ce qui ne change rien au fait qu'il est parfaitement utile.
Le fait que toi et d'autres n'y voient aucune utilité n'y changera rien.
-
Cet attribut est très rarement utilisé, sa gestion entraîne donc un surcoût inutile dans 99% des cas, et le surcoût peut être considérable. C'est donc une misfeature de Unix. Je ne suis pas le seul à le dire.
Est-ce que tu peux me citer un seul système de fichier utilisé dans le monde et qui ne dispose pas de cette fonctionnalité ?
-
Qui a dit qu'il était question de le rendre inaccessible ?
Pas moi.
déplacer les données peu accédées sur des unités de stockage "lentes", voire de les archiver sur bandes
Sur bande, le fichier n'est plus accessible. Tu ne vas pas faire un mount d'une bande, quand même?
Qui a dit qu'il était question de connaître la fréquence d'utilisation ?
Pas moi.
déplacer les données peu accédées sur des unités de stockage "lentes"
Bref, tu confirmes qu'en plus de ne pas comprendre Unix, le C, la programmation et l'informatique en général, tu ne sais pas ce que tu racontes.
-
Est-ce que tu peux me citer un seul système de fichier utilisé dans le monde et qui ne dispose pas de cette fonctionnalité ?
Tous
(SAUF BIEN SUR CEUX QUI SONT CONÇUS POUR UNIX ALORS OUI ILS ONT CETTE FONCTION SINON IL NE S'AGIRAIT PAS DE FS POUR UNIX)
-
Tous ne disposent pas de la fonctionnalité atime ?
Ça veut dire qu'aucun FS ne sait faire du atime ?
Ben alors, y'a pas de soucis :)
La "misfeature d'unix" n'existe donc pas, puisqu'aucun FS ne l'implèmente.
(pour info, la majorité des FS, si ce n'est tous, implèmente cette fonctionnalité, incluant ntfs ET fat)
-
Tous ne disposent pas de la fonctionnalité atime ?
Tous ceux qui ne sont pas nés avec la contrainte de l'avoir
Ça veut dire qu'aucun FS ne sait faire du atime ?
Aucun en dehors du monde Unix (au sens strict).
-
C'est quoi le souci vu que c'est désactivable et que depuis 2009 le defaut pour Linux (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a1c01c9477602ee8b44548a9405b2c1d587b5a2) c'est relatime pour ceux qui ne désactive pas atime.
-
Sur bande, le fichier n'est plus accessible. Tu ne vas pas faire un mount d'une bande, quand même?
https://en.wikipedia.org/wiki/Linear_Tape_File_System
Bref, tu confirmes qu'en plus de ne pas comprendre Unix, le C, la programmation et l'informatique en général, tu ne sais pas ce que tu racontes.
Et toi que tu n'as strictement aucune idée de la façon dont une entreprise gère ses données.
-
Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !
En quoi cp -a ne préserve pas les attributs?
Qu'est-ce que préserver les attributs?
En plus je parlais de copier des fichiers en tant qu'utilisateur normal et non faire des sauvegardes en tant qu'administrateur.
Vue ton ignorance sur l'utilité de l'attribut atime, je te retourne le compliment.
Je connais parfaitement les DEUX usages habituels de cet attribut : nettoyer les fichiers non utilisés, et les emails.
-
C'est quoi le souci vu que c'est désactivable et que depuis 2009 le defaut pour Linux (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a1c01c9477602ee8b44548a9405b2c1d587b5a2) c'est relatime pour ceux qui ne désactive pas atime.
Pas mieux, je ne me suis plus posé cette question depuis ReiserFS 3.6 il y a plus de 10 ans.
-
https://en.wikipedia.org/wiki/Linear_Tape_File_System
Et toi que tu n'as strictement aucune idée de la façon dont une entreprise gère ses données.
C'est marrant, ils ne parlent pas de l'impact du temps d'accès sur un processus normal...
While LTO seek times can range from 10 to 100 seconds
On va mettre un processus en attente jusqu'à 100 s au lieu de 100 ms, mais tout est normal.
-
C'est quoi le souci vu que c'est désactivable et que depuis 2009 le defaut pour Linux (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a1c01c9477602ee8b44548a9405b2c1d587b5a2) c'est relatime pour ceux qui ne désactive pas atime.
Sans les messages "You have new mail" et "You have mail", linux n'est plus Unix!
-
Tout fichier possède son unique inode. L'inode contient la totalité des informations sur le fichier, sauf le nom. Les inodes sont tous de même taille.
En Unix, le "nom du fichier" n'est même pas une information du fichier, mais une information du répertoire qui contient un "lien dur" vers le fichier.
Renommer un fichier ne modifie pas le fichier lui-même, et ne nécessite pas d'avoir le droit d'écrire dans le fichier. (Supprimer le fichier non plus, mais ça modifie évidemment l'inode du fichier.)
Les informations des inodes
- Type de fichier : -,d, l, c, p, b.
C'est la sortie de ls -l, les types de fichiers sont en réalité :
"-" : fichier régulier (regular), créé par open(2) ou touch(1)
"d" : répertoire (directory), créé par mkdir
"l" : lien symbolique (symlink), créé par symlink(2), ln(1)
"p" : pipe nommé (FIFO special file), créé par mkfifo
"c", "b" : périphérique (device), sémantique dépendante du driver (autant de sémantiques différentes que de familles de périphériques), peut aussi bien être une abstraction du matériel, donner l'accès direct à du matériel, correspondre à une abstraction logicielle
Et tu as omis :
"s" : socket UNIX nommée, créée par bind
- Taille du fichier.
Il y a plusieurs tailles :
- la taille apparente, c'est le nombre d'octets qu'on peut lire
- la taille sur disque, c'est l'espace occupé par la représentation du fichier dans le système de fichiers
- atime :date de la dernière lecture.
- mtime :date de la dernière modification.
- ctime :date de la dernière connexion.
Connexion? à quoi?
-
C'est marrant, ils ne parlent pas de l'impact du temps d'accès sur un processus normal...
On va mettre un processus en attente jusqu'à 100 s au lieu de 100 ms, mais tout est normal.
Le fait que l'utilisateur puisse avoir à attendre une ou deux minutes avant d'avoir effectivement accès aux données stockées sur cartouches est une conséquence jugée négligeable en regard des économies réalisées.
Et dans les faits, applications et utilisateurs vivent très bien avec.
Donc, oui, tout est normal.
Pour Vivien :
Le champ ctime correspond sous UNIX à la date de modification de l'inode (ex : modification des permissions du fichier.)
Chez Microsoft, il est interprété différemment et correspond à la date de création du fichier.
-
Le fait que l'utilisateur puisse avoir à attendre une ou deux minutes avant d'avoir effectivement accès aux données stockées sur cartouches est une conséquence jugée négligeable en regard des économies réalisées.
Et dans les faits, applications et utilisateurs vivent très bien avec.
Les utilisateurs peuvent peut être accepter d'attendre, s'ils savent pourquoi ils doivent attendre et s'ils pensent que c'est normal.
Sinon ils risquent de penser que l'application est plantée et la fermer de force.
Dans une processus réseau, c'est encore pire : un processus client risque d'atteindre un timeout et de relancer la transaction.