Bagaimana cara memperbaiki btrfs? [Tutup]


9

Saya telah menjaring milis dan akhirnya selesai di halaman Ubuntubtrfs , dan saya merasa btrfs masih belum memiliki utilitas perbaikan penuh (seperti yang ditunjukkan pada halaman beranda mereka ). Meskipun berbulan-bulan yang lalu itu dijadwalkan sebagai default untuk Oracle Linux dan termasuk dalam banyak distro.

Jadi, sebagai pengganti itu, apakah ada panduan pemecahan masalah di suatu tempat tentang cara memperbaikinya btrfs?

Gagal, akankah menyalin cadangan saya di atas FS saya memperbaiki keadaan? (Saat menghapus snapshot jika perlu untuk ruang? Atau menghapus korupsi?) Haruskah saya mencoba mengembalikan ke snapshot sebelumnya dan kemudian mengembalikan file yang hilang dari cadangan? Atau mengembalikan file yang hilang dari snapshot @ dan @ rumah saya?

Catatan : Ini adalah pertanyaan umum. Saya sengaja menghilangkan masalah FS saya yang sebenarnya (untuk saat ini); Saya ingin menemukan alur kerja umum / kanonik dan panduan pemecahan masalah.

(Ok, ok - inilah beberapa lebih detail;)) :

Saya dimatikan selama shutdown yang digantung, dan telah disajikan dengan ketidakstabilan sistem karenanya. Sistem akan boot dan berjalan selama beberapa waktu sampai ia menulis data yang cukup dan membeku. Terakhir kali saya membuka Thunderbird. Ini membutuhkan pengaturan ulang yang lebih keras dan mungkin lebih banyak korupsi. sudo btrfsck /dev/sda1berosilasi di antara beberapa kesalahan - sering kali pertama kali dari formulir

root 338 inode 7861227 errors 1000
root 338 inode 7904568 errors 1000
root 338 inode 7955174 errors 400
found 46242054144 bytes used err is 1
total csum bytes: 43112400
total tree bytes: 2074640384
total fs tree bytes: 1889853440
btree space waste bytes: 547680627
file data blocks allocated: 110756974592
 referenced 68393684992
Btrfs Btrfs v0.19

oooo, sekarang getty benar-benar buah (saya hanya berharap untuk melihat di parent transid verify failedsini ...)

parent transid verify failed on 14266105856 wanted 464223 found 464221
parent transid verify failed on 14266105856 wanted 464223 found 464221
Extent back ref already exists for 14261530624 parent 0 root 256 
leaf parent key incorrect 14261751808
bad block 14261751808
Extent back ref already exists for 66455355392 parent 0 root 2 
Extent back ref already exists for 66455257088 parent 0 root 2 
Extent back ref already exists for 14257274880 parent 0 root 2 
block 14262571008 rec extent_item_refs 2, passed 2
block 14262575104 rec extent_item_refs 1, passed 1
block 14262579200 rec extent_item_refs 1, passed 1
Extent back ref already exists for 14262579200 parent 0 root 257 
leaf 14263906304 items 50 free space 132 generation 464224 owner 2
fs uuid 7d049403-cf6e-4b52-a624-32051e1f5b2a
chunk uuid be6f8f93-320c-4465-85d6-f53907698c32
item 0 key (14263341056 EXTENT_ITEM 4096) itemoff 3944 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332576 1 0) level 0
    tree block backref root 257
item 1 key (14263345152 EXTENT_ITEM 4096) itemoff 3893 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332586 c 8332543) level 0
    tree block backref root 257
failed to find block number 14263525376

(Semua sangat diringkas tentu saja; Saya tidak pernah ingin membanjiri Anda dengan rincian ini :))

Dan sekarang eksekusi terakhir saya membuat saya akrab:

parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464223
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] == 0)' failed.

, termasuk kesalahan acak opsional di akhir. Oh, senang. Perhatikan bahwa ini verify failedberubah saat data ditulis ke drive.

Kesalahan acak lainnya:

btrfsck: disk-io.c:412: find_and_setup_root: Assertion `!(!root->node)' failed.

2
Ini sepertinya terlalu terbuka. Posting masalah Anda yang sebenarnya. Kebingungan itu tidak membantu siapa pun.
Chris Down

Saya memutuskan untuk mencobanya baru-baru ini dan menggunakannya pada root untuk sistem baru. Macine mendapat hard reset (jangan tanya) dan tidak pernah kembali sepenuhnya. Saat itulah saya mengetahui bahwa fsck untuk btrfs tidak lengkap! wow, saya tidak percaya itu adalah pilihan untuk filesystem root, sekeren mungkin
barrymac

Saya telah berhasil menggunakan milik saya selama sekitar 7 bulan sekarang. Saya pikir pasti sudah dekat dengan memiliki fsck yang tepat pada saat saya benar-benar memukul masalah ini (yang tak terhindarkan mengingat cara saya "bereksperimen" ...)
Stephen

1
Oh ayolah. Itu terlalu jauh untuk menyamakan "masalah" dengan beberapa aktivitas (baik di linux, btrfs, atau aksi eksternal a-la power cut) yang mengarah ke korupsi? Apa masalah berarti lainnya yang akan ditemui pengguna yang malang ketika berhadapan dengan sistem file? Ya, bukan 100% pilihan kata terbaik, tetapi menjamin komentar dengan kata "tanpa" itu tidak. Hanya ingat bahwa linux menjadi lebih umum (seperti halnya btrfs), dan akan ada pemula di sekitar (yang bukan saya). Jadi mari kita pergi dengan "@ ChrisDown Jadi saya menduga bahwa tidak ada panduan pemecahan masalah yang masuk akal untuk btrfs"
Stephen

1
Jika Anda menginginkan panduan pemecahan masalah, itulah yang harus Anda minta (itu tidak kabur). Meminta panduan berdasarkan apakah pengguna yang malang akan menggunakan kata-kata seperti itu sepertinya cara yang buruk untuk mengajukan pertanyaan ...
Chris Down

Jawaban:


6

Untuk membantu menjawab:

verifikasi transid induk gagal pada 14265458688 ingin 464230 ditemukan 464221

Dapat diperbaiki dengan:

$ btrfs-zero-log DEVICE

CATATAN: data bisa hilang! Coba dan pasang pertama kali dengan:

$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT

Jika tidak bisa memasang data seperti itu mengatakan "bad fs":

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

Berikut ini adalah email nyata, meskipun sulit untuk diikuti, yang saya kirim untuk mengklarifikasi solusinya. Semoga Anda bisa melihat penjelasan samar ini:

kutipan email

Re: Pertanyaan: Bagaimana saya bisa memulihkan partisi ini? (tidak dapat menemukan logis $ hugenum len 4096)

Hugo Mills carfax.org.uk> menulis:

On Mon, 26 Agustus 2013 pukul 01:10:54 PM -0600, Chris Murphy menulis:

Pada 26 Agustus 2013, pukul 11:41, Nick Lee nickle.es> menulis:

Ada diskusi di IRC beberapa hari yang lalu bahwa masalah dengan bloco root pohon kemungkinan merupakan hasil dari masalah dengan disk itu sendiri, atau chunk tree / pemetaan logis. Saya menjalankan pemulihan, melihat kesalahan yang ditemukan, dan menekan tombol tulis. (Jika gagal, saya akan menjalankan sesuatu photorec, kehilangan organisasi sebagai efek samping.)

Saya bisa menulis sesuatu yang lebih jelas setelah penerbangan saya besok jika Anda mau.

Saya hanya ingin tahu tentang kapan harus menggunakan berbagai teknik: -o recovery, btrfsck, chunk-recover, zero log.

Mari kita asumsikan bahwa Anda tidak memiliki kegagalan perangkat fisik (yang merupakan seperangkat alat yang berbeda - mount -odegraded, btrfs dev del missing).

Hal pertama yang harus dilakukan adalah mengambil btrfs-image -c9 -t4 dari filesystem, dan menyimpan salinan output untuk menampilkan josef. :)

Kemudian mulailah dengan -orecovery dan -oro, pemulihan untuk hampir semua hal.

Jika itu gagal, maka cari di dmesg untuk kesalahan yang berkaitan dengan pohon log - jika itu rusak dan tidak dapat dibaca (atau menyebabkan crash), gunakan btrfs-zero-log.

Jika ada masalah dengan chunk tree - satu-satunya yang saya lihat baru-baru ini melaporkan sesuatu seperti "tidak bisa memetakan alamat" - maka chunk-recover mungkin berguna.

Setelah itu, btrfsck mungkin adalah hal berikutnya yang harus dicoba. Jika opsi -s1, -s2, -s3 berhasil, maka btrfs-select-super akan membantu dengan mengganti superblok dengan yang berfungsi. Jika itu tidak akan berguna, kembali ke btrfsck - perbaiki.

Akhirnya, btrfsck --perbaikan --init-pohon-tingkat mungkin diperlukan jika ada pohon tingkat rusak. Akhirnya, jika Anda mendapatkan korupsi di checksum, ada --init-csum-tree.

Hugo.


Juga masalah transid terjadi ketika ada TRANSAKSI (tulis atau hapus) yang terjadi ketika unit mati tiba-tiba. Ini akan mengharapkan nilai tertentu kembali pada boot tetapi jika TRANSAKSI itu tidak bisa ditulis ke disk (tetapi hanya untuk login, yang juga kadang-kadang ada di disk) maka kesalahan ini akan terjadi. Perhatikan bagaimana ini diharapkan 464230 tetapi mendapat yang lebih tua 464221 seperti 9 transaksi yang lalu .. 9 banyak sehingga Anda mungkin memiliki kehilangan data (atau jika penghapusan adalah trasnsation mungkin memiliki lebih banyak data) .. Saya mungkin merasa aman jika hanya 1 atau 2 off .
kossboss

Saya harus memberi hadiah karena memberikan jawaban, walaupun saya tidak tahu apakah itu valid - Saya sudah sejak pindah dari btrfs, karena saya memiliki kebutuhan sederhana (keandalan, dan harus mampu menjejalkan sebanyak mungkin media pada disk)
Stephen
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.