파일 제거 후 Linux의 df가 올바른 여유 공간을 표시하지 않습니다

파일을 저장하는 데 사용되는 파일 서버가 있습니다. 파일은 일주일 또는 1 년 동안있을 수 있습니다. 불행히도 서버에서 파일을 제거 할 때 df명령에 여유 공간이 반영되지 않습니다. 결국 서버가 가득 차고 ( df99 % 표시) 스크립트에 더 많은 파일을 보내지 않습니다. 단, 수십 GB의 여유 공간이있을 수 있습니다.

내가있어 noatime그 어떤 변화도 가져 오지면 마운트 된 파티션에 플래그를.

파일 이름을 삭제해도 실제로 파일이 삭제되지는 않습니다. 다른 프로세스가 파일을 열어 놓아 삭제되지 않도록합니다. 해당 프로세스를 다시 시작하거나 종료하여 파일을 해제하십시오.

사용하다

lsof +L1

삭제 된 (연결되지 않은) 파일을 사용중인 프로세스를 찾으려면

Ignacio가 언급했듯이 파일을 삭제하면 해당 파일에 대해 열린 핸들이있는 프로세스를 삭제할 때까지 공간을 비울 수 없습니다.

그럼에도 불구하고 프로세스를 중단하지 않고 공간을 회수 할 수 있습니다. 파일 디스크립터를 제거하기 만하면됩니다.

먼저 lsof | grep이 파일을 보유한 프로세스를 식별하기 위해 삭제되었습니다.

[hudson@opsynxvm0055 log]$ /usr/sbin/lsof |grep deleted
java       8859   hudson    1w      REG              253,0 3662503356    7578206 /crucible/data/current/var/log/fisheye.out (deleted)

그런 다음 다음을 실행하십시오.

cd /proc/PID/fd

그때

[hudson@opsynxvm0055 fd]$ ls -l |grep deleted
total 0
l-wx------ 1 hudson devel 64 Feb  7 11:48 1 -> /crucible/data/current/var/log/fisheye.out (deleted)

"1"은 파일 설명자가됩니다. 이제 그 공간을 되찾기 위해 "> FD"를 입력하십시오

> 1

파일을 보유하는 다른 프로세스가있는 경우 작업을 반복해야 할 수도 있습니다.

한 가지 가능성은 삭제 한 파일이 파일 시스템에서 더 많은 참조를 가질 수 있다는 것입니다. 하드 링크를 만든 경우 여러 파일 이름이 동일한 데이터를 가리키며 데이터 (실제 내용)는 모든 참조가 제거 될 때까지 사용 가능 / 사용 가능한 것으로 표시되지 않습니다. 파일을 삭제하기 전에 파일을 링크하거나 (항목 이름 링크) ls -l을 수행하십시오 (두 번째 열이어야 함).

파일이 다른 곳에서 참조 된 것으로 판명되면 inode-number를 찾으려면 파일을 ls -i해야하고 -inum <inode-number>로 찾기를 수행하여 해당 파일에 대한 다른 참조 (아마도 -mount를 사용하여 동일한 파일 시스템 내에 유지하려는 경우)

파일을 여는 과정에서 파일이 여전히 잠겨 있습니다. 공간을 확보하려면 다음 단계를 수행하십시오.

1. sudo lsof | grep deleted어떤 프로세스가 파일을 보유하고 있는지 확인하고 실행 하십시오. 결과 예 :

   $ sudo lsof | grep deleted
   COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
   cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)
   

2. 를 사용하여 프로세스를 종료하십시오 sudo kill -9 {PID}. 위 샘플에서 PID는 1623입니다.

   $ sudo kill -9 1623
   

3. df공간이 이미 확보되었는지 확인하기 위해 실행 합니다. 여전히 가득 찬 경우 몇 초 정도 기다렸다가 다시 확인해야합니다.

파티션이 루트 사용을 위해 디스크 공간의 특정 부분을 예약하도록 구성된 df경우이 공간을 사용 가능한 것으로 포함하지 않습니다.

[root@server]# df -h
Filesystem            Size  Used Avail Use% Mounted on
...
/dev/optvol           625G  607G     0 100% /opt
...

파일 / 디렉토리를 삭제하여 공간을 확보 한 후에도 루트가 아닌 사용자는 특정 파티션에 쓸 수 없습니다.

루트 및 비 루트 사용자로 장치에서 파일을 작성하여 해당 사례인지 쉽게 확인할 수 있습니다.

또한 다음을 실행하여 파일 시스템 구성을 확인할 수 있습니다

tune2fs -l <device> | egrep "Block count|Reserved block count

자신의 실제 %를 계산합니다.

루트 전용 사용을 위해 예약 된 디스크 %를 변경하려면 다음을 실행하십시오.

tune2fs -m <percentage> <device>

다른 대답은 맞습니다. 파일을 삭제하고 공간이 확보되지 않으면 파일이 여전히 열려 있거나 다른 하드 링크가 있기 때문입니다.

문제 해결에 도움이되도록 드라이브 공간이 어디에 사용되는지 알려주는 도구를 사용하십시오 du. 공간이 어디로 이동하는지에 대한 개요를 얻는 데 사용할 수 있습니다 . 더 좋은 점은 xdiskusage 와 같은 그래픽 도구 (이와 같은 것들이 많음 )를 사용하여 범인을 찾아 내십시오 . xdiskusage와 친구들을 사용하면 가장 큰 스페이스 호그로 드릴 다운하여 스페이스가 어디로 가는지 알 수 있습니다.

이렇게하면 두 번째 하드 링크로 인해 여전히 공간을 차지하는 파일을 빠르게 찾을 수 있습니다. 또한 삭제 된 공간을 차지하지만 열린 파일 (파일 이름을 읽을 수 없기 때문에 (권한이 거부 됨)으로 표시됩니다).

/varFS가 줄어들 것으로 예상되는 파일 을 redhat 및 gzipping하기 위해이 작업을 수행하고 있음을 알고 있기 때문에 syslog 재시작 서비스를 제공하십시오. 과

lsof -v file

어쨌든 이것을 보여줄 것입니다.

추가 옵션 : 계속해서 데이터를 작성하는 프로세스 (로그, 코어 등)로 인해 디스크가 가득 찼을 수 있습니다. 공간이 실제로 해제되었지만 즉시 채워질 수 있습니다. 나는 실제로 그런 경우를 보았습니다. df이 경우 단순히 구멍 그림을 제공하지 않습니다. du자세히 알아 보려면 사용하십시오 .

EXT2를 사용하고 있는데 FSCK가이 상황에서 도움이되었습니다. shudown -F now을 시도하십시오. 다시 시작하고 fscks 한 후 절반의 공간이 사용 된 것을 볼 수 있습니다.

어떤 삭제 된 파일이 메모리를 차지하는지 확인하려면 다음 명령을 입력하십시오.

 $ sudo lsof | grep deleted

메모리를 보유한 삭제 된 파일이 표시됩니다.

그런 다음 pid 또는 name으로 프로세스를 종료하십시오.

$ sudo kill <pid>
$ df -h

지금 확인 당신은 같은 메모리를 가지고

메모리를 차지하는 파일을 보려면 아래 명령을 입력하지 않으면

# cd /
# du --threshold=(SIZE)

어떤 크기를 언급하는지는 어떤 파일이 임계 값보다 큰지를 보여주고 메모리가 남아있는 파일을 삭제합니다

터미널 열기이 명령을 시도하십시오 df -Th 다음이 명령을 사용하십시오 sudo du -h --max-depth = 1 /이 명령에서 디스크 사용 세부 사항을 찾은 다음 루트 사용자가 파일을 삭제할 때 엽니 다 (root-local-share-trash) 파일을 삭제하십시오