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.
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.
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/
-
frnog＠lumia.net -
Jonathan Leroy -
Kevin Lemonnier -
Ludovic Scotti -
Rémy Sanchez