Hello,
 
Un diagnostique d'un professionnel explique un crash disque suite à une saturation du disque 2 mois plus tôt, l'explication est la suivante :
Mon collègue a expliqué que pour moi cela provenait de la saturation des disques pendant 3 semaines qui n’a pas été observé à temps. Et à proprement parlé, ce type d’erreur Disque est très perfide. Pour exemple, mySQL va écrire un jour sur une table d’allocation non réservée au moment de la saturation des Disques, à moins de le désinstaller et le réinstaller il fera toujours appel à un moment à cette partition qui ne peut être physiquement alloué, d’où l’erreur. Maintenant avec toutes les recherches que j’ai pu faire on a aucun moyen de trouver le  ou les fichiers incriminés, hormis démonter les disques et les faire analyser par des sociétés de recouvrement de données.
 
J'ai pour ma part un minimum de culture sur les tables d'allocation, le hardware & co. En bon geek ça fait des années que j'ai eu des disques saturés sans conséquence majeure. Du coup mes interrogations :
 
Que pensez vous de cette explication ? (un peu confuse non ?)  
Avez vous déjà rencontré ce type d'erreur ?  
Je reste un peu sceptique pour ma part mais je serais heureux d'en apprendre davantage

up du soir !

+1. C'est trop confu pour que je puisse afirmaer que c'est de la connerie en branche, mais ça y ressemble vachement.
Sous windows95, je dit pas, mais on a maintenant des sytème raisonable qui savent utiliser les mutex avant d'ecrire des trucs sur un disque  

Merci pour ta réponse !
 
En plus il ne s'agit pas d'un très vieil OS, c'est sur du windows 2000 serveur...
 
Personne d'autre n'a d'opinion sur la question ?

C'est bien du pipo ça, c'est uniquement l'OS qui va interragir avec la table d'allocation des fichiers, jamais les logiciels en direct.
et l'OS n'est pas buggé de telle sorte qu'il écrive sur des zones pas prévues pour...  

pour une base de données, c'est faux, mais ce n'est pas juste un délire de ton ami. Afin d'optimiser la fragmentation des fichiers, les SGDB peuvent utiliser leur propre allocation (ils crée un enorme fichier blanc et contigue et repartissent les donnes comme le fairait un OS).  
Mais un bug dans cette allocation planterais la base, pas le disque.

Ok, merci pour ce complément d'information.
 
(j'up encore un peu voir si je peux collecter un peu plus d"avis )

Up du début de la semaine !
 
Personne n'a d'opinion sur le cas exposé ?

ce qui est possible :
 
tout sur la meme partition (je sais, c est furieusement crade et plus personne ne fait aussi moche mais bon ca peut arriver).
Ta partition C se remplie, se remplie, se remplie ... puis un jour , il a plus assé d espace pour le fichier de swap.
 
cela dit, tu nous dis pas si c est un crash hardware ou software

d'après le prestataire c'est une erreur hardware.
(du moins c'est le statut final annoncé au client...)

Ahem. Je sais, j'arrive et toussa , mais c'est quoi cette histoire ? Aurais-tu un lien vers une conclusion professionnelle définitive ? En quoi c'est moins endommageant pour le disque de faire des partitions ?
 
[edit] Décidément, si on a beaucoup de trafic, ça revient au même, et en multipliant les partitions on ne multiplie pas les têtes de lecture  . Donc amha le mieux c'est une partition, fixer la mémoire virtuelle dès formattage, puis défragmentation toutes les semaines Ou le meilleur: séparer physiquement en plusieurs durs.

En l'occurence le serveur utilise 2 partitions (car 2 disques durs ), avec le serveur mysql sur le disque non système... (puisque soit disant c'est mysql le coupable)
 
concernant le fond du problème : avez vous déjà eu des erreurs graves sur un disque juste parce qu'il était plein ?!

Je n'ai mème jamsi entendu parler d'un logiciel (autre peut-etre qu'un flasheur de BIOS) qui crée de domage physique à un DD simplement parceque ça n'arive pas.
Si le problème et physique, c'est pas mySQL le coupable et quiconque te dit le contraire est un idiot(ou quelqu'un qui cherche à te vendre SQL server).

 
non non ok, je restais dans l idee que ca pouvait etre un probleme purement software.
 
Windows demarre, par de bol, pas assé d espace sur le HD pour gerer le SWAP dont il a besoin : crash.  
 
mais la si c est hardware ....
 
 
cela dit, oui en effet, si le HD est plein, en tehorie, on a plus de chace d'utiliser un secteur defectueux.
En pratique, je l ai jamais croisé.
 
mais en aucun cas, un HD plein ne dertuira le HD

 
 
meme pas un petit systeme de mirroir ? pour un serveur qui semble important c est la moindre des choses.

pas de problèmes pour les backups.
C'est juste que le crash était vraiment pas clair à définir, assez important pour paralyser le serveur au point de requérir la mise en place d'un serveur identique.  
Et le gars nous envoie sa conclusion que mysql a fait crashé le serveur, car c'est mysql le premier qui a subit l'agonie des disques...

Faudrait déjà pouvoir identifier précisément la mort d'un disque. Il faut donc que ce soit celui qu'on utilise. Et si on sait identifier précisément la cause du décès on a les connaissances pour qu'il ait une vie saine
 
Non mais c'est du pipeau de technicien info Il est vrai que l'utilisation intensive joue sur la durée de vie du disque, mais il est encore plus vrai que si on dit "chai pas moi, il est mort c'est tout" à un client payant on passe pour des guignols A méditer sur la place de l'honnêteté dans la société d'aujourd'hui  
 
En plus tu peux refroidir les disques et leur donner une bonne alim, des câbles qui ne bougent pas etc, mais pour le trafic.... A part dévier sur plusieurs disques, ou scsi, raid etc
 
[edit] Enlevé quelques smilies, c'était lourd

Merci pour vos réponses, ça me conforte dans mon opinion
 
Rapport à l'honnêteté, un client peut comprendre la nature mécanique des pannes, c'est comme une voiture, tu prévois pas forcément que le joint de culasse va péter. Et dans les 2 cas il peut y avoir au préalable une perte de performance suite à la dégénéréscence du matériel...
 
Mais de là à produire des excuses qui peuvent mettre en jeu un tier, je trouve pas ça fin ! Mais c'est une autre histoire
 

Ben justement c'est ça l'intérêt du pipeau: paraitre avoir le contrôle et faire comprendre au client la panne, comme ça il part satisfait parce qu'un peu plus instruit. En l'occurence, il faut retenir "disque dur trop plein", ce qui en soi n'est pas un mauvais conseil.  
 
Mais bon, c'est juste une forte probabilité. Peut-être que ce que dit le mec est justifié, qui sait. Faudrait voir la même chose que lui, les événements avant le "crash" etc.