.png)
30GB 드라이브를 갖춘 작은 Intel NUC가 있습니다. 내 문제는 이 드라이브가 꽉 찼지만 원인을 찾을 수 없다는 것입니다.
df다음을 보고합니다
Filesystem 1K-blocks Used Available Use% Mounted on
udev 899412 0 899412 0% /dev
tmpfs 189284 2676 186608 2% /run
/dev/sda2 28414508 27751116 0 100% /
tmpfs 946404 0 946404 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 946404 0 946404 0% /sys/fs/cgroup
/dev/loop0 128 128 0 100% /snap/bare/5
/dev/loop1 56832 56832 0 100% /snap/core18/2128
/dev/loop2 56832 56832 0 100% /snap/core18/2246
tmpfs 946404 0 946404 0% /tmp
/dev/loop3 314880 314880 0 100% /snap/makemkv/381
/dev/loop4 66688 66688 0 100% /snap/gtk-common-themes/1515
/dev/loop5 63360 63360 0 100% /snap/core20/1169
/dev/loop6 63360 63360 0 100% /snap/core20/1081
/dev/loop7 33280 33280 0 100% /snap/snapd/13270
/dev/loop8 317184 317184 0 100% /snap/makemkv/385
/dev/loop9 33280 33280 0 100% /snap/snapd/13640
/dev/loop10 66816 66816 0 100% /snap/gtk-common-themes/1519
/dev/sda1 306584 5356 301228 2% /boot/efi
tmpfs 189280 4 189276 1% /run/user/1000
이를 계산하면 약 14GB 정도의 사용된 디스크 공간이 제공됩니다.
달리기sudo lsof | grep REG | grep -v "stat: No such file or directory" | grep -v DEL | awk '{if ($NF=="(deleted)") {x=3;y=1} else {x=2;y=0}; {print $(NF-x) " " $(NF-y) } }' | sort -n -u | numfmt --field=1 --to=iec | tail -10
중요한 몇 가지 프로세스가 포함된 목록을 제공합니다.
5,5M /usr/lib/php/20190902/fileinfo.so
6,8M /usr/lib/jellyfin/bin/libcoreclr.so
8,0M /var/log/journal/6296b00d07874d0a9533eed0efb81840/user-1000.journal
8,2M /usr/lib/jellyfin/bin/System.Private.Xml.dll
8,3M /usr/lib/locale/locale-archive
8,9M /usr/lib/jellyfin/bin/System.Private.CoreLib.dll
10M /usr/lib/udev/hwdb.bin
24M /snap/snapd/13640/usr/lib/snapd/snapd
27M /usr/lib/x86_64-linux-gnu/libicudata.so.66.1
64M /memfd:pulseaudio
실행하면 sudo du -sh / --exclude=disks --total총 13GB가 제공됩니다.
따라서 기본적으로 시스템이 내 드라이브를 채우고 있는 것으로 보고하는 누락된 ~16GB가 있는지 확인하는 방법에 대한 아이디어가 없습니다.
보고서는 실제로 다음과 같이 동작합니다.
cd ~/ && touch example && echo "FooBar" > example
-bash: echo: write error: No space left on device
미리 감사드리며 어떤 아이디어든 좋은 아이디어입니다. 기본적으로 현재 사용할 수 없는 장치가 있고 옵션이 부족합니다(기본적으로 완전히 다시 설치하거나 더 이상 사용해서는 안 되는 장치를 위해 더 큰 SSD를 구입하는 것) 20GB 이상)
답변1
"/" 파티션을 채우는 것을 찾으려고 시도할 수 있는 몇 가지 가능성은 다음과 같습니다.
lsof -nP +L1# 삭제(링크 해제)되었지만 여전히 프로세스에 의해 열려 있고 따라서 여전히 dist를 차지하는 모든 파일을 나열해야 합니다.- 해당 답변도 참조하십시오.https://unix.stackexchange.com/a/68532/27616몇 가지 추가 정보와 시도해 볼 사항을 제공합니다.
df -ih /또 다른 가능성: 해당 파일 시스템에 "수백만" 개의 작은 파일이 없는지 확인하십시오/. 각 파일은 최소한 "작은" 양의 디스크를 차지합니다(보통 최소 1개의 inode를 차지하기 때문에 크기는 다음에 따라 다름). 파일 크기 및 파일 시스템). 이것은 합산될 수 있습니다... 점유된 최소 디스크 공간이 512바이트인 경우 각각 1바이트의 파일 100만 개가 있으면 여전히 100만 바이트 대신 5억 1200만 바이트를 차지하게 됩니다.df점유된 디스크 공간(전체 inode 공간 계산)을 표시하는 반면,du추가된 파일 크기(즉, 해당 콘텐츠를 포함하는 inode가 차지하는 공간이 아닌 해당 파일의 콘텐츠만 표시)를 표시합니다.- 또 다른 가능성: 마운트된 파일 시스템에 의해 숨겨진 일부 큰 파일이 있을 수 있습니다. 즉, 일부 파일은 마운트된 파일 시스템 "아래"에 있을 수 있습니다.
/tmp예배 규칙서(파일 시스템에 있고 파일 시스템/을 마운트하기 위한 마운트 지점으로 사용되는 것/tmp)?/tmp파일 시스템이 마운트되지 않은 동안 거기에 물건을 넣으면 이런 일이 발생할 수 있습니다 . 이를 확인하려면 Linux에서/어딘가에 읽기 전용으로 다시 마운트(예:/mnt/readonlyroot/마운트 지점 아래에 마운트)하고 를 사용하여 찾아본 다음 #du -hs /mnt/readonlyroot과 비교하면 du가 다른 파일 시스템으로 내려가는 것을 방지할 수 있습니다. 예를 들어 파일 시스템 과 같이 아래에 마운트됩니다 .du -hxs /-x//tmp- 일부 마운트 지점 아래에서 읽기 전용으로 마운트(두 번째)하는 명령
/: 할 수 있습니다(내 메모리 상단에서... 지금은 Linux에서 확인할 수 없습니다).mkdir -p /mnt/rootreadonly/디렉토리 마운트 지점을 생성합니다(아이러니하게도 "/" 파일 시스템 내부에 위치하게 됩니다...).mount -o loop -o ro /dev/sda2 /mnt/rootreadonly("/" 파일 시스템이 읽기 전용으로 나타나도록 하기 위해 질문에서 "/" 파일 시스템이 "/dev/sda2"에 있음을 보여 주므로 여기에 sda2를 지정합니다. 이 답변을 읽는 다른 사람은 먼저 출력을 확인해야 합니다. 파일 시스템이 어디서 왔는지mount확인하는 중 ...)/
- 일부 마운트 지점 아래에서 읽기 전용으로 마운트(두 번째)하는 명령