On lun. 12 mai 2014 à 14:22:14, David Guyot wrote: > Bonjour, la liste. > > Je viens de remarquer ce qui me semble être un bug dans la gestion des > partitions de /etc/fstab dans le cas de partitions imbriquées et aurait > aimé savoir que faire de cette information. > > Je m'explique : j'ai récemment configuré un serveur dédié sous Wheezy, > lequel contient, entre autres, deux partitions montées sous /var/www et > /var/www/cache ; pour des raisons de limitations techniques de mon > hébergeur, la grande firme roubaisienne, j'ai dû configurer d'abord la > partition montée sous /var/www/cache, large d'environ 124 Gio, puis la > partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www > était située après /var/www/cache dans /etc/fstab. > > À ce stade, les plus aguerris d'entre vous devraient entrevoir mon > problème : cela a donné lieu à un fonctionnement très erratique de la > partition /var/www/cache, comme les commandes ci-dessous, exécutées > juste après un redémarrage du serveur, attestent : > david@Curunir:~$ df -h > Sys. fich. Taille Util. Dispo Uti% Monté sur > rootfs 54G 3,1G 49G 6% / > udev 10M 0 10M 0% /dev > tmpfs 13G 328K 13G 1% /run > /dev/md1 54G 3,1G 49G 6% / > tmpfs 5,0M 0 5,0M 0% /run/lock > tmpfs 35G 0 35G 0% /dev/shm > /dev/md3 20G 233M 19G 2% /var/log > /dev/md4 1,7T 852M 1,6T 1% /var/www/cache > /dev/md6 99G 188M 94G 1% /home > /dev/md7 1,7T 852M 1,6T 1% /var/www > tmpfs 32G 0 32G 0% /tmp > david@Curunir:~$ sudo su > [sudo] password for david: > root@Curunir:/home/david# umount /dev/md4 > umount: /var/www/cache: not mounted > root@Curunir:/home/david# mount /dev/md4 > root@Curunir:/home/david# df -h > Sys. fich. Taille Util. Dispo Uti% Monté sur > rootfs 54G 3,1G 49G 6% / > udev 10M 0 10M 0% /dev > tmpfs 13G 328K 13G 1% /run > /dev/md1 54G 3,1G 49G 6% / > tmpfs 5,0M 0 5,0M 0% /run/lock > tmpfs 35G 0 35G 0% /dev/shm > /dev/md3 20G 233M 19G 2% /var/log > /dev/md4 124G 188M 118G 1% /var/www/cache > /dev/md6 99G 188M 94G 1% /home > /dev/md7 1,7T 852M 1,6T 1% /var/www > tmpfs 32G 4,0K 32G 1% /tmp > /dev/md4 124G 188M 118G 1% /var/www/cache > root@Curunir:/home/david# uname -a > Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux > root@Curunir:/home/david# aptitude show linux-image-3.2.0-4-amd64 > Paquet : linux-image-3.2.0-4-amd64 > Nouveau: oui > État: installé > Automatiquement installé: oui > Version : 3.2.57-3 > Priorité : optionnel > Section : kernel > Responsable : Debian Kernel Team <debian-kernel@lists.debian.org> > Architecture : amd64 > Taille décompressée : 106 M > Dépend: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools > (>= 0.99~) | linux-initramfs-tool > Pré-dépend: debconf | debconf-2.0 > Recommande: firmware-linux-free (>= 3~) > Suggère: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux | > lilo > Casse: at (< 3.1.12-1+squeeze1), initramfs-tools (< 0.99~) > Fournit: linux-image, linux-modules-3.2.0-4-amd64 > Description : Linux 3.2 for 64-bit PCs > The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or > VIA Nano processors. > > This kernel also runs on a Xen hypervisor. It supports both > privileged (dom0) and unprivileged (domU) operation. > > > Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque > journal que ce soit ; après de nombreux essais, je me suis souvenu de > l'ordre de ces partitions dans /etc/fstab et les ai inversées pour > placer /var/www avant /var/www/cache, et la partition /var/www/cache a, > de ce fait, retrouvé un comportement normal. > > Je sais que l'ordre dans /etc/fstab des systèmes de fichiers à monter > est important, mais je n'aurais jamais pensé que des problèmes liés > pourraient se montrer de la sorte, sans aucun avertissement ni gestion > correcte par le noyau. À mon sens, le noyau devrait gérer ce genre de > cas de façon transparente, par exemple en chargeant /etc/fstab d'un bloc > et en en vérifiant le contenu pour remettre dans l'ordre le montage des > partitions afin d'éviter les problèmes ; sinon, il devrait au moins être > capable d'avertir de ce genre de situation par un message dans les > journaux afin d'éviter de perdre des heures d'analyse de symptômes > sibyllins pour un problème aussi trivial. > > J'en arrive maintenant au moment fatidique : que dois-je faire de ce > problème ? Tout d'abord, est-ce bien un bug ou est-ce une > fonctionnalité ? Si c'est bien un bug, à qui le signaler ? Dois-je le > signaler d'abord à l'équipe Debian qui le remontra aux développeurs du > noyau si nécessaire, ou dois-je le signaler directement aux développeurs > du noyau puisque cela concerne la fonction bas niveau de gestion du > montage des disques ? > > Si vous êtes arrivés jusqu'à cette phrase, merci de m'avoir lu et merci > d'avance pour votre éclairage. > > Cordialement. Bonjour, D'expérience, mount a deux modes de fonctionnements, le mode séquentiel (appelé par mount -a), où l'ordre suivi est de haut en bas dans fstab, et l'ordre forké (mount -F) où une instance de mount est lancée par partoche, et où c'est plus ou moins la fête du slip. De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions imbriquées, et fait un mount -a au boot (en tout cas dans l'init script que j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le caractère « basique » du problème, j'aurais tendance à dire que c'est un comportement qui, s'il n'est pas voulu, ne gêne pas grand monde. Une solution « infaillible » (que je n'emploie pas, par flemme), c'est de mettre une option noauto sur les partitions problématiques, et de les monter via un rc.local qui sera, lui, bien ordonné. Quant au signalement, je pense que le mieux est d'abord d'obtenir des retours d'autres utilisateurs, donc en parler ici me semble bien. Bonne suite, -- PEB
Attachment:
signature.asc
Description: Digital signature