를 사용하여 일부 데이터(200GB 홈 디렉터리)를 백업하는 동안 rsync특정 파일에 대해 I/0 오류가 발생했습니다.재동기화백업을 "정상적으로" 계속했습니다. 문제 소스 파일의 파일 크기는 72바이트로 나타났습니다.
취소했습니다 재동기화, 동일한 명령을 다시 실행했습니다. 이번에는 동일한 파일이 데이터를 전송하는 것으로 나타났습니다..많은 데이터...그리고 더 많은 데이터, 그리고 더... 대상 파일의 크기를 확인해보니 최대 13GB였습니다! 그래서 Ctrl-c를 사용하여 취소했습니다.재동기화.
60.0 PB소스 파일 크기를 다시 확인해보니 Nautilus에서 500GB 드라이브에서 (Peta Bytes!) 크기가 표시되었습니다 .
이제 이 모든 것의 주요 요점은 다음과 같습니다. 이 파일을 삭제하면 다른 파일의 데이터가 손실될 수 있으며, 파일 시스템이 해당 파일을 실제보다 훨씬 더 크게 인식할 수 있다는 점을 알 수 있습니다. 파일 시스템은 ext4..
그냥 건너뛸 수도 있었는데재동기화예외가 있지만 삭제되면 어떤 일이 발생할 수 있는지에 특히 관심이 있습니다.
업데이트: 대상과 소스가 모두ext4
희소 파일이라는 제안과 관련하여: 희소 파일인 경우 왜 1분마다 크기가 다르게 표시됩니까? 당시에는 확실히(?) 사용되지 않았던 파일이었습니다. 파일 입니다 ~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.sol.많은더 그런.솔해당 디렉토리에 있는 파일들.. 게다가 첫 번째 패스에서는 I/0 오류가 표시되었습니다.
또한 에 따르면 man rsync제안된 -S옵션은 희소 파일을 처리하는 것입니다.효율적으로, 아니다제대로, 그래서 그것은 내가 그것을 사용하지 않더라도 -S두 경우 모두 희소 파일을 정확하게 복사해야 한다는 것을 암시합니다. 그렇지 않았고 희소 파일이라 할지라도 60.0 페타 바이트인 것은 확실(?) 파일 시스템 어딘가에 오류가 있는 것이 가장 큰 관심사입니다. 파일 시스템에 결함이 있는 경우 해당 파일을 삭제하면 다른 파일에 영향을 미칠 수 있습니까?
더 구체적으로 말하자면, 13GB의 데이터를 기록하고 등반하는 것입니다! 취소하면 13GB~60PB의 데이터도 삭제되나요?
답변1
일반적으로 커널 버그나 RAM 불량으로 인해 소스 파일 시스템이 손상된 것 같습니다(손상된 디스크는 손상된 데이터보다 읽을 수 없는 파일이 될 가능성이 더 높습니다). 이 시점에서 모든 베팅은 종료됩니다. 그러나 손상이 매우 국한된 경우 해당 파일의 inode만 손상되고 다른 파일은 손상되지 않으므로 해당 파일을 안전하게 삭제할 수 있습니다. 이 가정을 테스트할 방법이 없다는 점에 유의하십시오.
내 권장 사항은 다음과 같습니다.
- RAM 테스트를 수행하거나 디스크를 다른 시스템에 연결하십시오.
- 모든 데이터를 백업했는지 확인하십시오.
- 가능하면 SMART를 사용하여 디스크 상태를 확인하십시오.
- 달리다
fsck. - 디스크가 여전히 양호하면 계속 사용하세요.
답변2
그것은스파스 파일. -S파일이 최대한 적절하게 처리되도록 을 사용하는 것을 고려해야 합니다 .