Quanto tempo può impiegare fsck su un volume di 30 TB?

A metà novembre, un VPS che sto noleggiando da una società di hosting ha smesso di rispondere. Quando ho contattato l'assistenza, mi hanno spiegato che un'interruzione di corrente nel centro dati ha causato un riavvio forzato e fsck. Alla fine, ho chiesto perché ci voleva così tanto tempo e mi è stato detto che la dimensione del volume è di 30 TB. L'ultima volta che ho ricevuto un aggiornamento è stato a febbraio e non hanno risposto alla mia inchiesta più recente.

Capisco che fsck può essere molto lento per alcuni file system, ma è possibile che fsck impieghi 6 mesi su un volume di 30 TB, o dovrei supporre che questa società di hosting mi stia mentendo in modo da continuare a pagare la mia fattura ogni mese?

fsckla velocità dipende principalmente dal numero di file e da come sono distribuiti nella rispettiva directory. Detto questo, 6 mesi per a fsckè assolutamente assurdo: dovrebbe essere completato al massimo in alcune ore, soprattutto se l'utilizzo xfsha l' xfs_repairutilità rapida . Qui puoi trovare alcune fsckcorse su una scala - tutte completate in meno di un'ora (3600s). Quindi, non è possibile che tu fscksia ancora in esecuzione.

In ogni caso, una perdita di potenza imprevista non provocherà un vero e proprio replayfsck , piuttosto solo un replay del diario molto veloce (alcuni secondi) . Tuttavia, se alcuni file chiave sono stati danneggiati, il sistema operativo potrebbe non essere avviabile.

Ma probabilmente ti hanno appena mentito. Dovresti interrompere immediatamente il pagamento, chiedere una spiegazione e richiedere un rimborso totale.

Congettura: il loro sistema utilizza un RAID privo di BBU / FBWC (o anche RAID software) con tutte le possibili cache di scrittura (comprese queste nei dischi rigidi stessi) impostate alle impostazioni più aggressive, al fine di ottenere le massime prestazioni a costi minimi. Un'interruzione di corrente eccessiva in una tale configurazione può lasciare un filesystem journaling in una condizione in cui il journal non può essere considerato attendibile e non può essere utilizzato per il ripristino. Il problema è che un tale sistema riordina e posticipa in modo aggressivo le scritture, il che significa che una voce di diario può essere scritta con l'effetto dell'azione di dati persi ... o la voce di diario persa su un'azione di dati che era consequenziale.

Il ripristino di un tale sistema da un'interruzione del caso peggiore può significare che devi fare un fsck / riparazione "lento" che esamina effettivamente tutte le strutture del filesystem così come sono, il che potrebbe effettivamente richiedere un giorno o due per 30 TB .... non è improbabile che dovrai eseguire più cicli di riparazione. Aggiungete a ciò che il personale potrebbe non essere sempre disponibile per monitorare questo, si potrebbe facilmente essere fino a un fsck fatto a settimana. Probabilmente hanno rinunciato e dimenticato.

Per la maggior parte dei filesystem sarà molto più veloce, anche quando ci sono errori, poiché normalmente vengono controllati solo i metadati.

Nel peggiore dei casi, potrebbe leggere l'intero disco ( ad esempio qualcosa di simile fsck.ext4 -cc /dev/sda, che esegue un test di scrittura non distruttivo su ogni blocco), che potrebbe richiedere alcuni giorni per 30 TB. Se conosci la velocità delle unità, puoi calcolare dimensioni / velocità . Per un disco rigido consumer con una copia di circa 100 MB / s, alcune TB possono richiedere più ore di quanto la maggior parte delle persone si aspetti.

Se fosse il tuo server, potresti avere il problema che si avvia e poi si blocca quando fsckti chiede se vuoi correggere un errore. Ma l'amministratore del datacenter non lascerà l' fsckimpiccagione per 6 mesi mentre tutti i VPS sono offline.

Quindi ti stanno mentendo o c'è un grande fraintendimento. Oppure stavano eseguendo fsck qualche tempo fa e non ti hanno aggiornato sul nuovo problema al termine.