내 하드 드라이브가 손상되어 읽기 오류가 많이 발생합니다. 현재 btrfs 교체를 수행 중이지만 24시간 후 완료율이 5%를 조금 넘었습니다. 문제는 다음과 같습니다. 이것은 내 업무용 컴퓨터입니다. 현재 Live USB로 부팅하지만 돌아가야 합니다. 기존 Ubuntu로 작업을 계속할 수 있습니다(모든 읽기 오류로 인해 부팅이 매우 어렵지만 때로는 성공함).
참고: 읽기 오류가 없음에도 불구하고 전체 하드 드라이브 또는 적어도 이 파티션은 현재 약 500KBps로 읽고 있습니다. btrfs replace status
현재 0개의 읽기 오류가 보고됩니다.
따라서 두 가지 옵션이 있습니다. 1) 종료하고 다른 OS로 재부팅한 다음 btrfs replace start
처음 실행했던 것과 동일한 명령을 실행해 봅니다. 2) 현재 교체 작업을 취소하는데 시간이 오래 걸릴 수 있으며(이전에 취소해본 적이 있고 교체 후 1분만에 취소하는데 시간이 오래 걸리는 것 같습니다) 하루 힘들게 벌어들인 이체 진행 상황이 취소됩니다. 3) 패배를 인정하고 앞으로 2~3주 동안 이 LiveUSB 운영 체제에 익숙해지며 청소 직원이 USB 스틱에 부딪히지 않도록 기도하십시오.
답변1
이 질문을 다시 묻는 이유는 "btrfs 교체 이력서"를 검색할 때 Google 검색 결과 상위에 나오고 기존 답변으로는 전체 내용을 알 수 없기 때문입니다.
재부팅 후 교체 프로세스가 자동으로 재개됩니다(저울과 유사). 교체 작업 중에 하드 리셋까지 해야 했고, 파일 시스템을 재부팅하고 다시 마운트한 후에도 프로세스가 원활하게 계속되었습니다. 따라서 내 생각에는 sssheridan에 대한 이러한 모든 문제를 일으키는 것은 중단된 교체 작업 자체가 아니라 죽은 하드 드라이브에서 부팅해야 하는 상황 때문인 것 같습니다.
교체를 중단한 후 설치하면 다음 로그 줄이 인쇄됩니다.
BTRFS info (device sdh1): continuing dev_replace from /dev/sdb1 (devid 5) to target /dev/sdh1 @95%
마지막 숫자는 완료율입니다.
답변2
내 질문에 대답하자면: 시도해 보았는데 모든 것이 불타올랐습니다. 입/출력 오류는 어디에나 있고 내 파일 시스템에서는 RAID1이라고 생각하지만 그렇지 않습니다. 공평하게 말하자면, 파티션이 손상되었고 그것이 문제의 일부인 것 같지만 그럼에도 불구하고 나는 그것을 권장하지 않습니다. 하나를 만들고 btrfs replace cancel
그것이 끝날 때까지 기다리십시오.
답변3
간단히 말해서:
예. 그러나 scrub
그는 도망갔습니다.
긴 버전:
이 LWN 기사커밋 텍스트를 제공 replace
하고 다음과 같이 말합니다.
작동 중에 충돌하거나 전원이 꺼지는 것이 안전하며 다음 설치 시 프로세스가 재개됩니다.
replace
약 5% 정도 완료된 상태에서 다시 시작했습니다 .디스크 결함으로 인해 RAID1의 btrfs 교체 속도가 매우 느림.
복원하고 완료한 후 합계만 표시되지 않고 일부 합계가 표시되는 replace
것을 확인했습니다 . 이는 실패한 드라이브에 두 번째 복사본을 쓸 수 없기 때문에 쓰기 때문일 수 있습니다 . 모든 것을 RAID1로 만들기 위해 재조정했습니다.btrfs device usage /mountpoint
Data,DUP
Metadata,single
RAID1
btrfs
DUP
btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /mountpoint
이제 모든 데이터가 표시되었으므로 RAID1
모든 것이 괜찮은지 확인하겠습니다.
btrfs scrub start -Bd /mountpoint
csum errors
(새로 교체된 장치)에서 ~151GiB를 많이 스크러빙했기 때문에 다행입니다 .id 2
scrub device /dev/mapper/vg4TBd3-ark (id 1) status
scrub started at Mon Jan 28 20:47:33 2019, running for 00:41:40
total bytes scrubbed: 153.53GiB with 0 errors
scrub device /dev/mapper/vg6TBd1-ark (id 2) status
scrub started at Mon Jan 28 20:47:33 2019, running for 00:41:40
total bytes scrubbed: 151.49GiB with 174840 errors
error details: csum=174840
corrected errors: 174837, uncorrectable errors: 0, unverified errors: 0
scrub
지금 크롤링 중입니다. 로그에는 다음과 같은 여러 줄이 표시됩니다.
BTRFS warning (device dm-5): checksum error at logical 3425803567104 on dev /dev/mapper/vg6TBd1-ark, physical 162136981504, root 5, inode 3367374, offset 0, length 4096, links 1 (path: HDDs/Quantum LM30/Linux1/home/tn/uts.old/etc/root/home/tn/build/linux-2.4.13-ac8/linux/include/net/sock.h)
BTRFS error (device dm-5): bdev /dev/mapper/vg6TBd1-ark errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
BTRFS error (device dm-5): fixed up error at logical 3425803567104 on dev /dev/mapper/vg6TBd1-ark
scrub_handle_errored_block: 806 callbacks suppressed
다음에 184GiB 스크럽을 확인했을 때 총 262016개의 수정된 오류가 있었습니다(이 시점에서 다시 행복하게 확장되었습니다).
그 이후에는 어떤 오류도 발생하지 않았습니다. 이는 모든 오류가 151GiB 지점 주위에 집중되었음을 의미합니다.
151GiB는 재부팅했을 때 전체 2.88TiB의 약 5%입니다.
어쩌면 우연이었을지도 모르지만, 어쨌든 달려서 기쁘다 scrub
.