Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve
sur un disque miroré via le raid linux (mdadm...). Un shutdown -F a
effectivement fait un fsck au boot mais j'ai l'impression qu'il a été
vraiment rapide et minimaliste et je ne trouve pas de log pour savoir ce
qu'il a vraiment fait.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var... Je ne sais pas comment
m'y prendre. J'ai cru comprendre qu'il était aussi possible de booter
sur un live cd ou un cd d'install en mode rescue.
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas la vérification des blocs défectueux qu'il sous-traite à badblocks. Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel disque, partition ou volume. Le mode par défaut (lecture seule) ne nécessite pas de démontage.
Salut,
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve
sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas
la vérification des blocs défectueux qu'il sous-traite à badblocks.
Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel
disque, partition ou volume. Le mode par défaut (lecture seule) ne
nécessite pas de démontage.
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas la vérification des blocs défectueux qu'il sous-traite à badblocks. Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel disque, partition ou volume. Le mode par défaut (lecture seule) ne nécessite pas de démontage.
François Tricard
Salut,
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas la vérification des blocs défectueux qu'il sous-traite à badblocks. Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel disque, partition ou volume. Le mode par défaut (lecture seule) ne nécessite pas de démontage.
Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS o/. Si j'ai compris, a present, il faut que je passe en mode single-user ("init 1"), que je monte la partition en RO, puis que je lance un e2fsck pour corriger et marquer les bloque HS ?
Salut,
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se
trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas
la vérification des blocs défectueux qu'il sous-traite à badblocks.
Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel
disque, partition ou volume. Le mode par défaut (lecture seule) ne
nécessite pas de démontage.
Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS
o/. Si j'ai compris, a present, il faut que je passe en mode
single-user ("init 1"), que je monte la partition en RO, puis que je
lance un e2fsck pour corriger et marquer les bloque HS ?
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas la vérification des blocs défectueux qu'il sous-traite à badblocks. Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel disque, partition ou volume. Le mode par défaut (lecture seule) ne nécessite pas de démontage.
Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS o/. Si j'ai compris, a present, il faut que je passe en mode single-user ("init 1"), que je monte la partition en RO, puis que je lance un e2fsck pour corriger et marquer les bloque HS ?
Michel Tatoute
François Tricard wrote:
Salut,
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas la vérification des blocs défectueux qu'il sous-traite à badblocks. Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel disque, partition ou volume. Le mode par défaut (lecture seule) ne nécessite pas de démontage.
Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS o/. Si j'ai compris, a present, il faut que je passe en mode single-user ("init 1"), que je monte la partition en RO, puis que je lance un e2fsck pour corriger et marquer les bloque HS ?
si ton disque fait partie d'un raid ca ne va pas le faire.
de toute façon un disque qui fait des bads blocks est juste bon pour la poubelle (les bad blocks étant la partie émergée du problème).
Donc tu recupere les infos et tu change le disque.
Y a t'il des informations importantes dessus?
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring sur /var ? Généralement les données sur /var sont temporaires et de peu de valeur... non?
Michel.
François Tricard wrote:
Salut,
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se
trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais
refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer
une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas
la vérification des blocs défectueux qu'il sous-traite à badblocks.
Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel
disque, partition ou volume. Le mode par défaut (lecture seule) ne
nécessite pas de démontage.
Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS
o/. Si j'ai compris, a present, il faut que je passe en mode
single-user ("init 1"), que je monte la partition en RO, puis que je
lance un e2fsck pour corriger et marquer les bloque HS ?
si ton disque fait partie d'un raid ca ne va pas le faire.
de toute façon un disque qui fait des bads blocks est juste bon pour la
poubelle (les bad blocks étant la partie émergée du problème).
Donc tu recupere les infos et tu change le disque.
Y a t'il des informations importantes dessus?
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring
sur /var ? Généralement les données sur /var sont temporaires et de peu de
valeur... non?
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Pour moi, mon disque comporte des blocks déféctueux alors j'aimerais refaire un fsck avec un maximum de controle. Pourriez vous m'indiquer une procédure ? J'ai peur de démonter le /var
Le but premier de fsck est la vérification du système de fichiers, pas la vérification des blocs défectueux qu'il sous-traite à badblocks. Celui-ci peut être exécuté indépendamment de fsck sur n'importe quel disque, partition ou volume. Le mode par défaut (lecture seule) ne nécessite pas de démontage.
Merci pour la piste, j'ai donc analysé la partoche et j'ai 53 bloques HS o/. Si j'ai compris, a present, il faut que je passe en mode single-user ("init 1"), que je monte la partition en RO, puis que je lance un e2fsck pour corriger et marquer les bloque HS ?
si ton disque fait partie d'un raid ca ne va pas le faire.
de toute façon un disque qui fait des bads blocks est juste bon pour la poubelle (les bad blocks étant la partie émergée du problème).
Donc tu recupere les infos et tu change le disque.
Y a t'il des informations importantes dessus?
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring sur /var ? Généralement les données sur /var sont temporaires et de peu de valeur... non?
Michel.
Pascal Hambourg
François Tricard wrote:
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Tu veux dire que hdc8 est une partition RAID qui fait partie d'un volume RAID 1 mdX, lui-même monté en tant que /var ?
[...]
j'ai donc analysé la partoche et j'ai 53 bloques HS o/. Si j'ai compris, a present, il faut que je passe en mode single-user ("init 1"), que je monte la partition en RO, puis que je lance un e2fsck pour corriger et marquer les bloque HS ?
Petite précision : fsck ne corrige pas les blocs défecteux, il ne fait que les marquer pour qu'ils ne soient plus utilisés par le système de fichiers.
si ton disque fait partie d'un raid ca ne va pas le faire.
Déjà il ne faut pas exécuter fsck -c sur la partition physique (hdc8) mais sur le volume RAID (mdX) qui contient le système de fichiers. Ensuite, le RAID 1 risque de cacher des blocs défectueux. En effet lors d'une opération de lecture un bloc du volume RAID 1 est lu sur une seule des deux partitions physiques. Si le bloc défectueux correspondant se trouve sur l'autre partition physique, il passe inaperçu. On peut vérifier le volume plusieurs fois, mais ça ne garantit pas que tous les blocs défectueux seront détectés. On peut éventuellement contourner le problème en sortant la partition saine du RAID avant de lancer la vérification, puis en la réintégrant et en répliquant le contenu de la partition qui a subi la vérification. Sinon, il y a peut-être moyen d'utiliser la liste des blocs trouvés par badblocks sur la partition physique en la fournissant à fsck, mais ça me semble délicat : il faut notamment prendre en compte la taille de bloc du système de fichiers, l'offset du début du volume par rapport au début de la partition...
de toute façon un disque qui fait des bads blocks est juste bon pour la poubelle (les bad blocks étant la partie émergée du problème).
Je ne serais par aussi catégorique. J'ai récupéré pour mon usage personnel plusieurs disques poubellisés pour cause de secteurs défectueux. La plupart continuent de fonctionner normalement après tentative de réparation (en fait réallocation) des secteurs défectueux et le cas échéant marquage de ceux qui n'ont pu être réparés. On entend souvent qu'une fois que des secteurs défectueux apparaissent, ça ne fait qu'empirer. Ce n'est pas ce que je constate. Il faut regarder les informations SMART du disque concernant la réallocation des secteurs. Si des secteurs défectueux deviennent visibles parce que la réserve est épuisée et que le nombre de secteurs réalloués a atteint son maximum, alors effectivement le disque est cuit. Dans le cas contraire, j'ai plutôt l'impression que des secteurs défectueux peuvent apparaître, probablement dans certaines conditions de stress (température trop élevée, alimentation instable...), sans impact sur la durée de vie du disque.
Au final c'est à chacun de voir, en fonction du prix qu'il accorde à ses données.
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring sur /var ?
La même chose que le mirroring du swap : une meilleure disponibilité du système.
Généralement les données sur /var sont temporaires et de peu de valeur... non?
Euh, il me semble qu'il peut y avoir des trucs assez importants dans /var, comme tout ce qui concerne la gestion des paquetages, la racine du site web, les bases de données... Et même s'il n'y a que des trucs temporaires sans importance, les applications qui s'en servent risquent de beaucoup moins bien marcher en cas de perte du disque la contenant.
François Tricard wrote:
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se
trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Tu veux dire que hdc8 est une partition RAID qui fait partie d'un volume
RAID 1 mdX, lui-même monté en tant que /var ?
[...]
j'ai donc analysé la partoche et j'ai 53 bloques HS
o/. Si j'ai compris, a present, il faut que je passe en mode
single-user ("init 1"), que je monte la partition en RO, puis que je
lance un e2fsck pour corriger et marquer les bloque HS ?
Petite précision : fsck ne corrige pas les blocs défecteux, il ne fait
que les marquer pour qu'ils ne soient plus utilisés par le système de
fichiers.
si ton disque fait partie d'un raid ca ne va pas le faire.
Déjà il ne faut pas exécuter fsck -c sur la partition physique (hdc8)
mais sur le volume RAID (mdX) qui contient le système de fichiers.
Ensuite, le RAID 1 risque de cacher des blocs défectueux. En effet lors
d'une opération de lecture un bloc du volume RAID 1 est lu sur une seule
des deux partitions physiques. Si le bloc défectueux correspondant se
trouve sur l'autre partition physique, il passe inaperçu. On peut
vérifier le volume plusieurs fois, mais ça ne garantit pas que tous les
blocs défectueux seront détectés. On peut éventuellement contourner le
problème en sortant la partition saine du RAID avant de lancer la
vérification, puis en la réintégrant et en répliquant le contenu de la
partition qui a subi la vérification. Sinon, il y a peut-être moyen
d'utiliser la liste des blocs trouvés par badblocks sur la partition
physique en la fournissant à fsck, mais ça me semble délicat : il faut
notamment prendre en compte la taille de bloc du système de fichiers,
l'offset du début du volume par rapport au début de la partition...
de toute façon un disque qui fait des bads blocks est juste bon pour la
poubelle (les bad blocks étant la partie émergée du problème).
Je ne serais par aussi catégorique. J'ai récupéré pour mon usage
personnel plusieurs disques poubellisés pour cause de secteurs
défectueux. La plupart continuent de fonctionner normalement après
tentative de réparation (en fait réallocation) des secteurs défectueux
et le cas échéant marquage de ceux qui n'ont pu être réparés. On entend
souvent qu'une fois que des secteurs défectueux apparaissent, ça ne fait
qu'empirer. Ce n'est pas ce que je constate. Il faut regarder les
informations SMART du disque concernant la réallocation des secteurs. Si
des secteurs défectueux deviennent visibles parce que la réserve est
épuisée et que le nombre de secteurs réalloués a atteint son maximum,
alors effectivement le disque est cuit. Dans le cas contraire, j'ai
plutôt l'impression que des secteurs défectueux peuvent apparaître,
probablement dans certaines conditions de stress (température trop
élevée, alimentation instable...), sans impact sur la durée de vie du
disque.
Au final c'est à chacun de voir, en fonction du prix qu'il accorde à ses
données.
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring
sur /var ?
La même chose que le mirroring du swap : une meilleure disponibilité du
système.
Généralement les données sur /var sont temporaires et de peu de
valeur... non?
Euh, il me semble qu'il peut y avoir des trucs assez importants dans
/var, comme tout ce qui concerne la gestion des paquetages, la racine du
site web, les bases de données... Et même s'il n'y a que des trucs
temporaires sans importance, les applications qui s'en servent risquent
de beaucoup moins bien marcher en cas de perte du disque la contenant.
Je dois exécuter un fsck sur une partition (hdc8 -> /var) qui se trouve sur un disque miroré via le raid linux (mdadm...).
Les volumes RAID ne s'appellent pas plutôt mdX ?
oui, mais là je parle d'un disque précis et d'une partion précise.
Tu veux dire que hdc8 est une partition RAID qui fait partie d'un volume RAID 1 mdX, lui-même monté en tant que /var ?
[...]
j'ai donc analysé la partoche et j'ai 53 bloques HS o/. Si j'ai compris, a present, il faut que je passe en mode single-user ("init 1"), que je monte la partition en RO, puis que je lance un e2fsck pour corriger et marquer les bloque HS ?
Petite précision : fsck ne corrige pas les blocs défecteux, il ne fait que les marquer pour qu'ils ne soient plus utilisés par le système de fichiers.
si ton disque fait partie d'un raid ca ne va pas le faire.
Déjà il ne faut pas exécuter fsck -c sur la partition physique (hdc8) mais sur le volume RAID (mdX) qui contient le système de fichiers. Ensuite, le RAID 1 risque de cacher des blocs défectueux. En effet lors d'une opération de lecture un bloc du volume RAID 1 est lu sur une seule des deux partitions physiques. Si le bloc défectueux correspondant se trouve sur l'autre partition physique, il passe inaperçu. On peut vérifier le volume plusieurs fois, mais ça ne garantit pas que tous les blocs défectueux seront détectés. On peut éventuellement contourner le problème en sortant la partition saine du RAID avant de lancer la vérification, puis en la réintégrant et en répliquant le contenu de la partition qui a subi la vérification. Sinon, il y a peut-être moyen d'utiliser la liste des blocs trouvés par badblocks sur la partition physique en la fournissant à fsck, mais ça me semble délicat : il faut notamment prendre en compte la taille de bloc du système de fichiers, l'offset du début du volume par rapport au début de la partition...
de toute façon un disque qui fait des bads blocks est juste bon pour la poubelle (les bad blocks étant la partie émergée du problème).
Je ne serais par aussi catégorique. J'ai récupéré pour mon usage personnel plusieurs disques poubellisés pour cause de secteurs défectueux. La plupart continuent de fonctionner normalement après tentative de réparation (en fait réallocation) des secteurs défectueux et le cas échéant marquage de ceux qui n'ont pu être réparés. On entend souvent qu'une fois que des secteurs défectueux apparaissent, ça ne fait qu'empirer. Ce n'est pas ce que je constate. Il faut regarder les informations SMART du disque concernant la réallocation des secteurs. Si des secteurs défectueux deviennent visibles parce que la réserve est épuisée et que le nombre de secteurs réalloués a atteint son maximum, alors effectivement le disque est cuit. Dans le cas contraire, j'ai plutôt l'impression que des secteurs défectueux peuvent apparaître, probablement dans certaines conditions de stress (température trop élevée, alimentation instable...), sans impact sur la durée de vie du disque.
Au final c'est à chacun de voir, en fonction du prix qu'il accorde à ses données.
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring sur /var ?
La même chose que le mirroring du swap : une meilleure disponibilité du système.
Généralement les données sur /var sont temporaires et de peu de valeur... non?
Euh, il me semble qu'il peut y avoir des trucs assez importants dans /var, comme tout ce qui concerne la gestion des paquetages, la racine du site web, les bases de données... Et même s'il n'y a que des trucs temporaires sans importance, les applications qui s'en servent risquent de beaucoup moins bien marcher en cas de perte du disque la contenant.
Mihamina (R12y) Rakotomandimby
Pascal Hambourg wrote:
Généralement les données sur /var sont temporaires et de peu de valeur... non? Euh, il me semble qu'il peut y avoir des trucs assez importants dans
/var, comme tout ce qui concerne la gestion des paquetages, la racine du site web, les bases de données...
/var/www, /var/lib/mysql,... Si c'est pas important ça,...
Pascal Hambourg wrote:
Généralement les données sur /var sont temporaires et de peu de
valeur... non?
Euh, il me semble qu'il peut y avoir des trucs assez importants dans
/var, comme tout ce qui concerne la gestion des paquetages, la racine du
site web, les bases de données...
/var/www, /var/lib/mysql,...
Si c'est pas important ça,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée baroque de le mettre dans /var.
Mihamina (R12y) Rakotomandimby
Nicolas George wrote:
R12y wrote in message <fbopjc$igt$:
/var/www, /var/lib/mysql,... Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold. Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature requests au niveau des distributions pour changer cette organisation historique. Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que c'est le moins pire.
Nicolas George wrote:
R12y wrote in message <fbopjc$igt$1@cabale.usenet-fr.net>:
/var/www, /var/lib/mysql,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold.
Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature
requests au niveau des distributions pour changer cette organisation
historique.
Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que
c'est le moins pire.
/var/www, /var/lib/mysql,... Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold. Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature requests au niveau des distributions pour changer cette organisation historique. Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que c'est le moins pire.
Mihamina (R12y) Rakotomandimby
Nicolas George wrote:
R12y wrote in message <fbopjc$igt$:
/var/www, /var/lib/mysql,... Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold. Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature requests au niveau des distributions pour changer cette organisation historique. Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que c'est le moins pire.
Nicolas George wrote:
R12y wrote in message <fbopjc$igt$1@cabale.usenet-fr.net>:
/var/www, /var/lib/mysql,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold.
Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature
requests au niveau des distributions pour changer cette organisation
historique.
Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que
c'est le moins pire.
/var/www, /var/lib/mysql,... Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold. Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature requests au niveau des distributions pour changer cette organisation historique. Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que c'est le moins pire.
Jerome Lambert
Nicolas George wrote:
R12y wrote in message <fbopjc$igt$:
/var/www, /var/lib/mysql,... Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold. Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature requests au niveau des distributions pour changer cette organisation historique. Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que c'est le moins pire.
Pour l'organisation des fichiers, il y a eu ici récemment toute une discussion là-dessus, notamment avec S.T. En gros, il y a deux approches: 1) on suit les recommandations des développeurs du programme initial, donc si la doc dit de mettre les fichiers à tel endroit, on les y met même si c'est une ineptie. Cette façon de procéder permet de mieux s'y retrouver en cas de parc (très) hétérogène, les fichiers étant au même endroit quel que soit le Unix ou la distribution utilisé.
2) on respecte les standards de l'arborescence, et vu que /var/ est censé cotenir des données modifiables pendant l'exécution, donc pour reprendre l'exemple d'apache /var/www est effectivement une ineptie. De cette manière l'arborescence reste claire et logique, mais alors chaque Unix/distribution Linux risque de poposer *sa* solution alternative. La doc d'apache stipule /usr/local/apache/htdocs comme défaut, mais donne aussi l'exemple de /usr/web comme alternative, FreeBSD met comme défaut /usr/local/www/data, MacOS X /Library/WebServer/Documents et j'ai aussi vu passer des /home/httpd.
Nicolas George wrote:
R12y wrote in message <fbopjc$igt$1@cabale.usenet-fr.net>:
/var/www, /var/lib/mysql,...
Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold.
Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature
requests au niveau des distributions pour changer cette organisation
historique.
Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que
c'est le moins pire.
Pour l'organisation des fichiers, il y a eu ici récemment toute une
discussion là-dessus, notamment avec S.T. En gros, il y a deux approches:
1) on suit les recommandations des développeurs du programme initial,
donc si la doc dit de mettre les fichiers à tel endroit, on les y met
même si c'est une ineptie. Cette façon de procéder permet de mieux s'y
retrouver en cas de parc (très) hétérogène, les fichiers étant au même
endroit quel que soit le Unix ou la distribution utilisé.
2) on respecte les standards de l'arborescence, et vu que /var/ est
censé cotenir des données modifiables pendant l'exécution, donc pour
reprendre l'exemple d'apache /var/www est effectivement une ineptie. De
cette manière l'arborescence reste claire et logique, mais alors chaque
Unix/distribution Linux risque de poposer *sa* solution alternative. La
doc d'apache stipule /usr/local/apache/htdocs comme défaut, mais donne
aussi l'exemple de /usr/web comme alternative, FreeBSD met comme défaut
/usr/local/www/data, MacOS X /Library/WebServer/Documents et j'ai aussi
vu passer des /home/httpd.
/var/www, /var/lib/mysql,... Le deuxième est raisonnable, mais le premier, c'est vraiment une idée
baroque de le mettre dans /var.
Je fais suivre sur fcold. Oui, en meme temps, je n'ai pas vu beaucoup de bugs ni de feature requests au niveau des distributions pour changer cette organisation historique. Soit j'ai raté les moments ou ils discutaient de ça, soit c'est que c'est le moins pire.
Pour l'organisation des fichiers, il y a eu ici récemment toute une discussion là-dessus, notamment avec S.T. En gros, il y a deux approches: 1) on suit les recommandations des développeurs du programme initial, donc si la doc dit de mettre les fichiers à tel endroit, on les y met même si c'est une ineptie. Cette façon de procéder permet de mieux s'y retrouver en cas de parc (très) hétérogène, les fichiers étant au même endroit quel que soit le Unix ou la distribution utilisé.
2) on respecte les standards de l'arborescence, et vu que /var/ est censé cotenir des données modifiables pendant l'exécution, donc pour reprendre l'exemple d'apache /var/www est effectivement une ineptie. De cette manière l'arborescence reste claire et logique, mais alors chaque Unix/distribution Linux risque de poposer *sa* solution alternative. La doc d'apache stipule /usr/local/apache/htdocs comme défaut, mais donne aussi l'exemple de /usr/web comme alternative, FreeBSD met comme défaut /usr/local/www/data, MacOS X /Library/WebServer/Documents et j'ai aussi vu passer des /home/httpd.
nicolas vigier
On 2007-09-06, Jerome Lambert wrote:
2) on respecte les standards de l'arborescence, et vu que /var/ est censé cotenir des données modifiables pendant l'exécution, donc pour reprendre l'exemple d'apache /var/www est effectivement une ineptie. De
Pourquoi une ineptie ? Tu ne modifies jamais tes pages web ? Pour moi /var contient toutes les données qui peuvent etre modifiées (ca correspond aux pages d'un serveur web). /usr ne contient que des données qui proviennent du système (de packages) et que l'on a aucun interet à backuper.
On 2007-09-06, Jerome Lambert <jerome.lambert@swing.be> wrote:
2) on respecte les standards de l'arborescence, et vu que /var/ est
censé cotenir des données modifiables pendant l'exécution, donc pour
reprendre l'exemple d'apache /var/www est effectivement une ineptie. De
Pourquoi une ineptie ? Tu ne modifies jamais tes pages web ?
Pour moi /var contient toutes les données qui peuvent etre modifiées
(ca correspond aux pages d'un serveur web). /usr ne contient que des
données qui proviennent du système (de packages) et que l'on a aucun
interet à backuper.
2) on respecte les standards de l'arborescence, et vu que /var/ est censé cotenir des données modifiables pendant l'exécution, donc pour reprendre l'exemple d'apache /var/www est effectivement une ineptie. De
Pourquoi une ineptie ? Tu ne modifies jamais tes pages web ? Pour moi /var contient toutes les données qui peuvent etre modifiées (ca correspond aux pages d'un serveur web). /usr ne contient que des données qui proviennent du système (de packages) et que l'on a aucun interet à backuper.
