- 데스크탑의 우분투 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 미만이며 대부분은 약 100,000입니다.
몇가지 정보:
$ 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
이 오류에 대한 많은 게시물을 찾았지만 예측이 적절하지 않습니다. "드라이브가 실제로 꽉 찼습니다", "inode가 부족합니다" 또는 "/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
dir_index대상 파일 시스템에서 사용 중인 ext4 기능 구현에 버그가 있습니다.
해결책: dir_index 없이 파일 시스템을 다시 생성하십시오. 또는 tune2fs를 사용하여 기능을 비활성화합니다(몇 가지 주의 사항이 필요합니다. 관련 링크 참조)Novell SuSE 10/11: ext3 파일 시스템에서 H-트리 인덱싱 비활성화여기에는외부 3비슷한 주의가 필요할 수도 있습니다.
(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 또는 "장치에 남은 공간이 없습니다"를 반환합니다.
답변2
많은 수의 작은 파일을 저장하기 위한 ext4보다 더 나은 옵션에 대한 제안:
파일 시스템을 객체 스토리지로 사용하는 경우 이에 특화된 파일 시스템을 사용하는 것이 좋습니다. 이로 인해 다른 기능이 손상될 수 있습니다. 빠른 Google 검색 공개세팔로스포린는 오픈 소스로 보이며 POSIX 파일 시스템으로 설치될 수 있고 다른 API를 통해서도 액세스할 수 있습니다. 복제를 활용하지 않고 단일 호스트에서 그만한 가치가 있는지 모르겠습니다.
또 다른 객체 스토리지 시스템은오픈스택 스위프트. 디자인 문서에 그렇게 적혀 있어요xattrs에 메타데이터가 포함된 별도의 파일로 각 객체를 저장합니다.. 이것은그것에 관한 기사. 그들의배포 가이드그들은 XFS가 객체 스토리지에 최고의 성능을 제공한다는 사실을 발견했다고 밝혔습니다. 따라서 작업 부하가 XFS가 가장 잘하는 것은 아니지만 RackSpace에서 테스트했을 때 경쟁 제품보다 확실히 더 나았습니다. Swift는 확장된 속성에 대한 훌륭하고 빠른 지원으로 인해 XFS를 선호할 수 있습니다. 추가 메타데이터가 필요하지 않은 경우(또는 바이너리 파일에 보관된 경우) ext3/ext4는 단일 디스크의 객체 스토리지 백엔드로 잘 작동할 수 있습니다.
Swift는 복제/로드 밸런싱을 수행하고 원본 디스크에 생성된 파일 시스템을 제공할 것을 권장합니다.RAID가 아님. 워크로드는 본질적으로 RAID5의 최악의 경우라고 명시되어 있습니다(소규모 파일 쓰기가 포함된 워크로드에 대해 이야기하는 경우 의미가 있음). XFS는 일반적으로 처음부터 끝까지 이를 완전히 압축하지 않으므로 얻을 필요가 없습니다. 전체 스트라이프 쓰기 및 RAID5는 패리티 스트라이프를 업데이트하기 위해 일부 읽기를 수행해야 합니다. 또한 Swift 문서에서는 드라이브당 100개의 파티션을 사용하는 것에 대해 설명합니다. 이는 Swift 용어이며 각 드라이브에서 논의되지 않은 것 같습니다.
각 디스크에 대해 별도의 XFS를 실행하면 실제로 큰 차이가 발생합니다..거대한무료 inode 매핑의 경우 각 디스크에는 별도의 XFS와 별도의 사용 가능 목록이 있습니다. 또한 소규모 쓰기 시 RAID5 손실을 방지합니다.
Swift와 같은 것을 통해 복제/로드 밸런싱을 처리하는 대신 파일 시스템을 객체 스토리지로 직접 사용하는 소프트웨어를 구축했다면 적어도 모든 파일을 하나의 디렉터리에 두는 것을 피할 수 있습니다. (파일을 여러 디렉터리에 배치하는 방법을 설명하는 Swift 문서는 보이지 않지만, 그럴 것이라고 확신합니다.)
거의 모든 일반 파일 시스템의 경우 유사한 구조를 사용하면 도움이 됩니다.
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
약 10,000개의 항목이 적절할 수 있으므로 균등한 간격의 4자 개체 이름을 가져와 이를 디렉터리로 사용하는 것이 간단한 해결책입니다. 완벽하게 균형을 이룰 필요는 없습니다. 이상한 100,000개 디렉토리는 아마도 명백한 문제가 아닐 것이며 일부 빈 디렉토리도 문제가 되지 않을 것입니다.
XFS많은 수의 작은 파일에는 적합하지 않습니다. 할 수 있는 작업을 수행하지만 더 큰 파일의 스트리밍 쓰기에 더 최적화되어 있습니다. 그래도 일반적으로 사용하기에는 꽤 괜찮습니다. ENOSPC해당 디렉토리 색인은 (내가 아는 한) 충돌이 없으며 수백만 개의 항목이 있는 디렉토리를 처리할 수 있습니다. (그러나 적어도 하나의 트리 레이어를 사용하는 것이 좋습니다.)
데이브 치너대규모 inode 할당 시 XFS 성능에 대한 일부 의견결과적으로 성능이 저하됩니다 touch. 할당할 여유 inode를 찾는 데는 여유 inode 비트맵이 조각화되기 때문에 CPU 시간이 더 많이 걸리기 시작합니다. 이는 하나의 큰 디렉터리와 여러 디렉터리의 문제가 아니라 전체 파일 시스템에서 사용되는 많은 inode의 문제입니다. 파일을 여러 디렉터리로 분할하면 OP의 ext4 차단 문제와 같은 일부 문제를 해결하는 데 도움이 되지만 여유 공간을 추적하는 전체 디스크 문제는 해결되지 않습니다. Swift의 디스크당 별도 파일 시스템은 RAID5의 거대한 XFS와 비교하여 이 문제를 해결하는 데 도움이 됩니다.
나는 모른다BTFS꽤 잘하는데 그럴 수도 있을 것 같아요. 페이스북이 수석 개발자를 고용하는 데에는 이유가 있다고 생각합니다. :P Linux 커널 소스 코드 압축 풀기 등 제가 본 일부 벤치마크에서는 btrfs가 잘 작동하는 것으로 나타났습니다.
알아요레이셀프스이 상황에 맞게 최적화되었지만 더 이상 유지 관리되는 경우가 거의 없습니다. 나는 reiser4를 사용하는 것을 정말로 권장하지 않습니다. 그래도 시도해 보는 것은 재미있을 것입니다. 그러나 이는 미래에 대한 보장이 가장 적은 옵션입니다. 또한 노후화된 reiserFS로 인해 성능이 저하되고 좋은 조각 모음 도구가 없다는 보고도 본 적이 있습니다. (Google에서 filesystem millions of small files기존 stackexchange 답변을 확인하세요.)
제가 놓친 부분이 있을 수도 있으니최종 제안: serverfault에 대해 이 질문을 해보세요! 지금 당장 무엇인가를 선택해야 한다면 BTRFS를 시도해 보되 백업이 있는지 확인하십시오. (특히 RAID 위에서 실행하는 대신 BTRFS의 내장 다중 디스크 중복성을 사용하는 경우 성능 이점이 클 수 있습니다. 읽기 중심의 기본 워크로드가 아닌 이상 작은 파일은 RAID5에 나쁜 소식이기 때문입니다.)
답변3
이 문제에 대해 제가 수정한 방법은 다음과 같습니다(다음 단계를 수행하려면 sudo 액세스가 필요할 수 있음).
Inode의 사용된 공간은 100%이며 다음 명령을 사용하여 검색할 수 있습니다.
df -i /
파일 시스템 인덱스 노드 IUsed IFree IUse%가 다음에 설치되어 있습니다.
/dev/xvda1 524288 524288 o 100% /
- iNoted를 릴리스해야 하므로 다음을 사용하여 이 i-노드 수가 포함된 파일을 찾아야 합니다.
이것이 inode 문제인지 알아보십시오.
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
- 이제 많은 파일이 포함된 폴더에 해당 파일을 0으로 만들었습니다. 오류를 방지하려면 다음 명령을 순서대로 실행하세요(제 경우 실제 폴더는 /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 {} +