장치에 충분한 공간이있을 때 mv 동안 간헐적 인 "장치에 남은 공간 없음"오류를 수정하는 방법?


21
  • 데스크탑의 우분투 14.04
  • 소스 드라이브 : / dev / sda1 : 5TB ext4 단일
    드라이브 볼륨
  • 대상 볼륨 : / dev / mapper / archive-lvarchive : lvm
    파티션 및 ext4가있는 raid6 (mdadm) 18TB 볼륨

이동할 파일은 약 1,500 만 개이며 일부는 복제본 일 수 있습니다 (중복 본을 덮어 쓰고 싶지 않습니다).

(소스 디렉토리에서) 사용 된 명령은 다음과 같습니다.

ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}

예상대로 며칠 동안 진행되었지만 빈도 증가에 오류가 있습니다. 대상 드라이브가 시작될 때 약 70 %가 찼으며 이제는 약 90 %입니다. 예전 동작의 약 1/200은 상태와 오류였으며 이제는 약 1/5입니다. 100Mb를 초과하는 파일이 없으며 대부분 약 100k입니다.

일부 정보 :

$ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/sdb3                      155G  5.5G  142G   4% /
none                           4.0K     0  4.0K   0% /sys/fs/cgroup
udev                           3.9G  4.0K  3.9G   1% /dev
tmpfs                          797M  2.9M  794M   1% /run
none                           5.0M  4.0K  5.0M   1% /run/lock
none                           3.9G     0  3.9G   0% /run/shm
none                           100M     0  100M   0% /run/user
/dev/sdb1                       19G   78M   18G   1% /boot
/dev/mapper/archive-lvarchive   18T   15T  1.8T  90% /mnt/archive
/dev/sda1                      4.6T  1.1T  3.3T  25% /mnt/tmp

$ df -i
Filesystem                       Inodes    IUsed     IFree IUse% Mounted on
/dev/sdb3                      10297344   222248  10075096    3% /
none                            1019711        4   1019707    1% /sys/fs/cgroup
udev                            1016768      500   1016268    1% /dev
tmpfs                           1019711     1022   1018689    1% /run
none                            1019711        5   1019706    1% /run/lock
none                            1019711        1   1019710    1% /run/shm
none                            1019711        2   1019709    1% /run/user
/dev/sdb1                       4940000      582   4939418    1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539   16% /mnt/archive
/dev/sda1                     152621056  5391544 147229512    4% /mnt/tmp

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

mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf 
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf 
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf 
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf 
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd

이 오류에 대한 게시물이 많이 발견되었지만 예후가 맞지 않습니다. "드라이브가 실제로 가득 찼습니다"또는 "아이 노드가 부족합니다"또는 "/ boot 볼륨이 가득 찼습니다"와 같은 문제. 그러나 대부분 타사 소프트웨어는 파일을 처리하는 방식으로 인해 문제를 일으키는 타사 소프트웨어를 다루며 모두 일정하므로 모든 이동이 실패합니다.

감사.

편집 : 다음은 샘플 실패 및 성공 파일입니다.

실패 (아직 소스 드라이브에 있음)

ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf

성공 (대상 볼륨에서)

ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf

또한 모든 파일이 실패하는 것은 아니지만 실패한 파일은 항상 실패합니다. 반복해서 다시 시도하면 일관성이 있습니다.

편집 : @mjturner의 요청 당 몇 가지 추가 명령

$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir

$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/archive
Filesystem UUID:          af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              289966080
Block count:              4639456256
Reserved block count:     231972812
Free blocks:              1274786115
Free inodes:              256343444
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        512
Flex block group size:    16
Filesystem created:       Thu Jun 25 12:05:12 2015
Last mount time:          Mon Aug  3 18:49:29 2015
Last write time:          Mon Aug  3 18:49:29 2015
Mount count:              8
Maximum mount count:      -1
Last checked:             Thu Jun 25 12:05:12 2015
Check interval:           0 (<none>)
Lifetime writes:          24 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup:           inode blocks

$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/tmp
Filesystem UUID:          10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              152621056
Block count:              1220942336
Reserved block count:     61047116
Free blocks:              367343926
Free inodes:              135953194
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      732
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Thu Jul 23 13:54:13 2015
Last mount time:          Tue Aug  4 04:35:06 2015
Last write time:          Tue Aug  4 04:35:06 2015
Mount count:              3
Maximum mount count:      -1
Last checked:             Thu Jul 23 13:54:13 2015
Check interval:           0 (<none>)
Lifetime writes:          150 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup:           inode blocks

파일이 여러 디렉토리에 복사되고 있거나 단일 대상 디렉토리에 1.5M 파일을 쓰려고합니까?
스누피

1.5m, 15m 및 그렇습니다. 모두 같은 디렉토리에 있지 않습니다. 실제로 거기에는 이미 40m가 넘고 총 30m가 더 있습니다.
Chris.Calwell 1

오, 무작위 다운 트롤 트롤이 다시 강타했다. 왜 당신이 downvote를 언급해야한다고 생각하지 않습니까?
Chris.Caldwell

1
다운 투표는 아마도 프로그래밍과 관련이 없기 때문에 귀하의 질문이 Unix.stackexchange 또는 askubuntu에 더 적합하기 때문일 수 있습니다. 태그에 프로그래밍 언어가 없으면 투표율이 떨어질 수 있습니다.
technosaurus

@Chris-SF의이 문제와 비슷한 것 같습니다 : serverfault.com/questions/384541/…
스누피

답변:


25

dir_index대상 파일 시스템에서 사용중인 ext4 기능 구현의 버그

해결책 : dir_index없이 filesytem을 다시 만드십시오. 또는 비활성화 기능 몇 가지주의 사항은 관련 링크를 참조하십시오 요구 (tune2fs를 사용하여 ext3로 파일 시스템 사용 안 함 H-트리 색인 : 노벨 수세 10/11을 관련 있지만, EXT3 유사한주의가 필요합니다.

(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)

ext4에는 기본적으로 dir_index라는 기능이 있으며 해시 충돌에 매우 취약합니다.

......

ext4는 내용의 파일 이름을 해시 할 수 있습니다. 이렇게하면 성능이 향상되지만 "작은"문제가 있습니다. ext4는 채워지기 시작할 때 해시 테이블을 늘리지 않습니다. 대신 -ENOSPC 또는 "장치에 남은 공간 없음"을 반환합니다.


3
헛소리, 정확히 똑같이 들리고 고치는 완전한 고통처럼. 다시 복사하는 데 약 한 달이 걸립니다. 내용을 잃지 않고이 작업을 수행 할 수 있습니까? 내일 dir_index 등을 더 연구해야합니다. 와우, 그런 생각은하지 않았을거야
Chris.Caldwell

tune2fs 명령을 추가하여 인덱스를 사용하지 않도록 설정했습니다.
steve

6
@steve를 잘 발견했습니다. 불행히도 끄면 dir_index한 디렉토리에 70m 파일의 액세스 성능이 저하 될 수 있습니다.
mjturner

3
네. 최고의 성능이 필요하지는 않지만 각 파일에 대한 fs 검색은 끔찍합니다. 이제 xfs 또는 10k 정도의 하위 폴더 배열을보고 있습니다. 하위 폴더는 합리적인 솔루션이지만 ext4에서는 여전히 충돌의 위험이 있습니다. xfs는 같은 문제로 고생합니까? 나는 그것이 B + 트리를 사용한다는 것을 읽었지만 충돌이 일어나지 않는 한 나에게는 그다지 의미가 없습니다. 잘못된 정보의 세계가 있으며, 파일이 백만 개가 넘는 파일 속도가 느리다는 주장과 그렇지 않은 주장을 들었습니다.
Chris.Caldwell

2
나는 이것이 훌륭한 답변이라고 생각하고 그것을 그렇게 표시하고 싶지만 진단뿐만 아니라 수정을 할 수 있다면 좋을 것이라고 생각합니다. xfs가 이와 같은 문제로 고통 받고 있는지 아는 사람이 있습니까? 나는 1m를 넘지 않거나 잘 확장되는 혼합 리뷰를 읽었습니다.
Chris.Caldwell

8

대량의 작은 파일을 저장하기 위해 ext4보다 나은 선택을위한 제안 :

파일 시스템을 객체 저장소로 사용하는 경우 파일 시스템을 전문으로하는 파일 시스템을 사용하여 다른 특성을 손상시킬 수 있습니다. 빠른 Google 검색에서 오픈 소스 인 것처럼 보이고 POSIX 파일 시스템으로 마운트 될 수 있지만 다른 API로 액세스 할 수있는 Ceph를 발견했습니다 . 복제를 이용하지 않고 단일 호스트에서 사용할 가치가 있는지 모르겠습니다.

다른 객체 저장 시스템은 OpenStack 's Swift 입니다. 디자인 문서에 따르면 각 객체는 별도의 파일로 메타 데이터와 함께 xattrs로 저장 됩니다. 여기에 관한 기사가 있습니다. 그들의 구축 가이드 는 XFS가 객체 스토리지에 최고의 성능을 제공한다는 것을 발견했습니다. 따라서 워크로드가 XFS가 가장 좋은 것은 아니지만 RackSpace가 테스트 할 때 경쟁사보다 훨씬 낫습니다. XFS는 확장 된 속성을 잘 / 빠르게 지원하기 때문에 Swift가 XFS를 선호 할 수 있습니다. 추가 메타 데이터가 필요하지 않거나 이진 파일 내에 보관 된 경우 ext3 / ext4가 단일 디스크에서 객체 저장소 백엔드로 제대로 작동 할 수 있습니다.

Swift는 복제 /로드 밸런싱을 수행하며 RAID가 아닌 원시 디스크로 만들어진 파일 시스템을 제공 할 것을 제안합니다 . RAID5의 워크로드는 본질적으로 최악의 경우입니다 (작은 파일을 쓰는 워크로드에 대해 이야기하는 경우에 적합합니다). XFS는 일반적으로 파일을 헤드 투 테일로 포장하지 않기 때문에 전체 스트라이프 쓰기를 받고 RAID5는 패리티 스트라이프를 업데이트하기 위해 약간의 읽기를 수행해야하며, Swift 문서는 드라이브 당 100 개의 파티션 사용에 대해 이야기하고 있습니다. SATA 디스크.

모든 디스크에 대해 별도의 XFS를 실행하는 것은 실제로 큰 차이가 있습니다. 하나의 거대한 free-inode 맵 대신 , 각 디스크에는 별도의 free-list를 가진 별도의 XFS가 있습니다. 또한 작은 쓰기에 대한 RAID5 페널티를 피합니다.

복제 /로드 밸런싱을 처리하기 위해 Swift와 같은 것을 거치지 않고 파일 시스템을 객체 저장소로 직접 사용하도록 소프트웨어를 이미 구축 한 경우 최소한 하나의 디렉토리에 모든 파일이있는 것을 피할 수 있습니다. (Swift 문서에서 파일을 여러 디렉토리에 배치하는 방법을 말하지는 않았지만 확실합니다.)

거의 모든 일반 파일 시스템에서는 다음과 같은 구조를 사용하는 데 도움이됩니다.

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

아마도 약 10k 항목이 합리적이므로 개체 이름을 잘 분배 한 4 문자를 가져 와서 디렉토리로 사용하는 것이 쉬운 해결책입니다. 균형이 잘 잡힐 필요는 없습니다. 홀수 100k 디렉토리는 눈에 띄는 문제가 아니며 빈 디렉토리도 아닙니다.

XFS 는 대량의 작은 파일에는 적합하지 않습니다. 가능한 기능을 수행하지만 더 큰 파일의 쓰기 작업을 스트리밍하는 데 더 최적화되어 있습니다. 그러나 일반적인 용도로는 전반적으로 매우 좋습니다. ENOSPC디렉토리 인덱싱 (AFAIK)에서 충돌이 발생 하지 않으며 수백만 개의 항목이있는 하나의 디렉토리를 갖는 것을 처리 할 수 ​​있습니다. (그러나 적어도 한 수준 트리를 사용하는 것이 좋습니다.)

Dave Chinner 는 많은 수의 inode가 할당 된 XFS 성능에 대해 언급하여 성능이 느려졌 touch습니다. 사용 가능한 inode 비트 맵이 조각화됨에 따라 할당 할 사용 가능한 inode를 찾으면 더 많은 CPU 시간이 걸립니다. 이것은 하나의 큰 디렉토리 대 여러 디렉토리의 문제가 아니라 전체 파일 시스템에서 많은 inode가 사용되는 문제입니다. 파일을 여러 디렉토리로 분할하면 OP에서 ext4가 막혔던 것과 같은 일부 문제를 해결할 수 있지만 사용 가능한 공간을 추적하는 전체 디스크 문제는 아닙니다. Swift의 디스크 당 별도의 파일 시스템은 RAID5의 거대한 XFS와 비교할 때 도움이됩니다.

btrfs 가 이것에 능숙한 지 모르겠지만 그럴 수도 있습니다. 필자는 Facebook이 이유로 주요 개발자를 고용하고 있다고 생각합니다. : P Linux 커널 소스를 untarring하는 것과 같은 일부 벤치 마크에서 btrfs가 잘 작동한다는 것을 보여줍니다.

나는 reiserfs 가이 경우에 최적화되어 있다는 것을 알고 있지만, 더 이상 거의 유지되지 않습니다. 나는 reiser4와 함께 갈 것을 권장하지 않습니다. 그러나 실험하는 것이 흥미로울 수 있습니다. 그러나 그것은 미래에 가장 안전한 선택입니다. 또한 오래된 reiserFS의 성능 저하에 대한보고를 보았으며 조각 모음 도구가 없습니다. (Google filesystem millions of small files및 기존 스택 교환 답변 중 일부를 살펴보십시오.)

아마도 뭔가 빠졌을 것이므로 최종 권장 사항은 serverfault에서 이것에 대해 문의하십시오! 지금 바로 무언가를 선택해야한다면 BTRFS를 사용해 보라고하지만 백업이 있는지 확인하십시오. (예를 들어 RAID 위에서 실행하는 대신 BTRFS의 내장 다중 디스크 중복성을 사용하는 경우 작은 파일이 RAID5에 대해 나쁜 소식이기 때문에 성능상의 이점이 클 수 있습니다.


1
정말 고마워. 많은 사람들이 하위 폴더를 사용하는 것을 보았으며 실제로 몇 년 전에 다른 설정에서 해당 유형의 솔루션을 사용했지만 다른 계층은 피하기를 희망했습니다. 그러나 그렇게하는 데 따른 오버 헤드는이 목적을 위해 작동하는 fs를 찾는 것보다 훨씬 적습니다. RE : XFS는 무릎 통증이 자주 제기 된 이후 많은 파일에서 너무 나쁘다는 놀라운 사실입니다. BTRFS, 위키 : "디렉토리 항목은 디렉토리 항목으로 표시되며 오른쪽 키 값은 파일 이름의 CRC32C 해시입니다." 우리와 같은 문제가 아닌가?
Chris.Caldwell

@ Chris.Caldwell : 확인해야하지만 BTRFS가 ENOSPC가 아닌 동일한 해시 버킷에서 여러 항목을 지원하여 해시 충돌을 처리한다고 가정합니다. 파일 시스템에서 별도의 파일 대신 데이터베이스에 물건을 보관하는 것에 대해 생각 했습니까? 이런 종류의 데이터를 처리하기 위해 시스템을 구축 할 필요가 없었습니다. 나는 XFS를 사용하는데, 이것은 내가 비디오를 저장하는데 사용하는 것 (범용 유닉스 소스 코드와 것들을 저장하는 것)에 좋습니다.
Peter Cordes

1
파일 시스템 설계 방식에 따라 디렉토리 수준은 오버 헤드가 적습니다. 작은 테이블에서 두 번의 빠른 조회는 최적화 된 것보다 많은 데이터를 저장하는 오버 플로우 테이블에서 한 번의 느린 조회보다 빠릅니다. 내가 말했듯이, 디렉토리에 파일을 완벽하게 배포 할 필요가 없으므로 파일 이름의 처음 4자를 가져 와서을 삽입하면 /됩니다. 코드의 많은 부분에 영향을 미치지 않기를 바랍니다. (으로 새 파일 작성에 실패한 경우 디렉토리를 작성해야합니다 ENOENT). 다른 파일 시스템이 있는지 serverfault에 문의하십시오.
Peter Cordes

@ Chris.Caldwell :이 답변을 관련이있는 질문에 실제로 복사해야합니다. 기존의 몇 가지가 있습니다. 객체 저장에 사용할 "추정 된"것이 무엇인지 궁금해서 Swift에 대한 문서를 발견했습니다. 분명히 객체를 XFS에 별도의 파일로 저장하지만 RAID가 아닌 각 디스크에 대해 별도의 XFS를 사용합니다. 중복 자체를 처리합니다.
Peter Cordes

1

아래이 문제의 경우 내가 해결 한 것입니다 (아래 단계에 대해 sudo 액세스가 필요할 수 있음).

  1. Inode의 사용 된 공간은 100 %였으며 아래 명령을 사용하여 검색 할 수 있습니다.

    df -i /

파일 시스템 아이 노드 사용 IFree IUse % Mounted on

/dev/xvda1            524288   524288  o     100% /
  1. iNoted를 비워야하므로 아래 명령을 사용하여 여기에 i 개의 노드가있는 파일을 찾아야합니다.

이것이 다음과 같은 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
  1. 이제 많은 파일이 들어있는 폴더로 넘어갔습니다. 오류를 피하기 위해 아래 명령을 차례로 실행하십시오 (내 경우 실제 폴더는 / var / spool / clientmqueue).
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.