Combien de temps peut prendre fsck sur un volume de 30 To?

À la mi-novembre, un VPS que je loue auprès d'une société d'hébergement a cessé de répondre. Lorsque j'ai contacté le support, ils m'ont expliqué qu'une panne de courant dans le centre de données avait provoqué un redémarrage forcé et fsck. Finalement, j'ai demandé pourquoi cela prenait autant de temps et on m'a dit que la taille du volume était de 30 To. La dernière fois que j'ai reçu une mise à jour, c'était en février, et ils n'ont pas répondu à ma dernière demande.

Je comprends que fsck peut être très lent pour certains systèmes de fichiers, mais est-il possible que fsck prenne 6 mois sur un volume de 30 To, ou devrais-je supposer que cette société d'hébergement me ment pour que je continue à payer ma facture tous les mois?

fsck

— Brian Bi
source

Ils vous ont probablement menti depuis le début. Je m'attendrais à ce que cela prenne des heures . Vous auriez dû arrêter de payer en décembre.

— Michael Hampton

Même s'ils ne mentent pas, choisir une configuration logicielle HW + qui pourrait nécessiter un FSCK qui montre longtemps qu'ils sont incompétents. Et quelle que soit la raison, ils ne fournissent pas le service pour lequel vous payez.

— Peter Cordes

Sonne comme un vrai fsck de cluster!

— JMK

@JMK Maintenant, je souhaite qu'il y ait un moyen de signaler les commentaires pour plus de mérite, peut-être ajouter à un temple de la renommée.

— pipe

Ce que dit @PeterCordes est le point clé. Vous payez pour un service. Vous êtes vraiment désolé d'apprendre qu'ils ont des problèmes, mais vous appelez pour le service que vous payez et que vous n'obtenez pas.

— Rob Moir

Réponses:

fsckla vitesse dépend principalement du nombre de fichiers et de la façon dont ils sont répartis dans le répertoire respectif. Cela dit, 6 mois pour un fsckest absolument absurde: il aurait dû se terminer en quelques heures tout au plus, surtout si on en utilise xfsqui a l' xfs_repairutilité rapide . Ici, vous pouvez trouver des fsckcourses à l'échelle - toutes terminées en moins d'une heure (3600s). Il n'est donc pas possible que votre fscksoit toujours en cours d'exécution.

Quoi qu'il en soit, une perte de puissance inattendue ne causera pas un coup dur fsck, mais seulement une relecture très rapide (quelques secondes) du journal . Cependant, si certains fichiers clés ont été endommagés, le système d'exploitation peut être impossible à démarrer.

Mais ils vous ont probablement menti. Vous devez arrêter de payer immédiatement, demander une explication et demander un remboursement total.

— shodanshok
source

S'ils utilisent ext2, alors une panne de courant nécessitera un plein fsck, et je ne serais pas surpris si cela prend des jours sur un volume de 30 To très utilisé. D'un autre côté, s'ils utilisent ext2un volume de 30 To, c'est en soi une raison de chercher ailleurs des services d'hébergement.

— Mark

ext2 utilise un compteur de blocs 32 bits, avec une taille de bloc maximale de 4096 octets (c'est-à-dire: une page) sur x86 et x86_64. Cela signifie que ext2 (et ext3) sont limités à des volumes de 8 To, donc non, l'OP ne peut pas utiliser ext2 / 3. Quoi qu'il en soit, utiliser n'importe quel système de fichiers non journalisé sur un volume de 30 To serait absolument fou .

— shodanshok

Je pense que ext4 fsck pourrait être un peu mieux si l'on a un FS de 30 To contenant un grand nombre de petits fichiers. La folie pour créer ça, donc encore une raison de chercher ailleurs.

— nigel222

Conjecture: leur système utilise un RAID sans BBU / FBWC (ou même RAID logiciel) avec tous les caches d'écriture possibles (y compris ceux-ci dans les disques durs eux-mêmes) définis à leurs paramètres les plus agressifs, afin d'obtenir des performances maximales à un coût minimal. Une panne de courant sur une telle configuration peut laisser un système de fichiers de journalisation dans une condition où le journal ne peut pas être approuvé et ne peut pas être utilisé pour la récupération. Le problème est qu'un tel système réorganise et retarde de manière agressive les écritures, ce qui signifie qu'une entrée de journal peut être écrite avec l'effet de l'action de données perdue ... ou l'entrée de journal perdue sur une action de données qui était conséquente.

La récupération d'un tel système après une panne dans le pire des cas peut signifier que vous devez effectuer une fsck / réparation "lente" qui examine en fait toutes les structures du système de fichiers telles qu'elles sont, ce qui pourrait en effet prendre un jour ou deux pour 30 To ... et cela il n'est pas improbable que vous deviez exécuter plusieurs cycles de réparation. Ajoutez à cela que le personnel n'est peut-être pas toujours disponible pour surveiller cela, vous pourriez facilement être en train de faire un fsck par semaine. Ils ont probablement abandonné et oublié.

— rackandboneman
source

Pour la plupart des systèmes de fichiers, ce sera beaucoup plus rapide, même en cas d'erreurs, car normalement seules les métadonnées sont vérifiées.

Dans le pire des cas, il peut lire l'intégralité du disque ( par exemple, quelque chose comme fsck.ext4 -cc /dev/sda, qui effectue un test d'écriture non destructif sur chaque bloc), ce qui pourrait prendre quelques jours pour 30 To. Si vous connaissez la vitesse des disques, vous pouvez calculer la taille / vitesse . Pour un disque dur grand public avec environ 100 Mo / s, la copie de quelques To peut prendre plus d'heures que la plupart des gens ne le pensent.

S'il s'agissait de votre serveur, vous pourriez avoir le problème qu'il démarre puis se bloque lorsque fsckvous demande si vous souhaitez corriger une erreur. Mais l'administrateur du centre de données ne laissera pas de fscksuspension pendant 6 mois alors que tous les VPS sont hors ligne.

Donc, soit ils vous mentent, soit il y a un énorme malentendu. Ou ils exécutaient fsck il y a quelque temps et ne vous ont pas informé du nouveau problème une fois terminé.

— allo
source

fscktraverse toutes les structures du système de fichiers, ce qui signifie principalement exécuter des E / S aléatoires. Le calcul ci-dessus, basé sur le taux de transfert séquentiel , n'est donc pas très utile.

— shodanshok

@shodanshok en effet, la structure du fichier n'est pas pertinente dans une vérification générale du lecteur, comme je viens de l'expliquer dans ma réponse.

— Overmind

@shodanshok mon hypothèse la plus défavorable était basée sur un fsck très étendu. Par exemple, le fsck xfs typique ne fait pas grand-chose. ext2 a une longue vérification approfondie et l'ancien scandisk MS-DOS avait un test de lecture-écriture sur chaque bloc de disque dur lors de son exécution en mode complet. Vous avez donc une limite supérieure à la taille du disque.

— allo

@Overmind Et votre réponse est sans rapport avec la question qui concerne fsck et non une vérification générale du lecteur.

— BlackJack

Veuillez noter que l'utilisation d'un débit de disque typique comme indicateur peut être trompeuse. J'ai fait le calcul lors de la resynchronisation d'une baie, ce qui aurait dû (à mon avis) prendre moins d'une journée, et cela a pris plus de deux semaines! Les recherches sont le seul facteur dominant pour le temps total et même lorsque vous pensez que vous effectuez une opération strictement séquentielle, ce n'est parfois pas le cas. Maintenant, fsck est strictement non séquentiel, donc ... vous ne pouvez pas juger du débit de disque habituel à la durée de l'opération (encore, les mois sont ridicules ... c'est un mensonge évident).

— Damon