천 마디 말보다 한 장의 그림이 더 중요하므로 다음과 같이 시작하고 싶습니다.
이미지를 보면 약 500GB의 하드 드라이브가 있음을 알 수 있습니다. 파일 시스템은 ext4입니다. 이 500GB 하드 드라이브에는 74TB가 넘는 파일이 있습니다.
rm .npmignore이것이 어떻게 가능한지 알고 싶습니다(분명히 어떤 유형의 디스크 손상). 하지만 더 중요한 것은 파일을 삭제해도 안전한지, 아니면 똑같이 효과적인 삭제 방법이 있는지 알고 싶습니다 .
내 주요 관심사는 파일이 시작된 후 디스크의 데이터를 파괴하는 것입니다. 이는 불가능합니다.
호기심에 파일은 저장소의 PATH 아래에 묻혀 있습니다 node_modules/bower/node_modules/request/node_modules/qs/.npmignore. 파일을 디렉터리 밖으로 이동하고 실행한 후 git checkout .npmignore파일이 실제로 텍스트 파일(duh)이고 실제로 700바이트보다 작다는 것을 발견했습니다.
답변1
파일 시스템이 손상되었을 가능성은 거의 없습니다. 대부분의 Unix 파일 시스템과 마찬가지로 Ext4fs는 스파스 파일을 지원합니다. 즉, 파일의 특정 블록은 물리적 매체에서 지원되지 않으며 일반적으로 읽을 때 반환되는 블록에는 null 값(0)만 포함됩니다.
스파스 파일을 삭제하는 것이 특정 위험을 의미하는 것은 아니지만 사실은 일부 프로세스나 사람이 잃고 싶어하지 않는 데이터가 포함될 수 있다는 것입니다.
이 strings명령을 사용하여 스파스 파일에 포함된 실제 로드를 확인할 수 있습니다.
파일 시스템이 손상된 것으로 의심되는 경우 문제를 찾는 가장 좋은 방법은 마운트를 해제하고 fsck하는 것입니다.
편집하다: 귀하의 질문에 대한 마지막 의견에 따르면 결국 파일 시스템이 손상된 것 같습니다. 손상 징후가 보이는 파일을 삭제하거나 파일 시스템에서 작업을 수행하는 것은 위험하며 파일을 추가로 손상시킬 수 있습니다. 가능한 한 빨리 제거하고 fsck다른 메타데이터가 손상되지 않았는지 확인하는 것이 좋습니다 .
답변2
파일을 삭제하는 것은 "안전"해야 합니다. 이는 npm으로 작업을 수행할 때 무시할 파일과 패턴을 npm에 알려주는 일종의 구성 파일입니다.
삭제할지 여부는 귀하에게 달려 있습니다. 유용한 목적으로 사용될 수 있습니다. 어쩌면 그것을 고양이로 삼아 그 안에 무엇이 들어 있는지 보고 거기에서 판단을 내릴 수도 있습니다.
@jordanm이 지적했듯이 파일은 실제로 47TB가 아닙니다.
답변3
Wumpus Q. Wumbley가 지적했듯이 이는 손상된 바이트이거나 엄청난 우연의 일치입니다. 나는 과감히 파일을 삭제하기로 결정했고, 주변 파일에 뚜렷한 손상을 입히는 일 없이 프로세스가 순조롭게 진행되었습니다.