나는 백업용으로 사용하려는(오래 전에 사용했어야 했던) 1TB 외장 하드 드라이브를 가지고 있으며 이를 이해하기 위해 많은 실험을 수행했습니다. 데스크탑 그래픽 목록의 메뉴 항목 속성을 다시 살펴보니 Property
그 중 3분의 1 정도가 사용된 것을 보고 놀랐습니다. 그런 다음 명령줄을 살펴보니 다음과 같은 결과가 나왔습니다.
[root@localhost]/home/Harry# du -cs /run/media/Harry/CA6C321E6C32062B
167785742 /run/media/Harry/CA6C321E6C32062B
167785742 total
[root@localhost]/home/Harry# ls -alh /run/media/Harry/CA6C321E6C32062B
total 4.2M
drwx------ 1 Harry Harry 4.0K Nov 18 15:15 .
drwxr-x---+ 3 root root 60 Nov 21 14:14 ..
drwx------ 1 Harry Harry 4.0K Oct 22 2013 2014-01-07
drwx------ 1 Harry Harry 4.0K Sep 22 20:12 2014-09-22
drwx------ 1 Harry Harry 4.0K Sep 23 19:56 2014-09-23
drwx------ 1 Harry Harry 4.0K Sep 23 19:56 2014-09-24
drwx------ 1 Harry Harry 4.0K Sep 25 19:18 2014-09-25
drwx------ 1 Harry Harry 4.0K Sep 25 19:18 2014-09-26
drwx------ 1 Harry Harry 4.0K Sep 27 23:33 2014-09-27
drwx------ 1 Harry Harry 4.0K Sep 28 19:12 2014-09-28
drwx------ 1 Harry Harry 4.0K Oct 7 20:00 annals
-rw------- 1 Harry Harry 30 Apr 23 2013 autorun.inf
drwx------ 1 Harry Harry 0 Oct 12 16:54 GPS
drwx------ 1 Harry Harry 0 Nov 18 15:15 System Volume Information
-rw------- 2 Harry Harry 4.2M Apr 17 2013 TOSHIBA STOR.E ALU 2S 2.5.pdf
[root@localhost]/home/Harry#
나는 여러 사이트에서 이 차이점을 "설명"하고 여러 가지 다르고 다소 혼란스러운 답변을 제공하는 것을 보았지만 그 중 어느 것도 공간을 복구하는 데 도움이 되지 않았습니다.
나는 얼마 전에 이것을 보고 거대한 trash
폴더를 "삭제"했고 rm
그것이 문제의 일부일지도 모른다고 생각했습니다.
이에 덧붙여 위와 같은 내용을 작성하고 인터넷을 검색한 후 다음 명령어를 사용했는데 ncdu /run/media/Harry/CA6C321E6C32062B
, 결과는 이었습니다 . 나는 또한 이것을 시도했다
[root@localhost]/home/Harry# baobab /run/media/Harry/CA6C321E6C32062B
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
(baobab:15557): dconf-WARNING **: failed to commit changes to dconf: The connection is closed
...이 이미지가 만들어졌습니다. 마우스 포인터를 내부 링으로 이동하면 라벨이 생성되지만 Annals 171.8 GB
이미지에 표시할 수 없습니다.
Annals
디렉토리가 분명히 차지하는 추가 공간을 복구할 수 있는 방법이 있습니까 ? 그게 어디서 나온 건지 모르겠어요. 이쯤 되면 저를 완전 초보자로 대해주세요.
답변1
annals
왜 디렉토리를 삭제하지 않습니까 ?
# rm -r /run/media/Harry/CA6C321E6C32062B/annals
참고: 디렉토리가 있기 때문에 Windows 시스템에 있는 것처럼 보입니다 System Volume Information
. 이것은 아마도 NTFS라는 뜻인가요? 이런 경우에는 *nix 친화적인 파일 시스템으로 포맷하는 것이 더 나을 수 있습니다.
물론 이는 위의 항목 중 어느 것도 유지하고 싶지 않다고 가정합니다. 이렇게 하려면 먼저 디스크에서 복사한 다음 포맷하세요.
답변2
질문을 올바르게 이해했다면 문제는 데이터를 잘못 읽고 해석하고 있다는 것입니다. 'ls'로 표시되는 크기는 디렉터리의 크기입니다.체크리스트, 디렉토리에 포함된 모든 파일의 크기가 아닙니다.
이 시도:
작은 상자를 얻으세요. 몇 권의 책이나 기타 크거나 무거운 물건을 안에 넣으세요. 이제 작은 종이를 가져다가 그 위에 "물건 상자"라고 쓰세요. 이제 상자의 무게를 측정해 보세요. 그런 다음 종이 조각의 무게를 개별적으로 측정합니다. 그들은 동일합니까? 매우 무거운 용지를 사용하지 않는 한 거의 발생하지 않습니다. 종이의 무게(상자 자체가 아닌 상자 안에 무엇이 들어 있는지 알려주는 텍스트 포함)가 너무 작아서 저울이 이를 인식하지 못할 수도 있습니다.
디렉토리 목록은 거의 동일합니다. 그렇지 않다콘텐츠카탈로그, 나는 그 안에 무엇이 있는지 알려주는 레이블일 뿐입니다. 이것이 "ls"가 보고하는 내용입니다: 단지 레이블의 크기입니다. 반면에 "du" 명령은 상자에 몇 개의 조각이 있는지 알려줍니다.그리고 그 안에 있는 모든 것무거운.
그렇다면 왜 4.0K입니까? 글쎄요, 상자가 많고 각 상자의 크기가 같다고 상상해 보세요. 많은 작은 품목(예: 다른 상자에 들어 있는 품목의 종이 목록)의 경우 여러 품목을 하나의 상자에 넣을 수 있습니다. 그러나 매우 큰 품목/품목 자체의 경우 보관하기 위해 여러 개의 상자가 필요할 수 있습니다. 마찬가지로 파일 시스템도 매우 유사합니다. 전체 디스크를 "청크"라고 하는 작은 조각으로 나눕니다. 매우 작은 품목의 경우 상자만 있으면 됩니다. 매우 큰 품목의 경우 두 개 이상이 필요할 수 있습니다. 이 경우 예제에서는 디스크의 블록 크기가 4.0K임을 나타냅니다. 따라서 모든 파일 목록이 4.0K 내에 있는 한 다른 "상자"/"청크"를 사용하지 않습니다. 파일의 실제 내용이 맞는지 여부에 관계없이 전체 목록이 하나의 블록에 맞습니다. 이는 각 청크에 할당된 최소 크기이므로 항상 4.0k가 됩니다.같거나 작다4.0K. 목록이 4.0K를 초과하면 총 크기 8.0K에 대해 또 다른 4.0K 블록을 할당합니다. 이제 총 크기가 8.0K를 초과할 때까지 다른 블록을 할당하지 않습니다. 등.
"ls"가 디렉터리 데이터에 사용된 전체 크기를 나열하지 않는 이유가 궁금하다면그리고여기서 모든 파일의 총 개수는 간단합니다. "ls" 명령을 실행할 때마다 각 항목의 크기를 계산해야 합니다. "ls -al /"을 수행했다고 상상해 보십시오. "/"를 나열하려고 할 때마다 전체 1TB 드라이브의 전체 크기를 계산해야 합니다. 그러나 그에 따라 총계를 조정하려면 파일 시스템의 모든 파일을 검사하여 어떤 파일이 심볼릭 링크인지, 하드 링크인지, 마운트 지점인지 등을 확인해야 합니다.
예를 들어, 4MB 드라이브가 있는 경우(예,매우 작은최신 크기) 4개의 1MB 파티션으로 나뉩니다. 파티션 1은 루트 "/", 파티션 2는 스왑 공간, 파티션 3은 "/some/deep/nested/path"에 설치되고, 파티션 4는 "/home"입니다. "ls -al /"은 무엇을 보고해야 합니까? "/" 파티션의 전체 크기(1MB)입니까, 아니면 4개 파티션 모두의 전체 크기(4MB)입니까? 드라이브의 모든 파일을 확인하여 어떤 파티션에 있는지 확인하지 않고 어떤 것이 무엇인지 어떻게 알 수 있습니까? 4MB 드라이브의 경우 시간이 많이 걸리지 않지만 거의 꽉 찬 6TB 드라이브를 상상해 보세요. "ls"가 드라이브의 모든 파일을 검사하는 동안 몇 시간 정도 기다릴 수 있습니다.
"du"는 다르게 수행하지만 파일 시스템이 사용 데이터를 유지하는 방법에 대한 또 다른 매우 복잡하고 기술적인 프로세스입니다. 말하자면 사실입니다.아니요원하는 데이터를 추적하세요(디렉터리별 사용량). 크기만 기록됩니다.전체 파티션그리고 얼마나 많은 공간이 사용되는지전체 파티션따라서 여유 공간 = 전체 공간 - 사용된 공간을 계산할 수 있습니다. 각 디렉토리에 대한 정보를 추적하려고 시도하고 변경될 때마다 이를 다시 계산해야 한다면 'ls'와 동일한 문제가 발생합니다(6TB 드라이브에서 단일 바이트만 변경한 경우 몇 시간이 걸릴 수 있음)! )
답변3
대부분을 유지/수리하려는 경우 첫 번째 옵션은 실제 Windows 상자에 연결하고 chkdsk /f /r
해당 드라이브에서 실행하는 것 입니다.
경고하다: 이 작업은 몇 시간이 걸릴 수 있습니다.
예를 들어 확인하십시오.http://technet.microsoft.com/en-us/magazine/ee872425.aspx사용하기위한.
autorun.inf
사용된 파일 시스템이 지정되지 않았기 때문에 파일과 폴더 가 분명하므로 NTFS로 가정합니다 System Volume Information
.
(팁: TOSHIBA STOR.E ALU 2S도 NTFS용으로 사전 포맷되어 있습니다.)
질문의 다른 부분에서는 전체 공간 사용량의 차이가 손상된 파일 시스템이나 열린 파일 핸들에서 발생할 수 있습니다. 후자는 the du -sm /run/media/Harry/CA6C321E6C32062B
와
df -m /run/media/Harry/CA6C321E6C32062B
출력의 차이로 쉽게 관찰할 수 있으며, df와 du 출력의 사용된 공간을 비교하면 매우 유사해야 합니다.
또한 드라이브가 30% 이상 사용되었다는 결론을 어떻게 얻었는지 명시하지 않았습니까?