☰

파일의 크기(Nemo에 따르면)는 있지만 디스크 공간(RAM)을 차지하지 않는 방법은 무엇입니까?

tag-icon • tag-icon linux filesystems
파일의 크기(Nemo에 따르면)는 있지만 디스크 공간(RAM)을 차지하지 않는 방법은 무엇입니까?

오늘 몇 개의 파일을 다운로드했습니다. AFAIK 응용 프로그램은 처음부터 전체 파일에 대한 공간을 예약합니다. 첫 번째와 두 번째 파일의 경우 다운로드가 시작된 후 사용 가능한 RAM이 감소하는 것을 보았지만 세 번째 파일의 경우 (메시지당) 공간이 부족하여 일부 파일을 삭제하고 다운로드를 시작했습니다. 하지만 놀랍게도 free여전히 많은 여유 공간이 표시됩니다. 응용 프로그램이 실행할 공간의 일부만 예약했을 수도 있다고 생각하여 파일 크기를 확인했지만 그렇지 않았으며 Nemo에서 볼 수 있듯이 파일 크기가 몇 GB 였습니다. 의도한 것보다 실수로 삭제한 것이 더 많을지도 모른다고 생각했는데 다운로드를 해보니 free여유 메모리가 거의 없는 것으로 나타났습니다. 파일 시스템은 상당히 크지만 공간을 차지하지 않는 개체(파일)를 어떻게 보고할 수 있습니까?

시스템은 Ubuntu liveUSB를 기반으로 하며 말한 findmnt대로 RAM으로 부팅하므로 부팅 스크립트에 대해 잘 모르기 때문에(그리고 질문에 어떤 태그가 적용되는지 모르기 때문에 호출하기가 망설여집니다 .) 원인을 확인해야 하는 경우 순수 tmpfs 드라이브에서 문제를 재현해 볼 수 있습니다. 아, 내 질문은 다양한 Linux 유틸리티의 정보가 충돌하는 경우 어떻게 이를 신뢰할 수 있습니까?/cowtmpfs

답변1

파일의 겉보기 크기는 디스크에서 실제로 차지하는 공간과 반드시 ​​동일하지는 않습니다.

$ truncate -s 10P hugefile
$ ls -l hugefile
-rw-rw-r--. 1 skitt skitt 11258999068426240 Jan  7 11:49 hugefile

실제로 10PiB 디스크는 없지만 다행히 hugefile10PiB를 차지하지는 않습니다.

$ stat hugefile
  File: hugefile
  Size: 11258999068426240   Blocks: 0          IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 182589989   Links: 1
Access: (0664/-rw-rw-r--)  Uid: (26561/   skitt)   Gid: (26561/   skitt)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2022-01-07 11:49:26.653101365 +0100
Modify: 2022-01-07 11:49:34.631215761 +0100
Change: 2022-01-07 11:49:34.631215761 +0100
 Birth: 2022-01-07 11:49:26.653101365 +0100

여기서 중요한 필드는 블록 수 0입니다.

이러한 파일을 스파스 파일이라고 합니다.

이것은 파일의 최종 크기가 미리 알려졌을 때 작동하는 다운로드 도구의 수입니다. 파일의 겉보기 크기가 항상 최종 "실제" 크기와 동일하도록 파일의 전체 크기를 제공한 다음 쓰기를 수행합니다. 파일을 받을 때 파일 내용을 확인하고 점차적으로 디스크 공간을 할당합니다. 이것이 당신이 보는 것입니다.

관련 정보