- 데스크탑의 우분투 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
답변
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 또는 “장치에 남은 공간 없음”을 반환합니다.
답변
대량의 작은 파일을 저장하기 위해 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에 대해 나쁜 소식이기 때문에 성능상의 이점이 클 수 있습니다.
답변
아래이 문제의 경우 내가 해결 한 것입니다 (아래 단계에 대해 sudo 액세스가 필요할 수 있음).
-
Inode의 사용 된 공간은 100 %였으며 아래 명령을 사용하여 검색 할 수 있습니다.
df -i /
파일 시스템 아이 노드 사용 IFree IUse % Mounted on
/dev/xvda1 524288 524288 o 100% /
- 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
- 이제 많은 파일이 들어있는 폴더로 넘어갔습니다. 오류를 피하기 위해 아래 명령을 차례로 실행하십시오 (내 경우 실제 폴더는 / 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 {} +