[過去ログ] くだらねえ質問はここに書き込め!Part 246 (1002レス)
前次1-
抽出解除 必死チェッカー(本家) (べ) レス栞 あぼーん

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
469: 2021/12/17(金) 17:31:22 ID:WDpFyAGb(1/15)調 AAS
2つHDD接続してます

# btrfs filesystem show
Label: 'debian' uuid: cf82c300-5af6-45d6-a682-1e93b9105cae
Total devices 1 FS bytes used 25.51GiB
devid 1 size 295.90GiB used 39.07GiB path /dev/sda2

Label: 'debian' uuid: 3a396f2a-5ad7-47af-9bbd-343195f050f2
Total devices 1 FS bytes used 21.17GiB
devid 1 size 146.84GiB used 25.07GiB path /dev/sdb2

以下のごとくsdb2のみ エラーが出て起動できません。直近に当該ディスクドライブが、ゴロンゴロンまともにスピンしませんでした。げんざいは綺麗にスピンしてます。

# dmesg
BTRFS errorのみ

[ 6576.245236] BTRFS error (device sdb2): parent transid verify failed on 577110016 wanted 1415 found 1373
[ 6576.252368] BTRFS info (device sdb2): no csum found for inode 217067 start 0
[ 6576.264856] BTRFS warning (device sdb2): csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1
[ 6576.281548] BTRFS error (device sdb2): parent transid verify failed on 577093632 wanted 1415 found 1373
[ 6584.082394] BTRFS error (device sdb2): parent transid verify failed on 577110016 wanted 1415 found 1373
[ 6584.082408] BTRFS info (device sdb2): no csum found for inode 217067 start 0
[ 6584.095117] BTRFS warning (device sdb2): csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1
471: 2021/12/17(金) 18:00:28 ID:WDpFyAGb(2/15)調 AAS
見やすくするために
[ 6584.082394] BTRFS error (device sdb2):
等の文字列をのぞいきました

parent transid verify failed on 577110016 wanted 1415 found 1373

no csum found for inode 217067 start 0

csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1

parent transid verify failed on 577093632 wanted 1415 found 1373

parent transid verify failed on 577110016 wanted 1415 found 1373

no csum found for inode 217067 start 0

csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1
472: 2021/12/17(金) 18:03:35 ID:WDpFyAGb(3/15)調 AAS
なおすでに
# btrfs rescue zero-log /dev/sdb2
を実行。
参考
外部リンク[md]:github.com

これをする前はマウントすらできませんでした。
473: 2021/12/17(金) 18:07:26 ID:WDpFyAGb(4/15)調 AAS
>
"chunk tree"という文字列を含むメッセージが出力されている。
どのデバイスにどのデータを配置するかという情報が入っているchunk treeというメタデータが壊れている可能性があります。次のコマンドによって、ファイルシステムをスキャンしてchunk treeを復元できます。

# btrfs rescue chunk-recover /dev/sdb2

"chunk tree"という文字列を含むメッセージが出力されてませんが、実行。

# btrfs rescue chunk-recover /dev/sdb2
ERROR: the device is busy
474: 2021/12/17(金) 18:17:43 ID:WDpFyAGb(5/15)調 AAS
大段
■mountできなくなった

<<(我)もうすでにマウントはできてるのですが...

中の
□mountに必要なメタデータの復元

これ以降の操作はmountできなくなったBtrfsファイルシステムを構成するストレージの内容を変更します

中の
-----------------------------------------
それ以外のメッセージが出ている、あるいはとくにメッセージが残っていない

大きく分けて次の2つの可能性が考えられます。

スーパーブロック(後述)が壊れている
root tree(後述)が壊れている
-----------------------------------------

第一にスーパーブロックが壊れている場合です。スーパーブロックとは、mountしようとしたストレージがBtrfsに属していることを示すと共に、各種管理情報を保持しているメタデータです。このデータにはバックアップされていますので、スーパーブロックが壊れている場合は次のコマンドによって復元できます。
# btrfs rescue super-recover /dev/sdb2
ERROR: the device is busy
475: 2021/12/17(金) 18:23:19 ID:WDpFyAGb(6/15)調 AA×

476: 2021/12/17(金) 18:31:24 ID:WDpFyAGb(7/15)調 AAS
ファイルシステムの復元(最終手段)
# btrfs check --repair /dev/sdb2
このコマンドは矛盾のあるデータは容赦無く削除するなどして無理矢理にでもmountできるようにするためのものであり、かつ、必ずしも成功するとは限りません。このため、他に打つ手がまったく無くなったときの最後の手段として使用してください

# btrfs check --repair /dev/sdb2
enabling repair mode
WARNING:
Do not use --repair unless you are advised to do so by a developer
or an experienced user, and then only after having accepted that no
fsck can successfully repair all types of filesystem corruption. Eg.
some software or hardware bugs can fatally damage a volume.
The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
ERROR: /dev/sdb2 is currently mounted, use --force if you really intend to check the filesystem
#
<< マウントしてない状態でやるのか
477: 2021/12/17(金) 18:31:28 ID:WDpFyAGb(8/15)調 AAS
# btrfs check --repair /dev/sdb2
enabling repair mode
WARNING:

Do not use --repair unless you are advised to do so by a developer
or an experienced user, and then only after having accepted that no
fsck can successfully repair all types of filesystem corruption. Eg.
some software or hardware bugs can fatally damage a volume.
The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/sdb2
UUID: 3a396f2a-5ad7-47af-9bbd-343195f050f2
[1/7] checking root items
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=578355200 item=136 parent level=1 child bytenr=579682304 child level=1
ERROR: failed to repair root items: Input/output error
#
478: 2021/12/17(金) 18:36:00 ID:WDpFyAGb(9/15)調 AAS
警告
開発者からアドバイスがない限り、--repair は使用しないでください。
ということを理解した上で、そのうえで行ってください。
fsck はあらゆる種類のファイルシステムの破損を正常に修復することができます。例えば
いくつかのソフトウェアやハードウェアのバグは、ボリュームに致命的な損傷を与える可能性があります。

[1/7] ルートアイテムのチェック
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
トランシッドの失敗を無視する
ERROR: 子ebが破損: 親 bytenr=578355200 item=136 親レベル=1 子 bytenr=579682304 子レベル=1
ERROR: ルートアイテムの修復に失敗しました。入出力エラー
#

<<以上機械翻訳

# btrfs rescue super-recover /dev/sdb2

ERROR: the device is busy  <<先に実行したコマンドでこの意味がわからなかったが、

<< マウントしてない状態でやるのか  ということでは?

もう一度やり直し
480: 2021/12/17(金) 21:38:04 ID:WDpFyAGb(10/15)調 AAS
"chunk tree"という文字列を含むメッセージが出力されている。
どのデバイスにどのデータを配置するかという情報が入っているchunk treeというメタデータが壊れている可能性があります。次のコマンドによって、ファイルシステムをスキャンしてchunk treeを復元できます。

# btrfs rescue chunk-recover /dev/sdb2
このコマンドはストレージプールのすべてを走査するため、非常に時間がかかる恐れがあります。

----------------
# btrfs rescue chunk-recover /dev/sdb2
Scanning: 104862273536 in dev0

すごい長い時間かかてる、、、
482: 2021/12/17(金) 22:00:46 ID:WDpFyAGb(11/15)調 AAS
# btrfs rescue chunk-recover /dev/sdb2
Scanning: DONE in dev0

We are going to rebuild the chunk tree on disk, it might destroy the old metadata on the disk, Are you sure? [y/N]: y
Chunk tree recovery aborted
#
おわた
dmesg どうなった?

# dmesg | tail
[11570.040916] usb 6-3: Product: WN-G300UA
[11570.040920] usb 6-3: Manufacturer: I-O DATA DEVICE, INC.
[11570.040923] usb 6-3: SerialNumber: 00e04c000001
[11570.857132] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11570.884652] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11571.107981] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11571.163660] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11572.726292] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[14120.958897] sysctl (11524): drop_caches: 3
[14143.358555] Adding 2097148k swap on /dev/sda3. Priority:-2 extents:1 across:2097148k FS
#

消えた、btrfs 関連エラー??
ひとつだけになった?
[10621.063512] BTRFS error (device sdb2): Remounting read-write after error is not allowed
483: 2021/12/17(金) 22:18:17 ID:WDpFyAGb(12/15)調 AAS
だめだなー。起動できない。initramfs みたいな
さっきの日本語参考ページの元ネタってぽい英語ページにしたがってやってゆこうか
外部リンク:ownyourbits.com

>Be prepared
準備して
Rule zero is of course to have backups.
もちろん、ルールゼロはバックアップをとることです。
This will allow us to sleep well at night and handle a bad drive situation with a much cooler head.
これにより、私たちは夜よく眠り、はるかに涼しい頭で悪いドライブ状況に対処することができます。
I can’t stress this enough: have at least three copies in two different locations.
これを十分に強調することはできません。2つの異なる場所に少なくとも3つのコピーがあります。
Everything will be easier and less stressful when a drive fails, which will happen.
ドライブに障害が発生した場合、すべてが簡単になり、ストレスが軽減されます。

<< sdb の中にあるスナップショットはバックアップになんないのか?

また、このsda中のスナップショットでは、ファイルシステムを復元できないのか1
484: 2021/12/17(金) 22:19:55 ID:WDpFyAGb(13/15)調 AAS
Then, rule number one is to monitor your hard drive’s health.
次に、ルール1は、ハードドライブの状態を監視することです。
This is also critical because normally you will get the warning at least 24 or 48 hours before total failure so you have a good chance of getting your data out of there before it is too late.
通常、完全な障害が発生する少なくとも24時間または48時間前に警告が表示されるため、手遅れになる前にデータを取得できる可能性が高いため、これも重要です。

Hard drives don’t completely fail from one day to the other but we need to pay attention to them.
ハードドライブは、ある日から別の日に完全に故障するわけではありません

--------------------
とりあえずスマート有効にして、値を見てみるところからはじめる
485: 2021/12/17(金) 22:28:05 ID:WDpFyAGb(14/15)調 AAS
問題ディスク
ST3160815AS (3.AAC)
であるが、

890 個の不良セクターがありますが、使用可能です (35 °C / 95 °F)

<<以前と同じメッセージ

リアロケーティッドセクタカウント
カレントペンディングセクタカウント
アンコレクタブルセクタカウント   等の重要な値も以前といっしょ

エアフロー温度だけ 赤字で「過去に失敗した」と出ている
486: 2021/12/17(金) 22:47:38 ID:WDpFyAGb(15/15)調 AAS
これらの参考ページはすべて

Procedure if the drive can be mounted
ドライブをマウントできるかどうかの手順

であって、俺の環境はすでにマウントできてる

だからぜんぜん別の修復方法がありそうなものだ

> 復元したい日付のディレクトリへ入り、
$ cd /media/ユーザ/debian/timeshift-btrfs/snapshots/2021-12-13_16-08-21

これじゃダメなのか?(じつはもうやった、リードオンリーと出てできない)
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ

ぬこの手 ぬこTOP 1.348s*