OpenSolaris에서 파일을 제거 할 때 장치 공간이 부족합니다

클라이언트 상자에 NFS 공유 ( OpenIndiana 서버 에서 내 보낸)를 마운트하려고 할 때 OI 서버가 충돌했습니다. 나는 검은 화면이 생겨서 로그 덤프처럼 보였고, 시스템은 회복되었다. 다시 부팅되지 않았으며 부팅을 중단 한 후 다음과 같은 오류 메시지가 나타납니다.

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

OS 이외의 부팅 드라이브에 다른 것이 없으므로 드라이브를 채울 수 있는지 잘 모르겠습니다. 어쩌면 어떤 종류의 로그 파일입니까? 관계없이 아무것도 삭제할 수없는 것 같습니다. 아무것도 시도하고 삭제할 때 공간 오류가 발생하지 않습니다.

$ rm filename
cannot remove 'filename' : No space left on device 

"유지 관리 모드"에 로그인 할 수 있지만 표준 사용자 프롬프트는 로그인 할 수 없습니다.

출력 df은 다음과 같습니다.

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

출력 mount은 다음과 같습니다.

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

'zfs list -t all'의 출력은 다음과 같습니다.

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

좋아, 그것은 이상하다. .. 파일을 제거 할 공간이 충분하지 않다!

스냅 샷 이 있는 모든 파일 시스템에서 잠재적으로 발생할 수 있지만 ZFS에서는 비교적 일반적인 문제입니다 .

삭제하려는 파일이 여전히 스냅 샷에 존재한다는 설명입니다. 따라서 삭제하면 내용이 기존 스냅 샷에만 유지됩니다. 시스템은 스냅 샷에 파일이 있지만 현재 상태에없는 정보를 추가로 작성해야합니다. 약간의 추가 정보를위한 공간이 남아 있지 않습니다.

단기 수정은 최신 스냅 샷 이후에 생성 된 파일을 찾아 삭제하는 것입니다. 또 다른 가능성은 최신 스냅 샷 이후에 추가 된 파일을 찾아 최신 스냅 샷 당시의 크기로 자르는 것입니다. 로그 스팸으로 인해 디스크가 가득 찬 경우 가장 큰 로그 파일을 잘라보십시오.

보다 일반적으로 적용 가능한 수정은 일부 스냅 샷을 제거하는 것입니다. 로 스냅 샷을 나열 할 수 있습니다 zfs list -t snapshot. 특정 스냅 샷을 삭제하면 저장되는 데이터가 다른 스냅 샷에 필요할 수 있고 스냅 샷을 삭제하면 계속 작동하기 때문에 얼마나 많은 공간을 확보 할 것인지를 쉽게 예측할 수있는 방법은없는 것 같습니다. 따라서 필요한 경우 데이터를 다른 디스크에 백업하고 더 이상 필요하지 않은 하나 이상의 스냅 샷을 식별 한 후 실행하십시오 zfs destroy name/of/snap@shot.

이 OpenSolaris 포럼 스레드 에서이 문제에 대한 확장 된 토론이 있습니다.

이것은 기록 중 복사 파일 시스템의 잘 알려진 문제입니다. 파일을 삭제하려면 파일 시스템이 먼저 블록을 할당하고 새로운 상태를 수정해야 파일에 포함 된 풍부한 공간을 해제 할 수 있습니다.

( 복사시 복사 이외의 다른 방법이 있기 때문에 스냅 샷이있는 파일 시스템의 문제 는 아닙니다 )

짜내는 방법 :

• 스냅 샷 해제 (있는 경우 ...)
• 풀을 늘리십시오 (할당 할 여분의 여유 공간이있는 경우)
• 풀에서 다른 파일 시스템을 파괴 한 다음 타이트 파일 시스템
• 파일을 자른 다음 제거하십시오 (너무 꽉 조여도 그렇게 할 수는 없지만 ZFS Discuss의 스레드 참조 )
• 파일을 연결 해제하십시오. (같은 상기와)

나는 몇 년 전에 같은 함정에 빠졌고, 자유롭게 해줄 수있는 스냅 샷이 없었습니다. ZFS 토론 에서이 문제에 대해 자세히 논의한 스레드를 참조하십시오 .

4. Z3G (rpool / root USED 컬럼)는 모호합니다.

어쨌든 rpool / export / home / admin이 너무 크면 (3.85GB) 근본 원인 일 수 있습니다. 내용을보고 불필요한 파일을 제거하십시오. 관리 파일 시스템에는 스냅 샷이 없으므로 풀의 일부 공간을 즉시 확보해야합니다.

나는 그것을 가지고 있었고 필요한 것을 알아 내려고 노력했습니다. 내 해결책은 파일을 삭제하기 전에 파일 공간을 없애는 것이 었습니다.

우리는 때때로 미쳐 가고 디스크를 핵심 파일 (숫자로 끝나는)로 채우는 오작동하는 프로세스를 가지고 있으므로 하나의 사본을 유지하기 위해 이와 같은 것을 포함하는 스크립트를 생성했습니다.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

스크립트를 실행할 때 하나의 오류가 발생했습니다.

mv: cannot rename core.200000 to core: No space left on device

파일을 지우는 기능이었습니다.

이를 테스트하기 위해 디스크를 다음과 같이 채웠습니다.

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done