Montage autofs avec timeout et lien symbolique cassé : ls attend la pluie

Support Debian
#1

Bonjour,

Lorsque je démarre un disque dur spécifique dans un dock, j’ai configuré le système pour qu’une partition donnée se monte automatiquement (explications ici).
Dans mon répertoire $HOME/, j’ai un lien symbolique qui s’appelle mnt et qui pointe vers le point de montage décrit dans /etc/fstab. Et dans mon /home toujours, j’ai tout un tas de répertoires qui pointent vers mnt/quelque_chose. Je souhaite que ces répertoires restent sur le disque dur.

Seulement voilà : quand le disque dur est éteint (petit navire), mnt pointe vers quelque chose qui n’existe pas, la commande ls met presque 17 secondes à s’exécuter, voyez plutôt :

le-barde@ma-machine:~$ time ls
[contenu du dossier]

real	0m17,873s
user	0m0,001s
sys	0m0,004s
le-barde@ma-machine:~$

Je vois sur ce sujet reddit que c’est lié à la couleur. Donc si je fais ça sans la couleur, j’ai une réponse normale :

le-barde@ma-machine:~$ time ls
[contenu du dossier]

real	0m0,004s
user	0m0,004s
sys	0m0,000s
le-barde@ma-machine:~$

Voyez-vous un moyen d’avoir ls en (techni)color et de lui dire que s’il ne trouve pas, 'faut pas s’acharner ? Merci pour vos lumières !

#2

Sérieusement ? Forcément que ça met du temps, le disque est éteint, il faut le temps de se ralumer si le contenu du dossier n’est pas dans la mémoire de cache.

Oui, les couleurs, c’est de l’information inutile et très perturbante. Personnellement, je les ai désactivées, tous mes écrans en nuances de gris, c’est quand même plus reposant. Par contre, je me rends compte que certaines choses sont moins évidentes en nuances de gris, comme jouer à Color Zen sur Switch (genre COLOR Zen).

Non, le technicolor n’est pas très beau car les pellicules sont indépendantes, donc avec des décalages.

#3

La page de manuel pour systemd.automount contient :

Automount units may be used to implement on-demand mounting as well as parallelized mounting of file systems.

Ce que signifie « montage parallélisé » n’est pas clair pour moi, mais en revanche « à la demande » est clair : une tentative de montage est déclenchée automatiquement en cas d’accès au chemin du point de montage. Avec la coloration par défaut ls tente d’accéder à la cible de chaque lien symbolique pour vérifier si elle existe ou non et colorer le lien en bleu ou rouge. Tu as réglé le time-out à 2 secondes, donc il doit y avoir 8 ou 9 liens concernés dans le répertoire que tu listes.

Il y a peut-être moyen de configurer la coloration de ls avec dircolors pour ne pas vérifier la validité des liens symboliques.

#4

Oh @PascalHambourg tu es mon héros. Je vais voir (mais demain seulement) comment je peux me débrouiller avec ça, mais j’avoue que je suis impressionné par tes inductions.

#5

Assez étonnamment je n’ai plus ce souci :

le-barde@ma-machine:~$ time ls
[contenu du dossier]

real	0m0,004s
user	0m0,004s
sys	0m0,000s
le-barde@ma-machine:~$

Bizarre. Mais entre temps j’ai fait quelques umount, des systemctl daemon-reload && systemctl restart local-fs.target, et j’ai éteint et allumé deux-trois fois le dock.
On verra si le problème refait surface.

Petite question subsidiaire : avec ces options, si je veux éteindre le dock, comment démonter les disques ? Car si je fais umount ça se remonte aussi sec. À moins que ce soit acceptable d’éteindre les disques sans les démonter, mais j’ai toujours entendu le contraire pour du ext4 et btrfs.

#6

Non, il n’est pas acceptable d’éteindre ou débrancher un disque qui contient un système de fichiers monté. En principe avec tes options le système de fichiers auto-monté devrait être démonté automatiquement après 2 secondes de non utilisation (idle-timeout=2), ce qui me paraît quand même très court.

#7

Effectivement c’est court. Je viens de regarder la doc ici et là, effectivement c’est ce qui devrait se passer.

Je crois voir ce qui se passe. J’ai en réalité deux disques durs. Un WD_Black qui me sert de stockage actif, et un WD_Blue qui me sert pour la sauvegarde. Voici ce que j’ai mis dans le fstab :

UUID=ed5ac6e5-9fc3-4d28-b0b5-0c4833249c71 /mnt/home-black ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2
UUID=66433a8f-5d2f-4dad-9cb5-beebb246238f /mnt/blue       ext4  noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2,x-systemd.device-timeout=2

Il y a donc les mêmes options de montage.
Or voici ce que je fais :

le-barde@ma-machine:~$ ls /mnt/blue/ /mnt/home-black/ && mount
/mnt/blue/:
[...blabla...]

/mnt/home-black/:
[...blabla...]
[...contenu de la sortie de mount...]
systemd-1 on /mnt/home-black type autofs (rw,relatime,fd=35,pgrp=1,timeout=2,minproto=5,maxproto=5,direct,pipe_ino=15392)
systemd-1 on /mnt/blue type autofs (rw,relatime,fd=41,pgrp=1,timeout=2,minproto=5,maxproto=5,direct,pipe_ino=15399)
/dev/sdc8 on /mnt/home-black type ext4 (rw,relatime,x-systemd.automount)
/dev/sdb1 on /mnt/blue type ext4 (rw,relatime,stripe=8191,x-systemd.automount)
le-barde@ma-machine:~$

Mais si je relance mount un peu plus tard, voici ce que j’obtiens :

systemd-1 on /mnt/home-black type autofs (rw,relatime,fd=35,pgrp=1,timeout=2,minproto=5,maxproto=5,direct,pipe_ino=15392)
systemd-1 on /mnt/blue type autofs (rw,relatime,fd=41,pgrp=1,timeout=2,minproto=5,maxproto=5,direct,pipe_ino=15399)
/dev/sdc8 on /mnt/home-black type ext4 (rw,relatime,x-systemd.automount)

Donc ça marche pour le disque WD_Blue, mais pas pour le WD_Black. Il y a manifestement quelque chose qui va régulièrement dire bonjour à mon système de fichiers. Comment le trouver ? lsof +D /mnt/home-black ne me donne rien.

Un indice : j’ai plein de liens symboliques dans mon $HOME qui pointent dessus (comme le répertoire Vidéos par exemple), ça pourrait peut-être venir de là. Mais dans mon système XFCE pour le moment, aucune console ne pointe dessus (par acquit de conscience j’ai même fait cd Documents).

EDIT : j’ai corrigé quelques retours de bash.

#8

Si c’est un accès fugitif de temps en temps pour lire le contenu, voir si quelque chose a changé… je crains que ce soit très aléatoire à traquer avec lsof ou fuser. L’API inotify (inotifywait, inotifywatch) permet de surveiller les accès à un fichier ou un répertoire mais pas d’identifier le processus qui en est à l’origine. Peut-être en combinant les deux, en espérant que l’accès dure suffisamment longtemps pour être visible par lsof ou fuser après avoir été détecté.

#9

Le coupable était Tracker-miner. Mais comme il m’est utile, il faut que je le configure…

#10

Suite et fin du feuilleton, j’ai fait ceci :

gsettings list-recursively | grep Tracker

Des répertoires suivant des liens symboliques étaient listés dans la variable des répertoires à indexer. Je les ai donc supprimés en faisant ceci :

gsettings set org.freedesktop.Tracker.Miner.Files index-recursive-directories "['/home/lebarde/UnRépertoire, '&DOCUMENTS', '&DOWNLOAD']"

Et maintenant, les deux commandes ls /mnt/blue/ /mnt/home-black/ && mount et mount me rendent les bons résultats.

#11

Bon, le problème du timeout reste entier. En mettant 15ms de timeout ça réduit pas mal l’attente, mais dans Thunar c’est pire. Je pense qu’il teste chaque répertoire.

Extrait de /etc/fstab :
UUID=ed5ac6e5-9fc3-4d28-b0b5-0c4833249c71 /mnt/home-black ext4	noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=2s,x-systemd.device-timeout=15ms

:~$ time ls
real	0m1,775s
user	0m0,005s
sys	0m0,000s

Si je fais un sudo umount /mnt/home-black je n’ai plus la latence.

mount
[...]
systemd-1 on /mnt/home-black type autofs (rw,relatime,fd=108,pgrp=1,timeout=2,minproto=5,maxproto=5,direct,pipe_ino=565313)

C’est lui le fautif.