デバイスに十分なスペースがある場合、mv中に断続的な「デバイスにスペースがありません」エラーを修正する方法は？

• デスクトップ上のUbuntu 14.04
• ソースドライブ：/ dev / sda1：5TB ext4シングル
  ドライブボリューム
• ターゲットボリューム：/ dev / mapper / archive-lvarchive：raid6（mdadm）lvm
  パーティションとext4を備えた18TBボリューム

移動するファイルは約1500万個あり、一部は重複している可能性があります（重複を上書きしたくない）。

（ソースディレクトリから）使用されたコマンドは：

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

これは予想どおり数日間続いていますが、頻度を上げるとエラーが発生します。ターゲットドライブの起動時は約70％でしたが、現在は約90％です。以前は約1/200でしたが、現在は約1/5の状態とエラーになります。100Mbを超えるファイルはなく、ほとんどのファイルは約10万です。

いくつかの情報：

$ 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ボリュームがいっぱいになった」などの問題。ただし、ほとんどの場合、ファイルを処理する方法が原因で問題の原因となるサードパーティのソフトウェアを扱っており、それらはすべて一定であり、すべての移動が失敗することを意味します。

ありがとう。

編集：失敗して成功したファイルのサンプルは次のとおりです。

FAILED（まだソースドライブにあります）

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

SUCCEEDED（ターゲットボリューム上）

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を使用するか、またはディセーブル機能（いくつかの注意が必要な、関連リンクを参照ノベル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：ミステリアスな「デバイスに空きスペースがありません」エラー

ext4にはdir_indexという機能がデフォルトで有効になっていますが、これはハッシュ衝突の影響を非常に受けやすくなっています。

......

ext4には、そのコンテンツのファイル名をハッシュする可能性があります。これによりパフォーマンスは向上しますが、「小さな」問題があります。ext4は、いっぱいになり始めてもハッシュテーブルを拡大しません。代わりに、-ENOSPCまたは「デバイスにスペースが残っていません」を返します。

大量の小さなファイルを保存するためのext4よりも優れた選択肢の提案：

オブジェクトストアとしてファイルシステムを使用している場合、他の特性を損なう可能性のある、それを専門とするファイルシステムの使用を検討することをお勧めします。Googleで簡単に検索したところ、Cephが見つかりました。これはオープンソースのようで、POSIXファイルシステムとしてマウントできますが、他のAPIでもアクセスできます。レプリケーションを利用せずに、単一のホストで使用する価値があるかどうかはわかりません。

もう1つのオブジェクトストレージシステムは、OpenStackのSwiftです。その設計ドキュメントによると、各オブジェクトはxattrsのメタデータとともに個別のファイルとして保存されます。ここだそれについての記事。 彼らの展開ガイドによると、XFSがオブジェクトストレージに最高のパフォーマンスをもたらしたことがわかりました。そのため、ワークロードはXFSの得意ではありませんが、RackSpaceがテストを行っていたとき、競合他社より明らかに優れていました。XFSには拡張属性に対する優れた/高速のサポートがあるため、おそらくSwiftはXFSを好むでしょう。追加のメタデータが必要ない場合（またはバイナリファイル内に保持されている場合）、ext3 / ext4はオブジェクトストアバックエンドとして単一ディスク上で正常に動作する可能性があります。

Swiftは複製/負荷分散を行い、RAIDではなく rawディスクで作成されたファイルシステムを提供することを提案します。RAID5のワークロードは本質的に最悪のケースであることを指摘します（小さなファイルの書き込みを伴うワークロードについて話している場合、これは理にかなっています。XFSは通常、それらを頭から尻尾まで詰め込みません。 RAID 5はパリティストライプを更新するためにいくつかの読み取りを行う必要があります。Swiftのドキュメントでは、ドライブごとに100パーティションを使用することについても説明しています。これはSwiftの用語であり、 SATAディスク。

ディスクごとに個別のXFSを実行することは、実際には大きな違いです。1つの巨大な free-inodeマップの代わりに、各ディスクには個別の空きリストを持つ個別のXFSがあります。また、小規模な書き込みに対するRAID5のペナルティを回避します。

ファイルシステムをオブジェクトストアとして直接使用するようにソフトウェアをすでに構築している場合、Swiftのようなものを経由してレプリケーション/負荷分散を処理するのではなく、少なくともすべてのファイルを単一のディレクトリに置くことを避けることができます。（Swiftのドキュメントでは、ファイルを複数のディレクトリにどのようにレイアウトするのかはわかりませんでしたが、確かにそうなっています。）

ほとんどの通常のファイルシステムでは、次のような構造を使用すると役立ちます。

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

おそらく約1万エントリが妥当であるため、オブジェクト名の4文字を十分に分散させてディレクトリとして使用するのは簡単な解決策です。バランスがとれている必要はありません。奇妙な100kディレクトリはおそらく目立った問題ではなく、空のディレクトリもありません。

XFSは、大量の小さなファイルには理想的ではありません。それはできることをしますが、大きなファイルの書き込みをストリーミングするためにより最適化されています。ただし、一般的な使用には全体的に非常に優れています。ENOSPCディレクトリインデックス（AFAIK）の衝突がないため、数百万のエントリを持つ1つのディレクトリを処理できます。（ただし、少なくとも1レベルのツリーを使用することをお勧めします。）

Dave Chinner は、膨大な数のiノードが割り当てられたXFSのパフォーマンスに関するコメントをいくつか持っていたため、touchパフォーマンスが遅くなりました。空きiノードを見つけると、空きiノードビットマップが断片化されるため、より多くのCPU時間を要します。これは、1つの大きなディレクトリと複数のディレクトリの問題ではなく、ファイルシステム全体で使用される多くのiノードの問題であることに注意してください。ファイルを複数のディレクトリに分割すると、OPでext4が詰まったような問題が発生しますが、空き領域を追跡するディスク全体の問題は発生しません。Swiftのディスクごとのファイルシステムは、RAID5上の巨大なXFSと比較して、これに役立ちます。

btrfsがこれで良いかどうかはわかりませんが、そうかもしれません。Facebookは、主な開発者を採用しているのには理由があると思います。：P Linuxカーネルソースの展開など、私が見たベンチマークのいくつかは、btrfsがうまく機能することを示しています。

私はreiserfsがこの場合に最適化されていることを知っていますが、それはほとんど維持されていません。reiser4に行くことは本当にお勧めできません。ただし、実験するのは面白いかもしれません。しかし、これは将来性が最も低い選択肢です。古くなったreiserFSでパフォーマンスが低下したという報告もありますが、最適なデフラグツールはありません。（google filesystem millions of small files、および既存のstackexchangeの回答のいくつかを見てください。）

私はおそらく何かが欠けているので、最終的な推奨事項：serverfaultでこれについて尋ねてください！ 今すぐ何かを選択する必要がある場合は、BTRFSを試してみてください。ただし、バックアップがあることを確認してください。（特に、BTRFSの組み込みの複数ディスク冗長性をRAID上で実行するのではなく使用する場合。読み取り専用のワークロードでない限り、小さなファイルはRAID5にとって悪いニュースであるため、パフォーマンスの利点は大きくなる可能性があります。）

この問題については、私が修正するためにしたことです（以下の手順ではsudoアクセスが必要な場合があります）：

1. iノードの使用済みスペースは100％で、以下のコマンドを使用して取得できます

   df -i /

ファイルシステムiノードIUsed IFree IUse％のマウント

/dev/xvda1            524288   524288  o     100% /

2. 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

3. これで、多数のファイルが含まれるフォルダーにゼロが設定されました。エラーを回避するために、次のコマンドを順番に実行します（私の場合、実際のフォルダーは/ 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 {} +