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 :
:~$ 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
:~$ sudo su
[sudo] password for david:
:/home/david# umount /dev/md4
umount: /var/www/cache: not mounted
:/home/david# mount /dev/md4
:/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
:/home/david# uname -a
Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux
:/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
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-j e 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éveloppe urs
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 m erci
d'avance pour votre éclairage.
Cordialement.
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-j e 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éveloppe urs
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 m erci
d'avance pour votre éclairage.
Cordialement.
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 :
:~$ 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
:~$ sudo su
[sudo] password for david:
:/home/david# umount /dev/md4
umount: /var/www/cache: not mounted
:/home/david# mount /dev/md4
:/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
:/home/david# uname -a
Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux
:/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
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-j e 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éveloppe urs
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 m erci
d'avance pour votre éclairage.
Cordialement.
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.
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,
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.
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,
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.
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,
Le 12/05/2014 16:37, David Guyot a écrit :
> Bonjour.
>
> Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les
> problèmes liés à un mauvais ordre de montage ne sont pas claireme nt
> indiqués ; un élément aussi important du système ne devrait-il pas être
> doté d'avertissements dans les pages man ou dans les journaux systè me
> lorsqu'un problème se produit ? J'ai du mal à trouver normal que le
> noyau accepte sans broncher de mettre les partitions dans un état
> incohérent ; habituellement, sous GNU/Linux, quand de telles
> possibilités sont laissées à root, elles sont entourées d'un lu xe de
> messages d'avertissement du genre « Attention, vous allez probablement
> endommager votre système si vous continuez ! », mais, ici, rien, le
> noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le
> bazar derrière.
>
> Aurais-je manqué quelque chose ?
>
> Merci d'avance.
>
> Cordialement.
>
Bonsoir,
On peut imaginer des situations où ce que tu trouves être un problè me
peut être une fonctionnalité intéressante et où le comportement e st
alors tout à fait souhaitable:
tu as un environnement de production (avec montage de /var/www puis
/var/www/cache) et pour des raisons d'exploitation tu désires mettre en
place temporairement un autre environnement (la nuit, le week-end ... ou
environnement dégradé suite à incident ... ou ...) et alors tu éc rases
temporairement ton environnement en montant un autre système de fichiers
/var/www (sans le besoin du cache).
Quand tu veux reveveuwnir dans l'environnement initial tu as juste à
démonter /var/www et tu retrouves ton environnement initial.
D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas
(c'est bien le principe même du montage d'un système de fichiers: ren dre
visible le nouveau système de fichiers et cacher l'ancienne arborescenc e).
On pourrait effectivement imaginer des warnings pour attirer l'attention
de cette situation qui dans d'autres circonstances porte à confusion,
Cordialement
Jacques
PS: si tu le juges utile tu peux poster ma réponse sur la liste
Le 12/05/2014 16:37, David Guyot a écrit :
> Bonjour.
>
> Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les
> problèmes liés à un mauvais ordre de montage ne sont pas claireme nt
> indiqués ; un élément aussi important du système ne devrait-il pas être
> doté d'avertissements dans les pages man ou dans les journaux systè me
> lorsqu'un problème se produit ? J'ai du mal à trouver normal que le
> noyau accepte sans broncher de mettre les partitions dans un état
> incohérent ; habituellement, sous GNU/Linux, quand de telles
> possibilités sont laissées à root, elles sont entourées d'un lu xe de
> messages d'avertissement du genre « Attention, vous allez probablement
> endommager votre système si vous continuez ! », mais, ici, rien, le
> noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le
> bazar derrière.
>
> Aurais-je manqué quelque chose ?
>
> Merci d'avance.
>
> Cordialement.
>
Bonsoir,
On peut imaginer des situations où ce que tu trouves être un problè me
peut être une fonctionnalité intéressante et où le comportement e st
alors tout à fait souhaitable:
tu as un environnement de production (avec montage de /var/www puis
/var/www/cache) et pour des raisons d'exploitation tu désires mettre en
place temporairement un autre environnement (la nuit, le week-end ... ou
environnement dégradé suite à incident ... ou ...) et alors tu éc rases
temporairement ton environnement en montant un autre système de fichiers
/var/www (sans le besoin du cache).
Quand tu veux reveveuwnir dans l'environnement initial tu as juste à
démonter /var/www et tu retrouves ton environnement initial.
D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas
(c'est bien le principe même du montage d'un système de fichiers: ren dre
visible le nouveau système de fichiers et cacher l'ancienne arborescenc e).
On pourrait effectivement imaginer des warnings pour attirer l'attention
de cette situation qui dans d'autres circonstances porte à confusion,
Cordialement
Jacques
PS: si tu le juges utile tu peux poster ma réponse sur la liste
Le 12/05/2014 16:37, David Guyot a écrit :
> Bonjour.
>
> Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les
> problèmes liés à un mauvais ordre de montage ne sont pas claireme nt
> indiqués ; un élément aussi important du système ne devrait-il pas être
> doté d'avertissements dans les pages man ou dans les journaux systè me
> lorsqu'un problème se produit ? J'ai du mal à trouver normal que le
> noyau accepte sans broncher de mettre les partitions dans un état
> incohérent ; habituellement, sous GNU/Linux, quand de telles
> possibilités sont laissées à root, elles sont entourées d'un lu xe de
> messages d'avertissement du genre « Attention, vous allez probablement
> endommager votre système si vous continuez ! », mais, ici, rien, le
> noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le
> bazar derrière.
>
> Aurais-je manqué quelque chose ?
>
> Merci d'avance.
>
> Cordialement.
>
Bonsoir,
On peut imaginer des situations où ce que tu trouves être un problè me
peut être une fonctionnalité intéressante et où le comportement e st
alors tout à fait souhaitable:
tu as un environnement de production (avec montage de /var/www puis
/var/www/cache) et pour des raisons d'exploitation tu désires mettre en
place temporairement un autre environnement (la nuit, le week-end ... ou
environnement dégradé suite à incident ... ou ...) et alors tu éc rases
temporairement ton environnement en montant un autre système de fichiers
/var/www (sans le besoin du cache).
Quand tu veux reveveuwnir dans l'environnement initial tu as juste à
démonter /var/www et tu retrouves ton environnement initial.
D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas
(c'est bien le principe même du montage d'un système de fichiers: ren dre
visible le nouveau système de fichiers et cacher l'ancienne arborescenc e).
On pourrait effectivement imaginer des warnings pour attirer l'attention
de cette situation qui dans d'autres circonstances porte à confusion,
Cordialement
Jacques
PS: si tu le juges utile tu peux poster ma réponse sur la liste
[…]
Bonjour.
[…] je continue de croire que le noyau devrait […]
[â¦]
Bonjour.
[â¦] je continue de croire que le noyau devrait [â¦]
[…]
Bonjour.
[…] je continue de croire que le noyau devrait […]
Effectivement, ta réponse est pertinente, mais je continue de croire que
le noyau devrait au moins avertir des conséquences d'un tel ordre de
montage des partitions. Je vais demander l'ajout de cet avertissement ;
dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du
noyau ?
Effectivement, ta réponse est pertinente, mais je continue de croire que
le noyau devrait au moins avertir des conséquences d'un tel ordre de
montage des partitions. Je vais demander l'ajout de cet avertissement ;
dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du
noyau ?
Effectivement, ta réponse est pertinente, mais je continue de croire que
le noyau devrait au moins avertir des conséquences d'un tel ordre de
montage des partitions. Je vais demander l'ajout de cet avertissement ;
dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du
noyau ?
Sauf que, comme dit plusieurs fois dans le fil, ça n’est p as
du ressort du noyau.
Au niveau supérieur, c’est la commande mount. Donc ce sera it Ã
la commande mount (man 8 mount) de faire attention ou d’envoyer
un message d’alerte lors d’un masquage.
Donc si tu veux faire un rapport de bogue (plutôt du niveau
wishlist à mon avis), ce serait sur mount (paquet mount) qu’ il
faudrait le faire.
Sauf que, comme dit plusieurs fois dans le fil, ça nâest p as
du ressort du noyau.
Au niveau supérieur, câest la commande mount. Donc ce sera it Ã
la commande mount (man 8 mount) de faire attention ou dâenvoyer
un message dâalerte lors dâun masquage.
Donc si tu veux faire un rapport de bogue (plutôt du niveau
wishlist à mon avis), ce serait sur mount (paquet mount) quâ il
faudrait le faire.
Sauf que, comme dit plusieurs fois dans le fil, ça n’est p as
du ressort du noyau.
Au niveau supérieur, c’est la commande mount. Donc ce sera it Ã
la commande mount (man 8 mount) de faire attention ou d’envoyer
un message d’alerte lors d’un masquage.
Donc si tu veux faire un rapport de bogue (plutôt du niveau
wishlist à mon avis), ce serait sur mount (paquet mount) qu’ il
faudrait le faire.
Effectivement, ta réponse est pertinente, mais je continue de
croire que le noyau devrait au moins avertir des conséquences d'un
tel ordre de montage des partitions. Je vais demander l'ajout de
Effectivement, ta réponse est pertinente, mais je continue de
croire que le noyau devrait au moins avertir des conséquences d'un
tel ordre de montage des partitions. Je vais demander l'ajout de
Effectivement, ta réponse est pertinente, mais je continue de
croire que le noyau devrait au moins avertir des conséquences d'un
tel ordre de montage des partitions. Je vais demander l'ajout de
On Tue, 13 May 2014 10:19:38 +0200
David Guyot wrote:
> Effectivement, ta réponse est pertinente, mais je continue de
> croire que le noyau devrait au moins avertir des conséquences d'un
> tel ordre de montage des partitions. Je vais demander l'ajout de
Il suffit d'avoir ne serais-ce qu'un quart de neurone
fonctionnel: on décolle rarement avec un planeur dont
on a pas encore monté les ailes…
--
Aria: On va à disneyland ensemble ? ya un ticket gratuit pour un ach eté !
Manon: Parfait je prend le gratuit !
On Tue, 13 May 2014 10:19:38 +0200
David Guyot <david.guyot@europecamions-interactive.com> wrote:
> Effectivement, ta réponse est pertinente, mais je continue de
> croire que le noyau devrait au moins avertir des conséquences d'un
> tel ordre de montage des partitions. Je vais demander l'ajout de
Il suffit d'avoir ne serais-ce qu'un quart de neurone
fonctionnel: on décolle rarement avec un planeur dont
on a pas encore monté les ailesâ¦
--
Aria: On va à disneyland ensemble ? ya un ticket gratuit pour un ach eté !
Manon: Parfait je prend le gratuit !
On Tue, 13 May 2014 10:19:38 +0200
David Guyot wrote:
> Effectivement, ta réponse est pertinente, mais je continue de
> croire que le noyau devrait au moins avertir des conséquences d'un
> tel ordre de montage des partitions. Je vais demander l'ajout de
Il suffit d'avoir ne serais-ce qu'un quart de neurone
fonctionnel: on décolle rarement avec un planeur dont
on a pas encore monté les ailes…
--
Aria: On va à disneyland ensemble ? ya un ticket gratuit pour un ach eté !
Manon: Parfait je prend le gratuit !
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est s i
simple, on pourrait s'attendre à ce que le système avertisse de ce
problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des
avertissements pour moins que ça, et, mount étant une commande esse ntielle,
elle pourrait se permettre d'être plus bavarde que de simplement fair e ce
qu'on lui dit sans avertir de problèmes potentiels.
Cordialement.
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est s i
simple, on pourrait s'attendre à ce que le système avertisse de ce
problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des
avertissements pour moins que ça, et, mount étant une commande esse ntielle,
elle pourrait se permettre d'être plus bavarde que de simplement fair e ce
qu'on lui dit sans avertir de problèmes potentiels.
Cordialement.
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est s i
simple, on pourrait s'attendre à ce que le système avertisse de ce
problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des
avertissements pour moins que ça, et, mount étant une commande esse ntielle,
elle pourrait se permettre d'être plus bavarde que de simplement fair e ce
qu'on lui dit sans avertir de problèmes potentiels.
Cordialement.
Le 13/05/2014 16:46, David Guyot a écrit :Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
Le 13/05/2014 16:46, David Guyot a écrit :
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
Le 13/05/2014 16:46, David Guyot a écrit :Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
