"장치에 공간이 남아 있지 않은"다른 이유가 있습니까?

HD를 외장 USB 3.0 드라이브에 백업하기 위해 Ubuntu 서버 시스템에서 Dirvish를 사용하고 있습니다. 며칠 전까지는 모든 것이 제대로 작동했지만 이제 모든 장치에 "공간이 남아 있지 않습니다 (28)"및 "파일 시스템이 가득 찼습니다"라는 오류로 모든 백업이 실패합니다. 불행히도 그렇게 간단하지 않습니다. 장치에 500GB가 넘는 여유 공간이 있습니다.

세부:

rsync_error :

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

로그는 때까지 평소와 거의 비슷하게 보입니다.

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

그러나 위에서 말했듯이 장치에는 많은 공간이 있습니다.

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

또한 많은 inode가 남아 있습니다.

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

장치는 rw로 마운트됩니다.

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

프로세스가 루트로 실행 중입니다.

나는 아무것도 바꾸지 않았다고 말하려고했지만 사실은 아닙니다. 백업중인 드라이브에 대해 acl을 켰습니다.

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

그게 문제가 될 수 있습니까? 그렇다면 어떻게? root는 여전히 파일에 대한 모든 액세스 권한을 갖습니다.

편집하다:

방금 임시 디렉토리를 확인했습니다.

• / tmp는 비어있는 .webmin 폴더 만 포함합니다.
• / var / tmp가 비어 있습니다

이러한 디렉토리가있는 파일 시스템에는 충분한 여유 공간과 inode가 있습니다.

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2 :

디렉토리는 상당히 크지 만 2GB를 초과하지는 않습니다. 백업이 실패한 파일은 가장 큰 파일이 아니며 7530 파일을 포함합니다.

EDIT3 :

이 질문을 게시 할 때 관련이없는 것으로 간주되는 정보 :

백업이 시작되기 전날 백업 된 파일 시스템에서 acls를 활성화했습니다. 이제 Dirvish (또는 rsync)가 모든 파일이 변경되었다고 생각하여 하드 링크가 아닌 복사 할 파일 목록이 매우 크다고 생각했습니다. 이는 일부 버퍼가 너무 작음을 의미 할 수 있습니다.

오늘날 빈 디스크에 대한 전체 백업은 완벽하게 작동했습니다. 다음에 증분 백업을 시도하겠습니다. 이것은 acls 활성화가 문제의 원인인지 여부를 보여줍니다.

내 의심 (EDIT3 참조)이 옳았습니다. 파일 시스템에 acl 지원을 추가하면 rsync / dirvish는 모든 파일이 변경되었다고 생각했습니다. 따라서 증분 백업을 만들고 기존 파일에 대한 하드 링크를 만드는 대신 하드 디스크에 충분한 공간이 없기 때문에 실패한 전체 백업을 만들려고 시도했습니다.

따라서 오류 메시지가 실제로 정확했습니다.

빈 백업 디스크로 다시 시작한 후에 증분 백업이 이전과 동일하게 작동했습니다.

남은 inode의 2 %를 살펴보면 EXT 파일 시스템이 부과하는 루트 리저브에 대해 생각하게되었습니다. 다음을 확인하십시오.

1. " 파일 시스템에서 루트를위한 공간을 예약했습니다-왜? "
2. " 비 OS 디스크에 대한"파일 시스템 예약 블록 "의 적당한 크기? "

사용중인 inode 수를 줄이려고하는 일부 이전 백업을 .tar.gz하려고합니다.

dummzeuch가 그의 문제에 대한 해결책을 찾았지만 실제로 디스크에 충분한 inode / free 공간이 있고 특정 디렉토리를 전송하는 동안 여전히 "장치에 남은 공간이 없음"을 표시하는 경우가 하나 더 있습니다.

이는 디렉토리 색인 생성이 활성화 된 ext4 파일 시스템으로 포맷 된 블록 장치에서 해시 충돌로 인해 발생합니다. 특히 단일 디렉토리에 100k가 넘는 파일을 호스트하고 파일 이름이 동일한 알고리즘 (캐시 파일, md5sum 파일 이름 등)에서 생성되는 경우 .)

해결책은 다른 디렉토리 인덱싱 알고리즘을 사용하는 것입니다.

tune2fs -E "hash_alg=tea" /dev/blockdev_name

또는 해당 블록 장치에 대해 디렉토리 인덱싱을 완전히 비활성화하려면 (성능이 저하 될 수 있음)

tune2fs -O ^dir_index /dev/blockdev_name

또 다른 해결책은 그러한 파일로 디렉토리를 채우는 것이 무엇인지 확인하고 소프트웨어를 수정하는 것입니다.

가능한 해결책은 파일 용량이 큰 폴더의 내용을 여러 개의 개별 하위 폴더로 분할하는 것입니다.

문제에 대한 자세한 설명은 여기 Axel Wagner에서 제공합니다.

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

건배.

디렉토리 자체에는 2GB 크기 제한이 있습니다. 즉, 디렉토리 크기가 2GB를 초과하는 파일이 너무 많으면 (디렉토리의 파일 크기가 아님) 문제가 발생합니다. 2.8M의 inode 만 사용하면 문제가되지 않습니다. 일반적으로 약 15M inode가 발생합니다.

그래서 이것은별로 도움이되지 않을 수도 있습니다-백업 장치에서 ext4를 사용해보십시오?

sysctl에서 Inotify 감시자 한계를 늘리십시오.

fs.inotify.max_user_watches = 100000 

다시 부팅하거나 그 sysctl -w버전도 수행하십시오 .

보통 그렇게 할 것입니다. 커널에 너무 많은 파일이 열려 있고 오류가 완전히 잘못되었습니다. Dropbox는 이에 대한 전형적인 예입니다.

다른 몇 가지 사항을 확인하는 것이 좋습니다.

1. 임시 디렉토리가 가득 차지 않았는지 확인하십시오. 때때로 중간 저장에 사용되며 쉽게 가득 찰 수 있습니다.
2. 삭제 된 파일에 설명자를 보유하고있는 프로세스가 있는지 확인하십시오. df가 적절한 크기를보고하기 때문에 가능성은 적지 만 여전히 아프지 않습니다.

내 문제에 대한 해결책을 찾는 동안이 주제를 찾았습니다.

실제로 ENOSPC에는 다른 이유가 있습니다. 그리고 ZFS 파일 시스템에서 EXT4 시스템으로 복사하는 동안 rsync를 사용하여 소리 내었습니다.

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

이 경우 :

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr 설명 :

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

필자의 경우 전체 파일 시스템을 다시 포맷해야 함을 의미합니다. :-(