.png)
한 시간 안에 4~5번 연속 불규칙 정전이 발생했습니다. 내 우분투가 갑자기 사용 중 모드로 들어가고 /dev/sda5에 오류가 있다고 말합니다.
그런 다음 다음을 시도합니다.
fsck /dev/sda5 -y
1시간 넘게 걸렸고 강제로 다시 작성했습니다. 많은 동네가 복원되고 있는 것 같습니다.
누군가 무슨 일이 일어나고 있는지 설명하거나 수정 사항을 제안할 수 있습니까?
답변1
아아, 아마도 일어난 일은 머리가 하드 드라이브에 부딪혔다는 것입니다.
최선의 선택은 아마도 /dev/sda를 완전히 바꾸는 것입니다. 오류는 sda5에만 국한되지 않고 모든 파티션에 영향을 미칠 수 있습니다.
(최근 5TB 드라이브에서 이런 일이 일어났습니다. 고통스럽습니다.)
내 경험상 "다시 쓰기" 옵션은 도움이 되지 않습니다. 거부하면 fsck가 종료됩니다. 모든 파티션을 읽기 전용으로 마운트하고 데이터를 다른 미디어(즉, 새 드라이브를 구입하는 것이 좋습니다)에 복사하는 것이 좋습니다.
e2fsck"불량 블록 검사 " 옵션을 사용할 수 있습니다 -c. 반면에 최신 하드 드라이브에서는 필요하지 않습니다.
답변2
짧은 대답은 다음과 같습니다. fsck드라이브가 갑자기 종료되거나 다시 시작되거나 연결이 끊어진 후에는 항상 실행하십시오. 원인심각한파일 시스템 구조의 손상은 약간 손상된 후에도 계속 사용됩니다.
답변이 길어요...
그 자체로 "오랜 시간"이 반드시 드라이브의 물리적 문제를 나타내는 것은 아닙니다.
하지만 정확히 무엇을 의미하는지에 따라 그럴 수도 있습니다.많은 동네가 복원되고 있습니다:읽을 수 없는 블록을 다시 매핑하면 잠재적인 드라이브 오류를 나타내지만 여러 파일에 교차 연결된 블록은 파일 시스템의 논리적 오류일 뿐입니다. (상당한 데이터 손실이 있지만 드라이브를 폐기할 정도는 아닙니다.)
나는 최근에 오래된 컴퓨터에서 USB-2를 통해 연결된 5TiB 드라이브를 실행해야 했고 fsck심지어아니요섹터 오류, 여전히 오랜 시간이 걸렸습니다.
나는 이것이 strace왜 그렇게 느린지 알아보기 위해 달려갔고 fsck.ext4대답은 분명했습니다. pread각 4KiB 블록에 대해 별도의 시스템 호출을 발행합니다. 실제로 사용 중인 각 10M inode에 대해 하나의 시스템 호출을 발행합니다.
한 시간 넘게 기다린 끝에 잠자리에 들었고 다음날 아침에 일어나서 시작한 지 1~9시간 사이에 성공적으로 완료했습니다.
내 경우에는 (a) 최근에 하드 재부팅이 있었고, (b) 보고된 유일한 오류는 사용 가능한 inode 및 사용 가능한 블록 수가 예상보다 적다는 것이었고, (c) 이후에는 드라이브 문제가 아니라고 생각합니다. 재부팅, 중복된 파일을 병합했습니다. 기본적으로는 여러 항목을 삭제하고 기존 디렉터리 항목을 변경하는 것뿐입니다.
다행히도 나는 새로운 것을 작성하지 않기 때문에 상호 연결된 파일이 없습니다.