[MISC] - Desactiver la modification date acces fichiers sous Linux
Hello, j'étais en train de lire cet article : https://blog.seboss666.info/2017/02/quelques-pistes-doptimisation-pour-vos-m... dans le quel vous pourrez lire ce conseil : << La date d’accès d’un fichier n’a que peu d’intérêt, à moins de vouloir en faire des statistiques. Hors, mettre à jour cette date consomme des opérations disque >> La question que je pose est que effectivement trouvez-vous vraiment que << La date d’accès d’un fichier n’a que peu d’intérêt >> ? Et si oui dans quel cas ? (Je ne conteste pas que toute modification d'attribut de struct stat consomme du temps, bon je ne suis pas capable de le quantifier (et l'auteur du reste ne le fait pas) ) Juste en passant, tout de suite après il est écrit : ========================================================== 1 /dev/mapper/frontier--vg-root / ext4 noatime,nodiratime,errors=remount-ro 0 1 ========================================================== (exemple de paramétrage de la fstab) << Les noatime (pour no access time), nodiratime (no directory access time), sont là pour dire de ne plus mettre à jour l’accès. Quand pour info, ces valeurs sont disponibles avec la commande stat :>> Euh si tu ne mets pas à jour le atime comment veux-tu que la struct stat soit correctement renseignée ? Ou c'est auto-magique ? Ou c'est mal dit ? Ou j'ai loupé un truc ? Pour cette partie je vais demander à l'auteur. Bon we, Emilio
La question que je pose est que effectivement trouvez-vous vraiment que << La date d’accès d’un fichier n’a que peu d’intérêt >> ? Et si oui dans quel cas ?
Ça arrive d'utiliser les autres pour faire de la place, supprimer tous les fichiers qui ont plus de 2 ou 3 jours par exemple, mais la date d'accès .. J'ai du mal à imaginer une utilisation pour. Éventuellement lister les fichiers qui servent vraiment à quelque chose, qui pourraient être supprimé / déplacé sur un storage lent. Mais bon, c'est pas tous les jours. -- Kevin Lemonnier PGP Fingerprint : 89A5 2283 04A0 E6E9 0111
Dans mon taf on utilise souvent ces options sur des solutions de backup avec déduplication. Ca améliore en effet grandement les perfs Le 18 février 2017 à 20:34, Kevin Lemonnier <lemonnierk@ulrar.net> a écrit :
La question que je pose est que effectivement trouvez-vous vraiment que << La date d’accès d’un fichier n’a que peu d’intérêt >> ? Et si oui dans quel cas ?
Ça arrive d'utiliser les autres pour faire de la place, supprimer tous les fichiers qui ont plus de 2 ou 3 jours par exemple, mais la date d'accès .. J'ai du mal à imaginer une utilisation pour. Éventuellement lister les fichiers qui servent vraiment à quelque chose, qui pourraient être supprimé / déplacé sur un storage lent. Mais bon, c'est pas tous les jours.
-- Kevin Lemonnier PGP Fingerprint : 89A5 2283 04A0 E6E9 0111
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 18 février 2017 à 21:22, Ludovic Scotti <tontonlud@gmail.com> a écrit :
Dans mon taf on utilise souvent ces options sur des solutions de backup avec déduplication. Ca améliore en effet grandement les perfs
À noter que la plupart (toutes ?) les distribs récentes montent par défaut les partitions avec l'option "relatime", ce qui doit revenir plus ou moins au même niveau perfs. -- Jonathan Leroy.
Exactement, le problème du atime est résolu depuis longtemps avec relatime <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/Relatime.html> . On Sun, Feb 19, 2017 at 1:55 AM Jonathan Leroy <jonathan@unsigned.inikup.com> wrote:
Le 18 février 2017 à 21:22, Ludovic Scotti <tontonlud@gmail.com> a écrit :
Dans mon taf on utilise souvent ces options sur des solutions de backup avec déduplication. Ca améliore en effet grandement les perfs
À noter que la plupart (toutes ?) les distribs récentes montent par défaut les partitions avec l'option "relatime", ce qui doit revenir plus ou moins au même niveau perfs.
-- Jonathan Leroy. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- *Rémy Sanchez* http://hyperthese.net/
participants (5)
-
frnog＠lumia.net -
Jonathan Leroy -
Kevin Lemonnier -
Ludovic Scotti -
Rémy Sanchez