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.
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).
Non car modifiées par l'OS, comme un spool, des mails à traiter, les logs, des caches etc., et non par l'utilisateur.
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).
Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
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).
Non car modifiées par l'OS, comme un spool, des mails à traiter, les logs, des caches etc., et non par l'utilisateur.
Yannick Patois
Jerome Lambert wrote:
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). Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Pas completement d'accord. Je dirais que dans /var, je met ce qui ne pourrait pas etre monté en Read-Only.
Mettre www sous /usr me parait bien plus aberrant que sous /var.
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce sens, /home/http est aussi cohérent...
D'autant que, sauf pour les pages statiques, y'a bien des fichiers modifiés sur un www! Il suffit d'une interface pour uploader des images, par exemple. Et c'est bien le process http qui le fait!
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).
Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Pas completement d'accord. Je dirais que dans /var, je met ce qui ne
pourrait pas etre monté en Read-Only.
Mettre www sous /usr me parait bien plus aberrant que sous /var.
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce
sens, /home/http est aussi cohérent...
D'autant que, sauf pour les pages statiques, y'a bien des fichiers
modifiés sur un www! Il suffit d'une interface pour uploader des images,
par exemple. Et c'est bien le process http qui le fait!
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). Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Pas completement d'accord. Je dirais que dans /var, je met ce qui ne pourrait pas etre monté en Read-Only.
Mettre www sous /usr me parait bien plus aberrant que sous /var.
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce sens, /home/http est aussi cohérent...
D'autant que, sauf pour les pages statiques, y'a bien des fichiers modifiés sur un www! Il suffit d'une interface pour uploader des images, par exemple. Et c'est bien le process http qui le fait!
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce sens, /home/http est aussi cohérent...
Mouais... mettons nous du coté des hébergeurs de sites, qui sont quand même de gros consommateurs d'Apache... Chaque client doit: - avoir acces FTP (rw) à son espace Web - ne pas être "trop pres" des fichiers utiles au système - avoir un espace web exclusif, accessible par le daemon Apache - ...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut.
Yannick Patois wrote:
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce
sens, /home/http est aussi cohérent...
Mouais... mettons nous du coté des hébergeurs de sites, qui sont quand
même de gros consommateurs d'Apache...
Chaque client doit:
- avoir acces FTP (rw) à son espace Web
- ne pas être "trop pres" des fichiers utiles au système
- avoir un espace web exclusif, accessible par le daemon Apache
- ...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou
mettre intelligemment le DocumentRoot par défaut.
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce sens, /home/http est aussi cohérent...
Mouais... mettons nous du coté des hébergeurs de sites, qui sont quand même de gros consommateurs d'Apache... Chaque client doit: - avoir acces FTP (rw) à son espace Web - ne pas être "trop pres" des fichiers utiles au système - avoir un espace web exclusif, accessible par le daemon Apache - ...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut.
Jerome Lambert
Jerome Lambert wrote:
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). Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Pas completement d'accord. Je dirais que dans /var, je met ce qui ne pourrait pas etre monté en Read-Only.
Non. /var est est conçu pour être le lieu où l'OS fait sa "tambouille". Voir p.ex. "/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files." http://www.pathname.com/fhs/pub/fhs-2.3.html
/www ne correspond pas à la description ci-dessus.
Mettre www sous /usr me parait bien plus aberrant que sous /var.
Oui, ne fut-ce que parce que /usr est censé être en lecture seule.
Et /var me parait être le lieu où l'on met le 'home' des démons,
les démons n'ont pas de "home". Ils ont des fichiers éclatés un peu partout (config dans /etc, exécutables dans /usr/(s)bin/, ...), par contre leurs journaux et leurs spools (donc les fichiers qui évoluent dans le temps) sont dans /var
dans ce sens, /home/http est aussi cohérent...
A tout prendre, oui, tout comme le /Library/WebServer/Documents de MacOS X. Sinon la norme citée ci-dessus fait mention d'un /srv "/srv contains site-specific data which is served by this system
This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. (...)
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs."
D'autant que, sauf pour les pages statiques, y'a bien des fichiers modifiés sur un www! Il suffit d'une interface pour uploader des images, par exemple. Et c'est bien le process http qui le fait!
Oui, mais /var n'est pas fait pour ça... ;-)
Jerome Lambert wrote:
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).
Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Pas completement d'accord. Je dirais que dans /var, je met ce qui ne
pourrait pas etre monté en Read-Only.
Non. /var est est conçu pour être le lieu où l'OS fait sa "tambouille".
Voir p.ex.
"/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary files."
http://www.pathname.com/fhs/pub/fhs-2.3.html
/www ne correspond pas à la description ci-dessus.
Mettre www sous /usr me parait bien plus aberrant que sous /var.
Oui, ne fut-ce que parce que /usr est censé être en lecture seule.
Et /var me parait être le lieu où l'on met le 'home' des démons,
les démons n'ont pas de "home". Ils ont des fichiers éclatés un peu
partout (config dans /etc, exécutables dans /usr/(s)bin/, ...), par
contre leurs journaux et leurs spools (donc les fichiers qui évoluent
dans le temps) sont dans /var
dans ce sens, /home/http est aussi cohérent...
A tout prendre, oui, tout comme le /Library/WebServer/Documents de MacOS
X. Sinon la norme citée ci-dessus fait mention d'un /srv
"/srv contains site-specific data which is served by this system
This main purpose of specifying this is so that users may find the
location of the data files for particular service, and so that services
which require a single tree for readonly data, writable data and scripts
(such as cgi scripts) can be reasonably placed. (...)
The methodology used to name subdirectories of /srv is unspecified as
there is currently no consensus on how this should be done. One method
for structuring data under /srv is by protocol, eg. ftp, rsync, www, and
cvs."
D'autant que, sauf pour les pages statiques, y'a bien des fichiers
modifiés sur un www! Il suffit d'une interface pour uploader des images,
par exemple. Et c'est bien le process http qui le fait!
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). Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Pas completement d'accord. Je dirais que dans /var, je met ce qui ne pourrait pas etre monté en Read-Only.
Non. /var est est conçu pour être le lieu où l'OS fait sa "tambouille". Voir p.ex. "/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files." http://www.pathname.com/fhs/pub/fhs-2.3.html
/www ne correspond pas à la description ci-dessus.
Mettre www sous /usr me parait bien plus aberrant que sous /var.
Oui, ne fut-ce que parce que /usr est censé être en lecture seule.
Et /var me parait être le lieu où l'on met le 'home' des démons,
les démons n'ont pas de "home". Ils ont des fichiers éclatés un peu partout (config dans /etc, exécutables dans /usr/(s)bin/, ...), par contre leurs journaux et leurs spools (donc les fichiers qui évoluent dans le temps) sont dans /var
dans ce sens, /home/http est aussi cohérent...
A tout prendre, oui, tout comme le /Library/WebServer/Documents de MacOS X. Sinon la norme citée ci-dessus fait mention d'un /srv "/srv contains site-specific data which is served by this system
This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. (...)
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs."
D'autant que, sauf pour les pages statiques, y'a bien des fichiers modifiés sur un www! Il suffit d'une interface pour uploader des images, par exemple. Et c'est bien le process http qui le fait!
Oui, mais /var n'est pas fait pour ça... ;-)
Jerome Lambert
Yannick Patois wrote:
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce sens, /home/http est aussi cohérent...
Mouais... mettons nous du coté des hébergeurs de sites, qui sont quand même de gros consommateurs d'Apache... Chaque client doit: - avoir acces FTP (rw) à son espace Web - ne pas être "trop pres" des fichiers utiles au système - avoir un espace web exclusif, accessible par le daemon Apache - ...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut.
Dans /srv, justement créé à cet effet: <http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM>
Yannick Patois wrote:
Et /var me parait être le lieu où l'on met le 'home' des démons, dans
ce sens, /home/http est aussi cohérent...
Mouais... mettons nous du coté des hébergeurs de sites, qui sont quand
même de gros consommateurs d'Apache...
Chaque client doit:
- avoir acces FTP (rw) à son espace Web
- ne pas être "trop pres" des fichiers utiles au système
- avoir un espace web exclusif, accessible par le daemon Apache
- ...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou
mettre intelligemment le DocumentRoot par défaut.
Dans /srv, justement créé à cet effet:
<http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM>
Et /var me parait être le lieu où l'on met le 'home' des démons, dans ce sens, /home/http est aussi cohérent...
Mouais... mettons nous du coté des hébergeurs de sites, qui sont quand même de gros consommateurs d'Apache... Chaque client doit: - avoir acces FTP (rw) à son espace Web - ne pas être "trop pres" des fichiers utiles au système - avoir un espace web exclusif, accessible par le daemon Apache - ...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut.
Dans /srv, justement créé à cet effet: <http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM>
Nicolas George
Jerome Lambert , dans le message <46e01acd$0$13866$, a écrit :
Non car modifiées par l'OS, comme un spool, des mails à traiter, les logs, des caches etc., et non par l'utilisateur.
Voilà. La dynamique des pages services par un serveur web est similaire à celle des fichiers dans /home, pas à celle des fichiers dans /var ou dans /usr.
Jerome Lambert , dans le message
<46e01acd$0$13866$ba620e4c@news.skynet.be>, a écrit :
Non car modifiées par l'OS, comme un spool, des mails à traiter, les
logs, des caches etc., et non par l'utilisateur.
Voilà. La dynamique des pages services par un serveur web est similaire à
celle des fichiers dans /home, pas à celle des fichiers dans /var ou dans
/usr.
Jerome Lambert , dans le message <46e01acd$0$13866$, a écrit :
Non car modifiées par l'OS, comme un spool, des mails à traiter, les logs, des caches etc., et non par l'utilisateur.
Voilà. La dynamique des pages services par un serveur web est similaire à celle des fichiers dans /home, pas à celle des fichiers dans /var ou dans /usr.
Thierry B.
--{ Mihamina (R12y) Rakotomandimby a plopé ceci: }--
- ne pas être "trop pres" des fichiers utiles au système
J'ai déja bossé (dur dur) sur les notions de distance en math, mais là je vois que tout se complique d'un coup...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut.
Sur un disque rapide, fiable et trèèèès grand ?
--
Le serveur ne comprend pas beaucoup de valeur numériques: ici, il connait 1664, 51, 27, 11.5 et 43.
--{ Mihamina (R12y) Rakotomandimby a plopé ceci: }--
- ne pas être "trop pres" des fichiers utiles au système
J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou
mettre intelligemment le DocumentRoot par défaut.
Sur un disque rapide, fiable et trèèèès grand ?
--
Le serveur ne comprend pas beaucoup de valeur numériques: ici,
il connait 1664, 51, 27, 11.5 et 43.
--{ Mihamina (R12y) Rakotomandimby a plopé ceci: }--
- ne pas être "trop pres" des fichiers utiles au système
J'ai déja bossé (dur dur) sur les notions de distance en math, mais là je vois que tout se complique d'un coup...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut.
Sur un disque rapide, fiable et trèèèès grand ?
--
Le serveur ne comprend pas beaucoup de valeur numériques: ici, il connait 1664, 51, 27, 11.5 et 43.
François Tricard
[...]
bonsoir, merci pour vos interventions.
[...]
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...
Effectivement j'espère pouvoir continuer à utiliser ce disque car il ne me semble pas vraiment mort et son cas ne semble pas s'empirer, il m'empêche juste de resynchroniser le raid :-/
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.
Comme tu dis, je vais d'abord mettre les données au chaud et ensuite mets mes mains dans le cambouit...
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring sur /var ?
Quand on peut, ça ne mange pas de pain. J'ai même /tmp en raid :-)
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?
En se qui me concerne, toute donnée a de la valeur ;-)
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.
A bientôt,
[...]
bonsoir, merci pour vos interventions.
[...]
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...
Effectivement j'espère pouvoir continuer à utiliser ce disque car il ne
me semble pas vraiment mort et son cas ne semble pas s'empirer, il
m'empêche juste de resynchroniser le raid :-/
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.
Comme tu dis, je vais d'abord mettre les données au chaud et ensuite
mets mes mains dans le cambouit...
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring
sur /var ?
Quand on peut, ça ne mange pas de pain. J'ai même /tmp en raid :-)
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?
En se qui me concerne, toute donnée a de la valeur ;-)
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.
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...
Effectivement j'espère pouvoir continuer à utiliser ce disque car il ne me semble pas vraiment mort et son cas ne semble pas s'empirer, il m'empêche juste de resynchroniser le raid :-/
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.
Comme tu dis, je vais d'abord mettre les données au chaud et ensuite mets mes mains dans le cambouit...
Par ailleurs je ne vois pas bien ce que peut apporter un mirroring sur /var ?
Quand on peut, ça ne mange pas de pain. J'ai même /tmp en raid :-)
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?
En se qui me concerne, toute donnée a de la valeur ;-)
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.
A bientôt,
Mihamina (R12y) Rakotomandimby
Thierry B. wrote:
- ne pas être "trop pres" des fichiers utiles au système J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Tout est dans les guillemets. Comme tu sais, ils permettent de ne pas interpreter le contenu de ce qui est dedans. Sinon, bon, je voulais dire que mettre un user à un "cd ../etc" de /etc ou "cd ../bin" de /bin, ça m'a jamais mis à l'aise. Mais j'avoue que c'est psycologique et que techniquement c'est débile.
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut. Sur un disque rapide, fiable et trèèèès grand ?
J'en ai pas encore vu de satisfaisant.
Thierry B. wrote:
- ne pas être "trop pres" des fichiers utiles au système
J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Tout est dans les guillemets.
Comme tu sais, ils permettent de ne pas interpreter le contenu de ce qui
est dedans.
Sinon, bon, je voulais dire que mettre un user à un
"cd ../etc" de /etc ou "cd ../bin" de /bin, ça m'a jamais mis à l'aise.
Mais j'avoue que c'est psycologique et que techniquement c'est débile.
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou
mettre intelligemment le DocumentRoot par défaut.
Sur un disque rapide, fiable et trèèèès grand ?
- ne pas être "trop pres" des fichiers utiles au système J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Tout est dans les guillemets. Comme tu sais, ils permettent de ne pas interpreter le contenu de ce qui est dedans. Sinon, bon, je voulais dire que mettre un user à un "cd ../etc" de /etc ou "cd ../bin" de /bin, ça m'a jamais mis à l'aise. Mais j'avoue que c'est psycologique et que techniquement c'est débile.
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut. Sur un disque rapide, fiable et trèèèès grand ?
J'en ai pas encore vu de satisfaisant.
Jerome Lambert
Thierry B. wrote:
- ne pas être "trop pres" des fichiers utiles au système J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Tout est dans les guillemets. Comme tu sais, ils permettent de ne pas interpreter le contenu de ce qui est dedans. Sinon, bon, je voulais dire que mettre un user à un "cd ../etc" de /etc ou "cd ../bin" de /bin, ça m'a jamais mis à l'aise. Mais j'avoue que c'est psycologique et que techniquement c'est débile.
Si les permissions sont correctement définie et les programmes sont à jour pour la sécurité, les risques sont relativement faibles. Sinon il reste toujours un bon vieux chroot...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut. Sur un disque rapide, fiable et trèèèès grand ?
J'en ai pas encore vu de satisfaisant.
C'est que tu as mal cherché. J'ai pu tester un truc comme ça, et ça traçait grave... http://www.promise.com/product/product_detail_eng.asp?product_id9
Thierry B. wrote:
- ne pas être "trop pres" des fichiers utiles au système
J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Tout est dans les guillemets.
Comme tu sais, ils permettent de ne pas interpreter le contenu de ce qui
est dedans.
Sinon, bon, je voulais dire que mettre un user à un
"cd ../etc" de /etc ou "cd ../bin" de /bin, ça m'a jamais mis à l'aise.
Mais j'avoue que c'est psycologique et que techniquement c'est débile.
Si les permissions sont correctement définie et les programmes sont à
jour pour la sécurité, les risques sont relativement faibles.
Sinon il reste toujours un bon vieux chroot...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas
ou mettre intelligemment le DocumentRoot par défaut.
Sur un disque rapide, fiable et trèèèès grand ?
J'en ai pas encore vu de satisfaisant.
C'est que tu as mal cherché. J'ai pu tester un truc comme ça, et ça
traçait grave...
http://www.promise.com/product/product_detail_eng.asp?product_id9
- ne pas être "trop pres" des fichiers utiles au système J'ai déja bossé (dur dur) sur les notions de distance en math,
mais là je vois que tout se complique d'un coup...
Tout est dans les guillemets. Comme tu sais, ils permettent de ne pas interpreter le contenu de ce qui est dedans. Sinon, bon, je voulais dire que mettre un user à un "cd ../etc" de /etc ou "cd ../bin" de /bin, ça m'a jamais mis à l'aise. Mais j'avoue que c'est psycologique et que techniquement c'est débile.
Si les permissions sont correctement définie et les programmes sont à jour pour la sécurité, les risques sont relativement faibles. Sinon il reste toujours un bon vieux chroot...
Et alors? Ben rien... meme avec ces éléments je ne vois toujours pas ou mettre intelligemment le DocumentRoot par défaut. Sur un disque rapide, fiable et trèèèès grand ?
J'en ai pas encore vu de satisfaisant.
C'est que tu as mal cherché. J'ai pu tester un truc comme ça, et ça traçait grave... http://www.promise.com/product/product_detail_eng.asp?product_id9
