내 서버 중 하나에 이상한 문제가 있습니다. 디스크 공간의 거의 절반을 잃었습니다.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 271G 122G 149G 46% /
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.8G 8.0K 3.8G 1% /dev/shm
tmpfs 3.8G 8.6M 3.8G 1% /run
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/sda1 497M 120M 378M 24% /boot
tmpfs 778M 0 778M 0% /run/user/600
반면에 du는 6GB만 사용된 것으로 표시합니다.
du -hs /
6.0G /
이는 로그가 정기적으로 디스크를 100%까지 채우는 서버이므로 첫 번째 반응은 rsyslog 데몬을 다시 시작하는 것이었지만 아무런 효과가 없었습니다. 또한 서버를 다시 시작하려고 시도했기 때문에 일부 파일이 삭제되었지만 일부 프로세스에서 여전히 사용되는 것은 불가능합니다. 내가 찾고 있어요https://serverfault.com/questions/299839/linux-disk-space-missing누군가 다시 시작을 제안했지만 fsck도움이 되지 않았습니다. 같은 페이지에서 누군가가 다른 마운트 지점에서 파일을 찾아보라고 제안했지만 아무 것도 없습니다. 더 많은 조언을 구하고 있습니다.
출력 fdisk:
fdisk -l /dev/sda
Disk /dev/sda: 299.5 GB, 299506860032 bytes, 584974336 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 65536 bytes / 65536 bytes
Disk label type: dos
Disk identifier: 0x000f1d8a
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 17018879 7996416 82 Linux swap / Solaris
/dev/sda3 17018880 584974335 283977728 83 Linux
lsblk산출:
lsblk -f /dev/sda
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 xfs 78e8f824-1a2a-4c60-ab7b-6126a192932d /boot
├─sda2 swap bdbe969d-c59d-4956-ae69-71e2825f93dc [SWAP]
└─sda3 xfs a9c9da10-5e99-4a14-a207-490e3f676617 /
`xfs_quota -x -c 'free -h -b'` output:
Filesystem Size Used Avail Use% Pathname
/dev/sda3 270.7G 127.1G 143.5G 47% /
/dev/sda1 496.5M 119.0M 377.5M 24% /boot
Filesystem Size Used Avail Use% Pathname
/dev/sda3 270.7G 127.1G 143.5G 47% /
/dev/sda1 496.5M 119.0M 377.5M 24% /boot
xfs_quota -x -c 'quota -h'아무것도 반환하지 않습니다. 누구도 할당량을 설정하지 않습니다. 이는 동일한 구성과 파티션 레이아웃을 사용하여 지점에 배포된 수백 대의 서버 중 하나이지만 이 서버에만 이 문제가 있습니다. 어떤 특정한 이유로 인해 정기적으로 최대 100%까지 채워지는 유일한 디스크입니다. 우리는 매주 또는 2주에 한 번씩 일부 로그를 수동으로 삭제합니다.
답변1
boot, dev, run, 마운트 지점 디렉토리 중 하나 아래에 많은 수의 파일이 숨겨져 있는 것으로 보입니다. 이 sys디렉토리는 마운트 중인 다른 파일 시스템으로 인해 액세스할 수 없는 경우가 많습니다. 실행 중인 시스템에서 액세스해 보세요.
mkdir /mnt/root
mount --bind / /mnt/root
du -hs /mnt/root/
du반환된 값이 보고한 6GB 사용량보다 훨씬 많으면 이것이 문제인 것이 거의 확실합니다 . 이를 사용하여 손실된 파일이 숨겨져 있는 위치를 식별합니다.
du -hs /mnt/root/{boot,dev,run,sys}
이는 /mnt/root실제로 루트 /파일 시스템이므로 삭제나 기타 파일 작업에 주의해야 한다는 점을 기억하세요. 어떤 경우에도 /mnt/root마운트 지점으로 사용될 수 있는 디렉터리를 직접 삭제하려고 시도해서는 안 됩니다.
답변2
fs에서 어떤 공간을 차지하고 있는지 알아내는 가장 좋은 도구(어떤 파일이 삭제되었지만 아직 열려 있는지는 알 수 없음)는 rootfs를 진단 ncdu해 보는 것 입니다.ncdu -qx /
재부팅 후에도 문제가 지속되므로 "삭제되었지만 여전히 열려 있는 파일"의 피해자는 아닌 것으로 보입니다.
답변3
실행 중인 시스템에서 모든 파일과 디렉터리에 액세스하려면 루트 사용자로 디스크 사용량을 확인해야 합니다.
루트 파일 시스템에 할당량이 활성화되어 있을 수도 있습니다. 확인하다xfs_quota -x -c 'free -hi' /
라이브 CD(gparted, systemrescue)로 부팅 mount /dev/sda3 /mnt하고 du -csh /mnt/* 및 df -H.
그런 다음 /dev/sda3을 마운트 해제하고 /dev/sda3에서 마운트 해제된 xfs 파일 시스템을 확인합니다 xfs_repair -n /dev/sda3.
읽다https://mankier.com/8/xfs_repair어떤 검사를 수행하는지 알아보세요.
답변4
구성과 파티션이 동일한 서버 100대 중 1대입니다.
fs의 실제 사용량을 추정할 수 있습니까? 6GB는 너무 작나요?
dfGetInfo statvfs()는 슈퍼블록에서 사용 가능한 블록 수를 보고하므로 "사용량"은 계산된 값입니다.
기본적으로 du각 파일이 사용하는 블록과 해당 파일이 있는 디렉터리도 계산됩니다.
du < df 파일 시스템이 있기 때문에
블록은 fs에 의해 사용 가능한 것으로 간주되지 않으며
du디렉토리 항목 또는du어떤 이유로 인해 디렉토리 항목에 액세스할 수 없습니다. 여기에서 권한, ACL, SELinux, AppArmor, 긴 파일 이름을 확인하세요. https://unix.stackexchange.com/a/619878/153329
다음으로 고려하십시오:
또한 특정 이유로 인해 정기적으로 디스크를 100%까지 채우는 유일한 소프트웨어입니다. 우리는 매주 또는 2주에 한 번씩 일부 로그를 수동으로 삭제합니다.
열려 있는 파일을 삭제하면 파일 이름이 있는 디렉터리 항목은 사라지지만 inode는 그대로 남아 있으며, 파일 핸들이 닫히면 커널은 inode를 삭제하고 블록을 해제합니다.
가동 시간이 높은 컴퓨터에는 분리된 inode가 많을 수 있으므로 재부팅하는 것이 도움이 됩니다.
재부팅할 때 fsck가 도움이 되지 않았습니다.
어떤 이유로 이러한 분리된 inode는 오류, 정전, 이전 디렉터리 손상으로 인해 커널에서 제거되지 않을 수 있으므로 재부팅해도 도움이 되지 않습니다.
xfs_repair /dev/sda3마지막으로 마운트 해제된 파일 시스템을 수동으로 확인하는 것이 좋습니다 .
도움이 되지 않으면 파일 시스템이 손상되어 xfs_repair가 프리맵을 올바르게 업데이트할 수 없는 것일 수 있습니다.
대부분의 경우 신뢰해야 합니다 du.
다음에도 확인해 보세요.
du -h그것과 비교해보세요 du -bh /.
희소 파일 찾기:
find / -type f -printf "%S\t%p\n" | gawk '$1 < 1.0 {print}'
fs 블록 크기보다 작은 작은 파일이 많이 있을 수 있습니다.
xfs_info / | grep bsize
find / -type f -size -4096c | wc -l00