Berapa lama fsck dapat mencapai volume 30 TB?


17

Pada pertengahan November, VPS yang saya sewa dari perusahaan hosting berhenti merespons. Ketika saya menghubungi dukungan, mereka menjelaskan bahwa pemadaman listrik di pusat data menyebabkan reboot dan fsck secara paksa. Akhirnya, saya bertanya mengapa butuh waktu lama, dan diberi tahu bahwa ukuran volumenya 30 TB. Terakhir kali saya menerima pembaruan adalah pada bulan Februari, dan mereka belum menanggapi pertanyaan terbaru saya.

Saya mengerti bahwa fsck bisa sangat lambat untuk beberapa sistem file, tetapi apakah mungkin bagi fsck untuk mengambil 6 bulan pada volume 30 TB, atau haruskah saya berasumsi bahwa perusahaan hosting ini berbohong kepada saya sehingga saya terus membayar tagihan saya setiap bulan?


39
Mereka mungkin berbohong padamu sejak awal. Saya berharap itu akan memakan waktu berjam - jam . Anda seharusnya berhenti membayar pada bulan Desember.
Michael Hampton

15
Bahkan jika mereka tidak bohong, memilih setup perangkat lunak HW + yang bisa memerlukan FSCK yang lama menunjukkan mereka tidak kompeten. Dan apa pun alasannya, mereka tidak menyediakan layanan yang Anda bayar.
Peter Cordes

34
Kedengarannya seperti cluster nyata fsck!
JMK

2
@JMK Sekarang saya berharap ada cara untuk menandai komentar untuk kelebihan tambahan, mungkin menambahkan ke hall-of-fame.
pipa

2
Apa yang dikatakan @PeterCordes adalah titik kunci. Anda membayar layanan. Anda benar-benar menyesal mendengar bahwa mereka mengalami masalah tetapi Anda menelepon tentang layanan yang Anda bayar dan tidak terima.
Rob Moir

Jawaban:


31

fsckkecepatan terutama tergantung pada jumlah file dan bagaimana mereka tersebar di direktori masing-masing. Yang mengatakan, 6 bulan untuk fsckbenar-benar tidak masuk akal: itu harus diselesaikan dalam beberapa jam paling banyak, terutama jika menggunakan xfsyang memiliki xfs_repairutilitas cepat . Di sini Anda dapat menemukan beberapa fscklari dalam skala - semua selesai di bawah satu jam (3600-an). Jadi, tidak mungkin Anda fsckmasih berjalan.

Bagaimanapun, kehilangan daya yang tidak terduga tidak akan menyebabkan pukulan penuh fsck, melainkan hanya replay jurnal yang sangat cepat (beberapa detik) . Namun, jika beberapa file kunci rusak, OS dapat di-boot.

Tapi mereka mungkin berbohong padamu. Anda harus segera berhenti membayar, meminta penjelasan, dan mengajukan permohonan pengembalian uang total.


8
Jika mereka menggunakan ext2, maka kegagalan daya akan membutuhkan penuh fsck, dan saya tidak akan terkejut jika butuh berhari-hari pada volume 30TB yang banyak digunakan. Di sisi lain, jika mereka menggunakan ext2volume 30TB, itu dengan sendirinya adalah alasan untuk mencari tempat lain untuk layanan hosting.
Tandai

14
ext2 menggunakan penghitung blok 32-bit, dengan ukuran blok maksimum 4096 byte (yaitu: halaman) pada x86 dan x86_64. Ini berarti ext2 (dan ext3) terbatas pada volume 8TB jadi tidak, OP tidak dapat menggunakan ext2 / 3. Lagi pula, menggunakan sistem file non-jurnal pada volume 30 TB akan benar-benar gila .
shodanshok

Saya pikir ext4 fsck mungkin sedikit lebih baik jika seseorang memiliki 30TB FS yang berisi banyak file kecil. Gila untuk menciptakan itu, jadi masih alasan untuk mencari di tempat lain.
nigel222

7

Dugaan: Sistem mereka menggunakan RAID yang tidak menggunakan BBU / FBWC (atau bahkan RAID perangkat lunak) dengan semua cache tulis yang mungkin (termasuk hard disk itu sendiri) yang disetel pada pengaturan paling agresif, untuk mendapatkan kinerja maksimum dengan biaya minimal. Pemadaman listrik yang keras pada pengaturan seperti itu dapat meninggalkan sistem file jurnal dalam kondisi di mana jurnal tidak dapat dipercaya dan tidak dapat digunakan untuk pemulihan. Masalahnya adalah bahwa sistem seperti itu secara agresif menata ulang dan menunda menulis, yang berarti bahwa entri jurnal dapat ditulis dengan efek dari tindakan data yang hilang ... atau entri jurnal yang hilang pada tindakan data yang konsekuensial.

Memulihkan sistem seperti itu dari pemadaman kasus terburuk dapat berarti bahwa Anda harus melakukan fsck / perbaikan "lambat" yang benar-benar memeriksa semua struktur sistem file seperti apa adanya, yang memang bisa memakan waktu satu atau dua hari untuk 30TB .... dan itu bukan tidak mungkin Anda harus menjalankan beberapa siklus perbaikan. Tambahkan ke bahwa personil mungkin tidak selalu tersedia untuk memantau ini, Anda dapat dengan mudah turun ke satu fsck yang dilakukan per minggu. Mereka mungkin menyerah dan lupa.


1

Untuk sebagian besar sistem file akan jauh lebih cepat, bahkan ketika ada kesalahan, seperti biasanya hanya metadata yang diperiksa.

Dalam kasus terburuk, mungkin membaca seluruh disk, ( misalnya sesuatu seperti fsck.ext4 -cc /dev/sda, yang melakukan tes tulis non-destruktif pada setiap blok), yang bisa memakan waktu beberapa hari untuk 30 TB. Jika Anda mengetahui kecepatan drive, Anda dapat menghitung ukuran / kecepatan . Untuk hard drive konsumen dengan menyalin sekitar 100 MB / s, beberapa TB dapat memakan waktu lebih lama daripada yang diperkirakan kebanyakan orang.

Jika itu adalah server Anda, Anda bisa mendapatkan masalah saat boot kemudian hang ketika fsckmenanyakan apakah Anda ingin memperbaiki kesalahan. Tetapi admin pusat data tidak akan membiarkan fsckselama 6 bulan sementara semua VPS sedang offline.

Jadi mereka berbohong kepada Anda, atau ada kesalahpahaman besar. Atau mereka menjalankan fsck beberapa waktu lalu dan tidak memperbarui Anda tentang masalah baru setelah selesai.


4
fsckmelintasi semua struktur sistem file, yang sebagian besar berarti menjalankan i / o acak. Jadi perhitungan di atas, berdasarkan laju transfer sekuensial , tidak terlalu berguna.
shodanshok

@shodanshok memang struktur file tidak relevan dalam pemeriksaan drive umum, karena saya baru saja menjelaskan dalam jawaban saya.
Overmind

@shodanshok asumsi terburuk saya didasarkan pada fsck yang sangat luas. Sebagai contoh fsck xfs khas tidak banyak membantu. ext2 memiliki pemeriksaan ekstensif yang berjalan lama dan scandisk MS-DOS tua memiliki tes baca-tulis pada setiap blok hard drive saat menjalankannya dalam mode penuh. Jadi Anda memiliki batas atas pada ukuran disk.
allo

1
@ Overmind Dan jawaban Anda tidak relevan dengan pertanyaan yaitu tentang fsck dan bukan pemeriksaan drive umum.
BlackJack

Perlu diketahui bahwa mengambil throughput disk biasa sebagai indikator dapat menyesatkan. Saya telah melakukan perhitungan ketika menyinkronkan kembali array, yang seharusnya (menurut saya) perlu waktu kurang dari sehari, dan butuh lebih dari dua minggu! Mencari adalah satu-satunya faktor yang mendominasi untuk total waktu dan bahkan ketika Anda berpikir bahwa Anda melakukan operasi sekuensial ketat, kadang-kadang bukan satu. Sekarang fsck benar-benar tidak berurutan, jadi ... tidak mungkin Anda menilai dari throughput disk yang biasa dengan panjang operasi (masih, berbulan - bulan konyol ... itu kebohongan yang jelas).
Damon
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.