Auteur Sujet: Date des fichiers sous Linux: atime mtime ctime  (Lu 19325 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Date des fichiers sous Linux: atime mtime ctime
« 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.
« Modifié: 25 septembre 2016 à 13:43:20 par corrector »

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Date des ficihers sous Linux: atime mtime ctime
« Réponse #1 le: 03 septembre 2016 à 22:47:48 »
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.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Date des ficihers sous Linux: atime mtime ctime
« Réponse #2 le: 03 septembre 2016 à 22:53:18 »
Citer
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é ?

corrector

  • Invité
Date des ficihers sous Linux: atime mtime ctime
« Réponse #3 le: 03 septembre 2016 à 22:58:33 »
Qui a dit qu'il était question de le rendre inaccessible ?
Pas moi.
Citer
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.
Citer
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.

corrector

  • Invité
Date des ficihers sous Linux: atime mtime ctime
« Réponse #4 le: 03 septembre 2016 à 22:59:22 »
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)

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Date des ficihers sous Linux: atime mtime ctime
« Réponse #5 le: 03 septembre 2016 à 23:01:34 »
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)

corrector

  • Invité
Date des ficihers sous Linux: atime mtime ctime
« Réponse #6 le: 04 septembre 2016 à 12:50:12 »
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).

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Date des ficihers sous Linux: atime mtime ctime
« Réponse #7 le: 04 septembre 2016 à 14:15:06 »
C'est quoi le souci vu que c'est désactivable et que depuis 2009 le defaut pour Linux c'est relatime pour ceux qui ne désactive pas atime.

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Date des ficihers sous Linux: atime mtime ctime
« Réponse #8 le: 04 septembre 2016 à 15:00:35 »
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.

corrector1

  • Invité
Date des ficihers sous Linux: atime mtime ctime
« Réponse #9 le: 04 septembre 2016 à 15:39:10 »
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.

mirtouf

  • Abonné Bbox fibre
  • *
  • Messages: 1 297
  • Chelles (77)
    • L'antre de la bête
Date des ficihers sous Linux: atime mtime ctime
« Réponse #10 le: 05 septembre 2016 à 11:10:35 »
C'est quoi le souci vu que c'est désactivable et que depuis 2009 le defaut pour Linux 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.

corrector

  • Invité
Date des fichiers sous Linux: atime mtime ctime
« Réponse #11 le: 25 septembre 2016 à 12:38:59 »
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...
Citer
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.