Inode 사용법을 해제하는 방법?

inode 사용량이 100 % 인 df -i명령을 사용하는 디스크 드라이브가 있습니다. 그러나 파일을 실질적으로 삭제 한 후에도 사용량은 100 %로 유지됩니다.

그렇다면 올바른 방법은 무엇입니까?

디스크 공간 사용량이 적은 디스크 드라이브는 디스크 공간 사용량이 많은 디스크 드라이브보다 Inode 사용량이 더 높을 수 있습니까?

파일을 압축하여 사용 된 inode 수를 줄일 수 있습니까?

디스크가 꽉 차지 않았더라도 디스크에 많은 수의 inode를 사용하는 것은 매우 쉽습니다.

inode는 파일에 할당되므로, 각각 1 바이트 씩 많은 파일이 있으면 디스크가 부족하기 오래 전에 inode가 부족하게됩니다.

파일에 여러 개의 하드 링크가있는 경우 파일을 삭제해도 inode 수가 줄어들지 않을 수도 있습니다. 내가 말했듯이, inode 는 디렉토리 항목이 아닌 파일에 속합니다 . 파일에 두 개의 디렉토리 항목이 연결되어 있으면 하나를 삭제해도 inode가 해제되지 않습니다.

또한 디렉토리 항목을 삭제할 수 있지만 실행중인 프로세스에 여전히 파일이 열려 있으면 inode가 해제되지 않습니다.

필자의 초기 조언은 가능한 모든 파일을 삭제 한 다음 파일을 열어 놓은 프로세스가 남아 있지 않도록 상자를 재부팅하는 것입니다.

그렇게해도 여전히 문제가 있으면 알려주십시오.

그런데 많은 파일이 포함 된 디렉토리를 찾는 경우이 스크립트가 도움이 될 수 있습니다.

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

운이 좋지 않으면 모든 아이 노드의 약 100 %를 사용했으며 스쿼트를 만들 수 없습니다. 로 확인할 수 있습니다 df -ih.

그런 다음이 bash 명령이 도움이 될 수 있습니다.

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

그렇습니다. 시간이 오래 걸리지 만 파일이 가장 많은 디렉토리를 찾을 수 있습니다.

내 상황은 내가 아이 노드가 없어서 내가 할 수있는 모든 것에 대해 이미 삭제 한 것이었다.

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

나는 우분투 12.04LTS에 있고 패키지가 없어서 apt가 손상되어 약 40 만 개의 inode를 차지하는 오래된 Linux 커널을 제거 할 수 없었습니다. inode가 없어서 새 패키지를 설치할 수 없었습니다.

약 10,000 개의 inode를 확보하기 위해 몇 가지 오래된 Linux 커널을 수동으로 삭제했습니다.

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

이것은 누락 된 패키지를 설치하고 apt를 수정하기에 충분했습니다.

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

그런 다음 이전 Linux 커널의 나머지를 apt로 제거하십시오.

$ sudo apt-get autoremove

상황이 훨씬 나아졌습니다

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

내 해결책 :

이것이 다음과 같은 inodes 문제인지 확인하십시오.

df -ih

inode 수가 많은 루트 폴더를 찾으십시오.

for i in /*; do echo $i; find $i |wc -l; done

특정 폴더를 찾으십시오.

for i in /src/*; do echo $i; find $i |wc -l; done

이것이 리눅스 헤더 인 경우 다음을 사용하여 가장 오래된 것을 제거하십시오.

sudo apt-get autoremove linux-headers-3.13.0-24

개인적으로 나는 그것들을 마운트 된 폴더로 옮기고 (마지막 명령이 실패했기 때문에) 다음을 사용하여 최신을 설치했습니다.

sudo apt-get autoremove -f

이것은 내 문제를 해결했습니다.

나는 같은 문제가 있었고 PHP의 디렉토리 세션을 제거하여 수정했다.

rm -rf /var/lib/php/sessions/

/var/lib/php5이전 PHP 버전을 사용 중인 경우 아래에 있을 수 있습니다 .

다음 권한으로 다시 작성하십시오.

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

데비안의 디렉토리에 대한 기본 권한이 drwx-wx-wt표시됨 (1733)

스팸 공격 후 HostGator 계정 (모든 호스팅에 inode 제한을 두는)에서이 문제가 발생했습니다. /root/.cpanel/comet에 수많은 큐 레코드가 남았습니다. 이러한 상황이 발생하고 빈 inode가없는 경우 쉘을 통해이 cpanel 유틸리티를 실행할 수 있습니다.

/usr/local/cpanel/bin/purge_dead_comet_files

RSYNC를 사용하여 많은 수의 파일을 삭제할 수 있습니다

rsync -a --delete blanktest/ test/

파일이 0 인 빈 테스트 폴더를 만들면 명령이 테스트 폴더를 많은 파일과 동기화합니다 (이 방법을 사용하여 거의 5M 파일을 삭제했습니다).

http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux 덕분에

eaccelerator는 PHP를 블록으로 컴파일하기 때문에 문제를 일으킬 수 있습니다 ...로드가 많은 사이트의 Amazon AWS 서버 에서이 문제가 발생했습니다. 계속 문제가 발생하면 / var / cache / eaccelerator에서 eaccelerator 캐시를 삭제하여 Inode를 비우십시오.

rm -rf /var/cache/eaccelerator/*

(또는 캐시 디렉토리에 관계없이)

우리는 최근 비슷한 문제에 직면했습니다. 프로세스가 삭제 된 파일을 참조하는 경우 Inode가 릴리스되지 않으므로 lsof /를 확인하고 프로세스를 종료 / 다시 시작하면 inode가 해제됩니다.

여기서 틀렸다면 바로 정정하십시오.

앞에서 언급했듯이 작은 파일이 많은 경우 파일 시스템에 inode가 부족할 수 있습니다. 여기에 대부분의 파일이 포함 된 디렉토리를 찾을 수있는 방법이 있습니다 .

늦은 답변 : 제 경우에는 세션 파일이었습니다.

/var/lib/php/sessions

Inode를 사용하고있었습니다.
심지어 crontab을 열거 나 삭제 작업을 트리거하는 것 외에도 새 디렉토리를 만들 수 없었습니다. PHP를 사용하기 때문에 예제 1의 코드를 복사하고 코드의 해당 부분을 실행하도록 cronjob을 설정하는 이 안내서 가 있습니다.

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

crontab을 어떻게 열 었는지 궁금하다면 CLI를 통해 수동으로 일부 세션을 삭제했습니다.

도움이 되었기를 바랍니다!

이 정보를 볼 수 있습니다

for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t

지금 까지이 답변에 대한 많은 답변과 위의 모든 내용이 구체적으로 보입니다. 나는 당신이 갈 때 사용 stat하면 안전하다고 생각 하지만 OS에 따라 일부 inode 오류가 발생할 수 있습니다. 따라서 오버플로 문제를 피하기 위해 자신의 stat통화 기능을 구현 64bit하면 상당히 호환되는 것으로 보입니다.

도커를 사용하는 경우 모든 이미지를 제거하십시오. 그들은 많은 공간을 사용했습니다 ....

모든 컨테이너를 중지

docker stop $(docker ps -a -q)

모든 컨테이너 삭제

docker rm $(docker ps -a -q)

모든 이미지 삭제

docker rmi $(docker images -q)

나에게 작동