デバイスに十分なスペースがある場合、MV中に断続的な「デバイスにスペースが残っていません」エラーを修正する方法
- デスクトップ上のUbuntu 14.04
- ソースドライブ：/ dev/sda1：5TB ext4シングル
ドライブボリューム - ターゲットボリューム：/ dev/mapper/archive-lvarchive：raid6（mdadm）18TBボリューム、lvm付き
パーティションとext4
移動するファイルは約1500万あり、一部は重複している可能性があります（重複を上書きしたくない）。
（ソースディレクトリから）使用されたコマンドは次のとおりです。
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
このエラーに関するたくさんの投稿を見つけましたが、予後は適合しません。 「ドライブが実際にいっぱいです」、「iノードが不足しています」、「/ 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
Ext4機能の実装のバグdir_index宛先ファイルシステムで使用しています。
解決策：dir_indexなしでファイルシステムを再作成します。または、tune2fsを使用して機能を無効にします（注意が必要です。関連リンクを参照してください Novell SuSE 10/11：ext3ファイルシステムでのHツリーインデックスの無効化 これは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のクイック検索で Ceph が見つかりました。これはオープンソースのようで、POSIXファイルシステムとしてマウントできますが、他のAPIでもアクセスできます。レプリケーションを利用せずに、単一のホストで使用する価値があるかどうかはわかりません。
別のオブジェクトストレージシステムはOpenStackのSwiftです。その設計ドキュメントでは、 xattrs にメタデータを含む個別のファイルとして各オブジェクトを保存すると記述しています。 。 それに関する記事があります。 彼らの 導入ガイド は、XFSがオブジェクトストレージに最高のパフォーマンスを提供することを発見したと述べています。したがって、ワークロードはXFSとは異なりますRackSpaceが物事をテストしていたとき、それは競合他社より明らかに優れていたようです。おそらくSwiftは、XFSが拡張属性を適切に/高速でサポートしているため、XFSを支持します。ext3/ ext4は追加のメタデータが必要ない場合（またはバイナリファイル内に保持されている場合）は、オブジェクトストアバックエンドとして単一のディスクで使用できます。
Swiftはレプリケーション/ロードバランシングを実行し、ファイルシステムをrawディスク上に作成することを推奨しますnot RAID。それは、そのワークロードがRAID5の本質的に最悪のケースであることを指摘します（小さなファイルの書き込みを伴うワークロードについて話している場合、これは理にかなっています。XFSは通常、それらを完全にパックしていないため、フルストライプ書き込みを取得し、RAID5はパリティストライプを更新するためにいくつかの読み取りを実行する必要があります。Swift docsは、ドライブごとに100パーティションを使用することについても話します。これはSwift用語であり、各SATAディスク上に100の異なるXFSファイルシステムを作成することについて話しているのではありません。
ディスクごとに個別のXFSを実行することは、実際には大きな違いです。 1つのgigantic空きiノードマップの代わりに、各ディスクには個別の空きリストを持つ個別のXFSがあります。また、小規模な書き込みに対するRAID5のペナルティを回避します。
Swiftのように複製/負荷分散を処理するのではなく、ファイルシステムを直接オブジェクトストアとして使用するようにソフトウェアを構築している場合は、少なくともすべてを回避することができます。ファイルを1つのディレクトリに格納します（Swift docsには、ファイルを複数のディレクトリに配置する方法は記載されていませんが、確かにそうです）。
ほとんどすべての通常のファイルシステムでは、次のような構造を使用すると役立ちます
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
おそらく約10kのエントリが妥当であるため、オブジェクト名を適切に分散した4文字にして、それらをディレクトリとして使用することは簡単な解決策です。非常にバランスが取れている必要はありません。奇数の100kディレクトリはおそらく目立つ問題ではなく、空のディレクトリもありません。
[〜＃〜] xfs [〜＃〜]は、大きなファイルの小さなファイルには理想的ではありません。できることはしますが、より大きなファイルの書き込みをストリーミングするためにより最適化されています。ただし、一般的には全体的に非常に優れています。ディレクトリインデックス（AFAIK）の衝突時にENOSPCがなく、数百万のエントリを持つ1つのディレクトリを処理できます。 （ただし、少なくとも1レベルのツリーを使用することをお勧めします。）
Dave Chinnerが XFSのパフォーマンスについてコメントし、膨大な数のiノードが割り当てられている の結果、touchのパフォーマンスが遅くなりました。割り当てられる空きiノードを見つけると、空きiノードビットマップが断片化されるため、より多くのCPU時間がかかります。これは1つの大きなディレクトリと複数のディレクトリの問題ではなく、ファイルシステム全体で使用される多くのiノードの問題であることに注意してください。ファイルを複数のディレクトリに分割すると、ext4がOPで詰まったようないくつかの問題に役立ちますが、空き領域を追跡するというディスク全体の問題には役立ちません。 RAID5上の巨大なXFSと比較して、Swiftのディスクごとの個別のファイルシステムはこれに役立ちます。
btrfsがこれが得意かどうかはわかりませんが、そうかもしれません。 Facebookにはその理由で主任開発者を採用していると思います。 ：P Linuxカーネルソースの解凍などのベンチマークで、btrfsがうまく機能することを確認しました。
私はreiserfsがこのケースのために最適化されたことを知っていますが、それがたとえあったとしても、ほとんど維持されていません。私は本当にreiser4で行くことをお勧めできません。しかし、実験するのは興味深いかもしれません。しかし、これは、最も将来性のない選択肢です。古いreiserFSでパフォーマンスが低下するという報告もあり、適切なデフラグツールはありません。 （グーグルfilesystem millions of small files、および既存のstackexchange回答のいくつかを見てください。）
私はおそらく何かが足りないので、最終的な推奨事項：serverfaultでこれについて尋ねてください！ 今すぐ何かを選択する必要がある場合、BTRFSを試してみると思いますが、バックアップがあることを確認してください。 （特に、BTRFSの組み込みの複数ディスク冗長性をRAID上で実行するのではなく使用する場合。小さなファイルはRAID5にとって悪いニュースであるので、ほとんどが読み取りのワークロードでない限り、パフォーマンスの利点は大きくなる可能性があります。）
以下のこの問題については、私が修正したものです（以下の手順ではSudoアクセスが必要になる場合があります）：
Inodesの使用済みスペースは100％で、以下のコマンドを使用して取得できます
df -i /
IUsed IFree IUse％がマウントされたファイルシステムのiノード
/dev/xvda1 524288 524288 o 100% /
- INotedを解放する必要があるため、以下のコマンドを使用して、ここにiノードの数があるファイルを見つける必要があります。
これが次のiノードの問題かどうかを確認してください。
df -ih
Iノード数が多いルートフォルダを見つけてください。
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 {} +