Checker si un montage est vraiment bien opérationnel
27 réponses
Francois Lafont
Bonjour à tous,
Connaissez-vous le moyen le plus fiable possible pour tester si
un montage est bien monté (si j'ose dire) et parfaitement
opérationnel.
Au départ, je pensais par exemple tester la présence d'un fichier
à la racine de chaque répertoire faisant office de point de montage.
Mais le souci c'est que je veux mettre en place un tel check dans
le cadre d'une supervision sur un certain nombre de machines (environ
60) et cela suppose qu'il faut se mettre d'accord sur un fichier à
tester sur chaque montage ce qui n'est pas forcément simple car celui
dépendra du montage en question. Du coup c'est un peu pénible à mettre
en place « en masse » car pas super générique.
Autre idée : j'ai pensé à la commande mountpoint qui nous dit si un
répertoire est un point de montage ou non. Mais le souci c'est que ce
n'est pas une vérification assez « forte » pour moi. En effet, je crois
bien que par exemple sur un partage NFS monté on peut parfaitement
avoir la commande mountpoint qui nous dit que tel répertoire est bien
un point de montage mais si le serveur NFS est en vrac et que le partage
est inaccessible la commande mountpoint ne le verra pas (elle se contentera
de nous dire que le répertoire est bien un point de montage sans se
soucier de savoir si ce qu'il y a dedans est accessible ou non).
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si
possible de manière un peu générique. Est-ce possible d'après ? Le test
de la présence d'un fichier à la racine du montage est-il le seul
moyen 100% fiable ?
Connaissez-vous le moyen le plus fiable possible pour tester si un montage est bien monté (si j'ose dire) et parfaitement opérationnel.
Au départ, je pensais par exemple tester la présence d'un fichier à la racine de chaque répertoire faisant office de point de montage. Mais le souci c'est que je veux mettre en place un tel check dans le cadre d'une supervision sur un certain nombre de machines (environ 60) et cela suppose qu'il faut se mettre d'accord sur un fichier à tester sur chaque montage ce qui n'est pas forcément simple car celui dépendra du montage en question. Du coup c'est un peu pénible à mettre en place « en masse » car pas super générique.
Autre idée : j'ai pensé à la commande mountpoint qui nous dit si un répertoire est un point de montage ou non. Mais le souci c'est que ce n'est pas une vérification assez « forte » pour moi. En effet, je crois bien que par exemple sur un partage NFS monté on peut parfaitement avoir la commande mountpoint qui nous dit que tel répertoire est bien un point de montage mais si le serveur NFS est en vrac et que le partage est inaccessible la commande mountpoint ne le verra pas (elle se contentera de nous dire que le répertoire est bien un point de montage sans se soucier de savoir si ce qu'il y a dedans est accessible ou non).
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si possible de manière un peu générique. Est-ce possible d'après ? Le test de la présence d'un fichier à la racine du montage est-il le seul moyen 100% fiable ?
Merci d'avance pour vos conseils.
Je ne suis pas un grand spécialiste mais voilà comment je fais pour checker si mon disque de sauvegarde externe est bien monté http://pastebin.fr/28661
Le 06/09/2013 01:57, Francois Lafont a écrit :
Bonjour à tous,
Connaissez-vous le moyen le plus fiable possible pour tester si
un montage est bien monté (si j'ose dire) et parfaitement
opérationnel.
Au départ, je pensais par exemple tester la présence d'un fichier
à la racine de chaque répertoire faisant office de point de montage.
Mais le souci c'est que je veux mettre en place un tel check dans
le cadre d'une supervision sur un certain nombre de machines (environ
60) et cela suppose qu'il faut se mettre d'accord sur un fichier à
tester sur chaque montage ce qui n'est pas forcément simple car celui
dépendra du montage en question. Du coup c'est un peu pénible à mettre
en place « en masse » car pas super générique.
Autre idée : j'ai pensé à la commande mountpoint qui nous dit si un
répertoire est un point de montage ou non. Mais le souci c'est que ce
n'est pas une vérification assez « forte » pour moi. En effet, je crois
bien que par exemple sur un partage NFS monté on peut parfaitement
avoir la commande mountpoint qui nous dit que tel répertoire est bien
un point de montage mais si le serveur NFS est en vrac et que le partage
est inaccessible la commande mountpoint ne le verra pas (elle se contentera
de nous dire que le répertoire est bien un point de montage sans se
soucier de savoir si ce qu'il y a dedans est accessible ou non).
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si
possible de manière un peu générique. Est-ce possible d'après ? Le test
de la présence d'un fichier à la racine du montage est-il le seul
moyen 100% fiable ?
Merci d'avance pour vos conseils.
Je ne suis pas un grand spécialiste mais voilà comment je fais pour
checker si mon disque de sauvegarde externe est bien monté
http://pastebin.fr/28661
Connaissez-vous le moyen le plus fiable possible pour tester si un montage est bien monté (si j'ose dire) et parfaitement opérationnel.
Au départ, je pensais par exemple tester la présence d'un fichier à la racine de chaque répertoire faisant office de point de montage. Mais le souci c'est que je veux mettre en place un tel check dans le cadre d'une supervision sur un certain nombre de machines (environ 60) et cela suppose qu'il faut se mettre d'accord sur un fichier à tester sur chaque montage ce qui n'est pas forcément simple car celui dépendra du montage en question. Du coup c'est un peu pénible à mettre en place « en masse » car pas super générique.
Autre idée : j'ai pensé à la commande mountpoint qui nous dit si un répertoire est un point de montage ou non. Mais le souci c'est que ce n'est pas une vérification assez « forte » pour moi. En effet, je crois bien que par exemple sur un partage NFS monté on peut parfaitement avoir la commande mountpoint qui nous dit que tel répertoire est bien un point de montage mais si le serveur NFS est en vrac et que le partage est inaccessible la commande mountpoint ne le verra pas (elle se contentera de nous dire que le répertoire est bien un point de montage sans se soucier de savoir si ce qu'il y a dedans est accessible ou non).
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si possible de manière un peu générique. Est-ce possible d'après ? Le test de la présence d'un fichier à la racine du montage est-il le seul moyen 100% fiable ?
Merci d'avance pour vos conseils.
Je ne suis pas un grand spécialiste mais voilà comment je fais pour checker si mon disque de sauvegarde externe est bien monté http://pastebin.fr/28661
Doug713705
Le 05-09-2013, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si possible de manière un peu générique. Est-ce possible d'après ? Le test de la présence d'un fichier à la racine du montage est-il le seul moyen 100% fiable ?
grep "/point/de/montage" /proc/mounts
Par contre je ne sais pas de quelle manière se comporte /proc/mounts en cas de défaillance réseau sur un point de montage NFS/Samba.
Il me semble qu'il n'y a pas de solution miracle à ce problème (j'en étais resté là la dernière fois que j'ai essayé de faire la même chose aux alentours de 2002/2003, ça date).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 05-09-2013, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si
possible de manière un peu générique. Est-ce possible d'après ? Le test
de la présence d'un fichier à la racine du montage est-il le seul
moyen 100% fiable ?
grep "/point/de/montage" /proc/mounts
Par contre je ne sais pas de quelle manière se comporte /proc/mounts en
cas de défaillance réseau sur un point de montage NFS/Samba.
Il me semble qu'il n'y a pas de solution miracle à ce problème (j'en
étais resté là la dernière fois que j'ai essayé de faire la même chose
aux alentours de 2002/2003, ça date).
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 05-09-2013, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si possible de manière un peu générique. Est-ce possible d'après ? Le test de la présence d'un fichier à la racine du montage est-il le seul moyen 100% fiable ?
grep "/point/de/montage" /proc/mounts
Par contre je ne sais pas de quelle manière se comporte /proc/mounts en cas de défaillance réseau sur un point de montage NFS/Samba.
Il me semble qu'il n'y a pas de solution miracle à ce problème (j'en étais resté là la dernière fois que j'ai essayé de faire la même chose aux alentours de 2002/2003, ça date).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Lucas Levrel
Le 6 septembre 2013, Francois Lafont a écrit :
Au départ, je pensais par exemple tester la présence d'un fichier à la racine de chaque répertoire faisant office de point de montage. Mais le souci c'est que je veux mettre en place un tel check dans le cadre d'une supervision sur un certain nombre de machines (environ 60) et cela suppose qu'il faut se mettre d'accord sur un fichier à tester sur chaque montage ce qui n'est pas forcément simple car celui dépendra du montage en question. Du coup c'est un peu pénible à mettre en place « en masse » car pas super générique.
Tester si $(ls -A /mount/point) est non-vide ? Mais il faut être sûr que /mount/point est vide en local ! (Et il faut un timeout dans le montage NFS pour ne pas que ça bloque indéfiniment.)
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
Le 6 septembre 2013, Francois Lafont a écrit :
Au départ, je pensais par exemple tester la présence d'un fichier
à la racine de chaque répertoire faisant office de point de montage.
Mais le souci c'est que je veux mettre en place un tel check dans
le cadre d'une supervision sur un certain nombre de machines (environ
60) et cela suppose qu'il faut se mettre d'accord sur un fichier à
tester sur chaque montage ce qui n'est pas forcément simple car celui
dépendra du montage en question. Du coup c'est un peu pénible à mettre
en place « en masse » car pas super générique.
Tester si $(ls -A /mount/point) est non-vide ? Mais il faut être sûr que
/mount/point est vide en local ! (Et il faut un timeout dans le montage
NFS pour ne pas que ça bloque indéfiniment.)
Au départ, je pensais par exemple tester la présence d'un fichier à la racine de chaque répertoire faisant office de point de montage. Mais le souci c'est que je veux mettre en place un tel check dans le cadre d'une supervision sur un certain nombre de machines (environ 60) et cela suppose qu'il faut se mettre d'accord sur un fichier à tester sur chaque montage ce qui n'est pas forcément simple car celui dépendra du montage en question. Du coup c'est un peu pénible à mettre en place « en masse » car pas super générique.
Tester si $(ls -A /mount/point) est non-vide ? Mais il faut être sûr que /mount/point est vide en local ! (Et il faut un timeout dans le montage NFS pour ne pas que ça bloque indéfiniment.)
-- LL Eν οιδα οτι ουδεν οιδα (Σωκρατης)
franssoa
Le 06. 09. 13 01:57, Francois Lafont a écrit :
Au départ, je pensais par exemple tester la présence d'un fichier à la racine de chaque répertoire faisant office de point de montage. Mais le souci c'est que je veux mettre en place un tel check dans le cadre d'une supervision sur un certain nombre de machines (environ 60) et cela suppose qu'il faut se mettre d'accord sur un fichier à tester sur chaque montage ce qui n'est pas forcément simple car celui dépendra du montage en question.
Et pourquoi pas l'inverse ? Sans chaque dossier de montage local, créer un fichier au nom improbable et tester sa non présence une fois le montage fait ?
franssoa
Le 06. 09. 13 01:57, Francois Lafont a écrit :
Au départ, je pensais par exemple tester la présence d'un fichier
à la racine de chaque répertoire faisant office de point de montage.
Mais le souci c'est que je veux mettre en place un tel check dans
le cadre d'une supervision sur un certain nombre de machines (environ
60) et cela suppose qu'il faut se mettre d'accord sur un fichier à
tester sur chaque montage ce qui n'est pas forcément simple car celui
dépendra du montage en question.
Et pourquoi pas l'inverse ?
Sans chaque dossier de montage local, créer un fichier au nom improbable
et tester sa non présence une fois le montage fait ?
Au départ, je pensais par exemple tester la présence d'un fichier à la racine de chaque répertoire faisant office de point de montage. Mais le souci c'est que je veux mettre en place un tel check dans le cadre d'une supervision sur un certain nombre de machines (environ 60) et cela suppose qu'il faut se mettre d'accord sur un fichier à tester sur chaque montage ce qui n'est pas forcément simple car celui dépendra du montage en question.
Et pourquoi pas l'inverse ? Sans chaque dossier de montage local, créer un fichier au nom improbable et tester sa non présence une fois le montage fait ?
franssoa
Michaël Nourry
Le 06/09/2013 16:45, franssoa a écrit :
Le 06. 09. 13 01:57, Francois Lafont a écrit :
Et pourquoi pas l'inverse ? Sans chaque dossier de montage local, créer un fichier au nom improbable et tester sa non présence une fois le montage fait ?
franssoa
Ben oui mais si le montage se fait mais est défaillant tu ne le sauras pas (en particulier NFS). Je pense qu'un fichier dans le montage est une très bonne solution, un peu galère c'est vrai.
Par contre, pourquoi pas faire 1) mount , pour voir les montage fait 2) faire un ls /repdumount/ pour vérifier qu'il répond pour vérifier que partage n'est pas défaillant
-- Michaël
Le 06/09/2013 16:45, franssoa a écrit :
Le 06. 09. 13 01:57, Francois Lafont a écrit :
Et pourquoi pas l'inverse ?
Sans chaque dossier de montage local, créer un fichier au nom improbable
et tester sa non présence une fois le montage fait ?
franssoa
Ben oui mais si le montage se fait mais est défaillant tu ne le sauras
pas (en particulier NFS).
Je pense qu'un fichier dans le montage est une très bonne solution, un
peu galère c'est vrai.
Par contre, pourquoi pas faire
1) mount , pour voir les montage fait
2) faire un ls /repdumount/ pour vérifier qu'il répond pour vérifier que
partage n'est pas défaillant
Et pourquoi pas l'inverse ? Sans chaque dossier de montage local, créer un fichier au nom improbable et tester sa non présence une fois le montage fait ?
franssoa
Ben oui mais si le montage se fait mais est défaillant tu ne le sauras pas (en particulier NFS). Je pense qu'un fichier dans le montage est une très bonne solution, un peu galère c'est vrai.
Par contre, pourquoi pas faire 1) mount , pour voir les montage fait 2) faire un ls /repdumount/ pour vérifier qu'il répond pour vérifier que partage n'est pas défaillant
-- Michaël
Francois Lafont
Bonsoir,
Merci bien pour vos réponses. Finalement je retiens le coup du ls /rep/montage/ proposé par Lucas et Michaël qui me semble assez générique et en même temps efficace.
En effet, du coup, je pense faire un grep sur le fichier /etc/fstab (qui est censé annoncer ce qui doit être monté sur le serveur) afin de repérer tous les répertoires de montage (il faudra sans doute penser à virer /proc et des trucs dans le genre) et faire sur chacun de ces répertoires de montage un truc dans ce genre là :
----------------------------------------------- # la variable $dir représente un répertoire de montage. RESULT=0
# On teste si le répertoire est bien un point de # montage au yeux du système. if ! mountpoint "$dir" then RESULT=1 fi
# Mais le test précédent ne suffit pas car dans le cas # d'un partage réseau avec un serveur en vrac, la commande # mountpoint ne détectera pas le problème du partage inaccessible, # d'où l'idée d'un ls. if ! timeout --signal=SIGKILL 3 ls -f "$dir" > /dev/null 2>&1 then RESULT=2 fi
Il me semble qu'avec ceci, je ne passerai pas à côté d'un problème, non ? Qu'en pensez vous ?
J'ai mis l'option -f au niveau de la commande ls pour éviter toute sorte de tri dont je n'ai que faire et qui peut ralentir la machine.
Le petit truc qui m'embête, c'est le cas où le répertoire de montage contient beaucoup de fichiers. Je me dis que, peut-être, dans ce cas là la commande ls peut demander un peu de ressource à la machine (voire dépasser le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
-- François Lafont
Bonsoir,
Merci bien pour vos réponses. Finalement je retiens le coup du ls /rep/montage/
proposé par Lucas et Michaël qui me semble assez générique et en même temps
efficace.
En effet, du coup, je pense faire un grep sur le fichier /etc/fstab
(qui est censé annoncer ce qui doit être monté sur le serveur) afin de
repérer tous les répertoires de montage (il faudra sans doute penser à
virer /proc et des trucs dans le genre) et faire sur chacun de ces
répertoires de montage un truc dans ce genre là :
-----------------------------------------------
# la variable $dir représente un répertoire de montage.
RESULT=0
# On teste si le répertoire est bien un point de
# montage au yeux du système.
if ! mountpoint "$dir"
then
RESULT=1
fi
# Mais le test précédent ne suffit pas car dans le cas
# d'un partage réseau avec un serveur en vrac, la commande
# mountpoint ne détectera pas le problème du partage inaccessible,
# d'où l'idée d'un ls.
if ! timeout --signal=SIGKILL 3 ls -f "$dir" > /dev/null 2>&1
then
RESULT=2
fi
Il me semble qu'avec ceci, je ne passerai pas à côté d'un problème, non ?
Qu'en pensez vous ?
J'ai mis l'option -f au niveau de la commande ls pour éviter toute
sorte de tri dont je n'ai que faire et qui peut ralentir la machine.
Le petit truc qui m'embête, c'est le cas où le répertoire de montage
contient beaucoup de fichiers. Je me dis que, peut-être, dans ce cas là la
commande ls peut demander un peu de ressource à la machine (voire dépasser
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui
ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça
ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un
répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Merci bien pour vos réponses. Finalement je retiens le coup du ls /rep/montage/ proposé par Lucas et Michaël qui me semble assez générique et en même temps efficace.
En effet, du coup, je pense faire un grep sur le fichier /etc/fstab (qui est censé annoncer ce qui doit être monté sur le serveur) afin de repérer tous les répertoires de montage (il faudra sans doute penser à virer /proc et des trucs dans le genre) et faire sur chacun de ces répertoires de montage un truc dans ce genre là :
----------------------------------------------- # la variable $dir représente un répertoire de montage. RESULT=0
# On teste si le répertoire est bien un point de # montage au yeux du système. if ! mountpoint "$dir" then RESULT=1 fi
# Mais le test précédent ne suffit pas car dans le cas # d'un partage réseau avec un serveur en vrac, la commande # mountpoint ne détectera pas le problème du partage inaccessible, # d'où l'idée d'un ls. if ! timeout --signal=SIGKILL 3 ls -f "$dir" > /dev/null 2>&1 then RESULT=2 fi
Il me semble qu'avec ceci, je ne passerai pas à côté d'un problème, non ? Qu'en pensez vous ?
J'ai mis l'option -f au niveau de la commande ls pour éviter toute sorte de tri dont je n'ai que faire et qui peut ralentir la machine.
Le petit truc qui m'embête, c'est le cas où le répertoire de montage contient beaucoup de fichiers. Je me dis que, peut-être, dans ce cas là la commande ls peut demander un peu de ressource à la machine (voire dépasser le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
-- François Lafont
Michaël Nourry
Le 07/09/2013 01:28, Francois Lafont a écrit :
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
-- Michaël
Le 07/09/2013 01:28, Francois Lafont a écrit :
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui
ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça
ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un
répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Erf, oui tu as raison d'avoir peur :)
Et si au lieu de faire un ls, on fait par exemple un
echo date > fichier.temoin
(si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
-- Michaël
Doug713705
Le 07-09-2013, Michaël Nourry nous expliquait dans fr.comp.os.linux.configuration :
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Si le montage NFS est démonté, le fichier sera malgré tout écrit sous le point de montage.
Le test sera donc positif dans tous les cas.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 07-09-2013, Michaël Nourry nous expliquait dans
fr.comp.os.linux.configuration :
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui
ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça
ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un
répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Erf, oui tu as raison d'avoir peur :)
Et si au lieu de faire un ls, on fait par exemple un
echo date > fichier.temoin
(si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Si le montage NFS est démonté, le fichier sera malgré tout écrit sous le
point de montage.
Le test sera donc positif dans tous les cas.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 07-09-2013, Michaël Nourry nous expliquait dans fr.comp.os.linux.configuration :
le timeout même). En fait, j'aurais bien aimé trouver une option de ls qui ne m'affiche que les 10 premières entrées du répertoire par exemple mais ça ne semble pas exister. Imaginons un "ls -f" toutes les 10 mn sur un répertoire qui contient 50 000 fichiers, c'est par très bon pour le serveur.
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Si le montage NFS est démonté, le fichier sera malgré tout écrit sous le point de montage.
Le test sera donc positif dans tous les cas.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Michaël Nourry
Le 08/09/2013 00:30, Doug713705 a écrit :
Si le montage NFS est démonté, le fichier sera malgré tout écrit sous le point de montage.
Le test sera donc positif dans tous les cas.
Oui mais avant on vérifie que c'est bien un point de montage avec mountpoint ou mount -- Michaël Nourry CRDP Versailles
Le 08/09/2013 00:30, Doug713705 a écrit :
Si le montage NFS est démonté, le fichier sera malgré tout écrit sous le
point de montage.
Le test sera donc positif dans tous les cas.
Oui mais avant on vérifie que c'est bien un point de montage avec
mountpoint ou mount
--
Michaël Nourry
CRDP Versailles
Si le montage NFS est démonté, le fichier sera malgré tout écrit sous le point de montage.
Le test sera donc positif dans tous les cas.
Oui mais avant on vérifie que c'est bien un point de montage avec mountpoint ou mount -- Michaël Nourry CRDP Versailles
Francois Lafont
Salut Michaël, :-)
Le 07/09/2013 23:59, Michaël Nourry a écrit :
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Le souci c'est que ça me gêne un peu que le check modifie le système de fichiers (via une écriture), j'aimerais vraiment éviter d'y toucher.
Du coup, par rapport au "ls -f", je me suis dis que je pouvais le piper avec head afin d'écourter le travail de la commande ls. J'ai l'impression que ça marche. Sur des VMs, j'ai créé un partage nfs avec 100 000 fichiers dedans et j'ai tenté ceci :
---- ~# mount -t nfs 192.168.109:/test /test/ && time timeout --signal=SIGKILL 3 ls -f /test | head > /dev/null; echo $?
real 0m0.714s user 0m0.016s sys 0m0.004s 0 ----
Dans les mêmes conditions avec redémarrage du client et du serveur mais sans le « | head », j'ai :
real 0m2.564s user 0m0.016s sys 0m0.324s
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité (auquel cas ça me va car je sais alors que la commande ls ne pompera pas trop de ressources réseaux quel que soit le répertoire en face) ou bien ls continue-t-il son travail dans le vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se situe pas au niveau réseau puisque le ls va à son terme) ?
-- François Lafont
Salut Michaël, :-)
Le 07/09/2013 23:59, Michaël Nourry a écrit :
Erf, oui tu as raison d'avoir peur :)
Et si au lieu de faire un ls, on fait par exemple un
echo date > fichier.temoin
(si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Le souci c'est que ça me gêne un peu que le check modifie le
système de fichiers (via une écriture), j'aimerais vraiment
éviter d'y toucher.
Du coup, par rapport au "ls -f", je me suis dis que je pouvais
le piper avec head afin d'écourter le travail de la commande ls.
J'ai l'impression que ça marche. Sur des VMs, j'ai créé un partage
nfs avec 100 000 fichiers dedans et j'ai tenté ceci :
----
~# mount -t nfs 192.168.109:/test /test/ &&
time timeout --signal=SIGKILL 3 ls -f /test | head > /dev/null; echo $?
real 0m0.714s
user 0m0.016s
sys 0m0.004s
0
----
Dans les mêmes conditions avec redémarrage du client et du
serveur mais sans le « | head », j'ai :
real 0m2.564s
user 0m0.016s
sys 0m0.324s
En fait, la question que je me pose, c'est est-ce que le « | head »
interrompt vraiment le travail de la commande ls une fois qu'il a son
nombre de lignes souhaité (auquel cas ça me va car je sais alors que
la commande ls ne pompera pas trop de ressources réseaux quel que soit
le répertoire en face) ou bien ls continue-t-il son travail dans le
vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se
situe pas au niveau réseau puisque le ls va à son terme) ?
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Le souci c'est que ça me gêne un peu que le check modifie le système de fichiers (via une écriture), j'aimerais vraiment éviter d'y toucher.
Du coup, par rapport au "ls -f", je me suis dis que je pouvais le piper avec head afin d'écourter le travail de la commande ls. J'ai l'impression que ça marche. Sur des VMs, j'ai créé un partage nfs avec 100 000 fichiers dedans et j'ai tenté ceci :
---- ~# mount -t nfs 192.168.109:/test /test/ && time timeout --signal=SIGKILL 3 ls -f /test | head > /dev/null; echo $?
real 0m0.714s user 0m0.016s sys 0m0.004s 0 ----
Dans les mêmes conditions avec redémarrage du client et du serveur mais sans le « | head », j'ai :
real 0m2.564s user 0m0.016s sys 0m0.324s
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité (auquel cas ça me va car je sais alors que la commande ls ne pompera pas trop de ressources réseaux quel que soit le répertoire en face) ou bien ls continue-t-il son travail dans le vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se situe pas au niveau réseau puisque le ls va à son terme) ?
