메일링리스트 다 뒤져봤는데 드디어 완료됐네요우분투 btrfs
페이지,나는 느낀다btrfs
아직완전한 복구 유틸리티는 없습니다(위 그림 참조).홈페이지). 몇 달 전에 Oracle Linux의 기본값이 되었으며 많은 배포판에 포함되어 있습니다.
그렇다면 대안으로 문제 해결 방법에 대한 문제 해결 가이드가 있습니까 btrfs
?
실패하면 백업을 FS에 복사하면 문제가 해결됩니까? (공간이 필요하면 스냅샷을 삭제합니까? 아니면 손상된 파일을 삭제합니까?) 이전 스냅샷으로 되돌린 다음 백업에서 손실된 파일을 복구해야 합니까? 아니면 @ 및 @home 스냅샷에서 손실된 파일을 복구하시겠습니까?
노트: 이것은 일반적인 문제입니다. 현재로서는 정확한 FS 문제를 의도적으로 생략하고 있습니다. 일반/표준 작업 흐름 및 문제 해결 가이드를 찾고 싶습니다.
(알겠습니다. 자세한 내용은 여기에서 확인하세요 ;)):
종료 중에 전원이 꺼지므로 시스템이 불안정해집니다. 충분한 데이터가 기록되고 정지될 때까지 시스템이 잠시 시작되고 실행됩니다. 지난번에는 Thunderbird를 열었습니다. 더 많은 하드 리셋이 필요하고 더 많은 손상이 필요할 수 있습니다.
sudo btrfsck /dev/sda1
몇 가지 오류 사이에서 발생 - 일반적으로 양식에서 처음 발생
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
parent transid verify failed
오오, 이제 너무 맛있어 (그냥 여기서 보고 싶은데 ...)
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
(물론 모든 내용이 자세하게 요약되어 있습니다. 자세한 내용으로 여러분을 압도하고 싶지는 않습니다. :))
이제 마지막 실행을 통해 다음과 같은 친숙한 결과를 얻었습니다.
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.
, 끝에 선택적 무작위 오류가 포함됩니다. 행복해요. verify failed
데이터가 드라이브에 기록되면 이러한 내용이 변경됩니다 .
또 다른 무작위 오류:
btrfsck: disk-io.c:412: find_and_setup_root: Assertion `!(!root->node)' failed.
답변1
답변을 도와주세요:
상위 트랜ID 확인 실패 14265458688 구함 464230 발견 464221
이 문제는 다음을 통해 해결할 수 있습니다.
$ btrfs-zero-log DEVICE
노트:데이터가 손실될 수 있습니다! 먼저 설치해 보십시오:
$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT
"bad fs"와 같은 데이터를 마운트할 수 없는 경우:
$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO
이것은 제가 보낸 실제 이메일입니다. 비록 이해하기는 어렵지만, 그의 해결 방법을 명확히 하기 위한 것이었습니다. 이 신비한 설명을 이해하시기 바랍니다.
발췌이메일
Re: 질문: 이 파티션을 복구하는 방법은 무엇입니까? (논리적 $hugenum len 4096을 찾을 수 없습니다)
Hugo Mills carfax.org.uk> 님이 쓴 글:
2013년 8월 26일 월요일 오후 1시 10분 54초 -0600에 Chris Murphy가 다음과 같이 썼습니다.
2013년 8월 26일 오전 11시 41분, Nick Lee nickle.es>는 다음과 같이 썼습니다.
며칠 전 IRC에서 트리 루트의 블로코 문제가 디스크 자체의 문제일 수도 있고 블록 트리/논리 맵 문제로 인한 것일 수도 있다는 논의가 있었습니다. 블록 복구를 실행하고 발견된 오류를 확인한 후 쓰기를 누릅니다. (실패하면 사진 촬영을 좀 하게 될 것이고, 부작용으로 조직이 손실될 것입니다.)
원하시면 내일 비행기가 착륙한 후에 더 명확하게 글을 쓸 수 있습니다.
-o 복구, btrfsck, 청크 복구, 제로 로그 등 다양한 기술을 언제 사용해야 하는지 궁금합니다.
물리적 장치 오류가 없다고 가정합니다(다른 도구 세트 - mount -degraded, btrfs dev del 누락).
가장 먼저 해야 할 일은 파일 시스템 -c9 -t4의 btrfs 이미지를 얻고 josef를 표시하기 위한 출력 복사본을 보관하는 것입니다. :)
그런 다음 -orecovery 및 -oro,recovery를 시작하면 거의 모든 것을 복구할 수 있습니다.
이것이 실패하면 dmesg에서 로그 트리 관련 오류를 찾으십시오. 로그 트리가 손상되어 읽을 수 없거나 충돌을 일으키는 경우 btrfs-zero-log를 사용하십시오.
블록 트리에 문제가 있는 경우(최근에 "주소를 매핑할 수 없음"과 같은 보고서를 본 유일한 경우) 블록 복구가 유용할 수 있습니다.
그 후에는 btrfsck가 아마도 다음 시도일 것입니다. 옵션 -s1, -s2, -s3이 성공하면 btrfs-select-super는 슈퍼블록을 사용 가능한 슈퍼블록으로 대체하여 도움을 줍니다. 이것이 도움이 되지 않으면 btrfsck --repair로 돌아가십시오.
마지막으로 익스텐트 트리가 손상된 경우 btrfsck --repair --init-extent-tree가 필요할 수 있습니다. 마지막으로 체크섬이 손상된 경우 --init-csum-tree를 사용할 수 있습니다.
휴고.