☰

OpenSolaris에서 파일을 삭제할 때 장치에 공간이 없습니다.

tag-icon • tag-icon boot disk-usage rm opensolaris
OpenSolaris에서 파일을 삭제할 때 장치에 공간이 없습니다.

NFS 공유를 마운트해 보십시오(다음에서인디애나 오픈서버) 클라이언트 시스템에서 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    -

답변1

아, 이상하네요... 파일을 삭제할 공간이 부족해요!

이는 모든 파일 시스템에서 발생할 수 있지만 ZFS에서 상대적으로 일반적인 문제인 것으로 나타났습니다.가지다 스냅 사진.

삭제하려는 파일이 스냅샷에 아직 존재한다는 설명입니다. 따라서 삭제해도 콘텐츠는 여전히 존재하며(스냅샷에만) 시스템은 스냅샷에 파일이 있었지만 현재 상태에는 없다는 정보를 추가로 기록해야 합니다. 추가 정보를 위한 공간이 충분하지 않습니다.

단기적인 해결 방법은 최신 스냅샷 이후에 생성된 파일을 찾아 삭제하는 것입니다. 또 다른 방법은 최신 스냅샷 뒤에 첨부된 파일을 찾아서 최신 스냅샷 당시의 크기로 자르는 것입니다. 로그에 스팸이 발생하여 디스크가 가득 차면 가장 큰 로그 파일을 잘라보세요.

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

이 문제에 대한 광범위한 논의가 있습니다.이 OpenSolaris 포럼 주제.

답변2

이는 쓰기 중 복사 파일 시스템의 잘 알려진 문제입니다. 파일을 삭제하려면 파일 시스템이 먼저 블록을 할당하고 새 상태를 복구해야 방금 삭제된 파일에 포함된 많은 공간을 해제할 수 있습니다. 파일.

(이것은아니요쓰기 중 복사 외에 스냅샷을 구현하는 다른 방법이 있기 때문에 스냅샷이 있는 파일 시스템에 문제가 있습니다.

문제에서 벗어나는 방법:

  • 스냅샷 게시(있는 경우...)
  • 풀 확장(할당할 것이 남아 있는 경우)
  • 풀의 다른 파일 시스템을 제거한 후 압축된 파일 시스템 확장
  • 파일을 잘라낸 다음 삭제합니다. (비록 너무 꽉 쥐어 짜서 그렇게 할 수는 없지만ZFS 토론의 스레드)
  • 파일 연결을 해제합니다. (같은 상기와)

나는 몇 년 전에 같은 함정에 빠졌지만 나를 구출할 수 있는 게시 가능한 스냅샷이 없었습니다. 스레드 보기ZFS 토론이 문제는 심도있게 논의되었습니다.

답변3

4.Z3G(rpool/root USED 열)가 의심스럽습니다.

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

답변4

나는 이것을 가지고 있었고 무엇이 필요한지 알아 내려고 잠시 시간을 보냈습니다. 내 해결책은 파일을 삭제하기 전에 파일 공간을 0으로 만드는 것이었습니다.

가끔 이상하게 작동하여 디스크를 핵심 파일(숫자로 끝나는 파일)로 채우는 일부 오작동하는 프로세스가 있으므로 복사본을 보관하기 위해 이와 같은 스크립트를 생성했습니다.

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

관련 정보