- デスクトップのUbuntu 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ではない。ワークロードは本質的にRAID 5の最悪のケースであると明記されています（小規模なファイル書き込みを含むワークロードについて話す場合は意味があります）。 XFSは通常、最初から最後まで完全に圧縮しないため、取得する必要はありません。フルストライプ書き込みとRAID5は、パリティストライプを更新するためにいくつかの読み取りを実行する必要があります。また、Swiftのドキュメントでは、ドライブごとに100個のパーティションを使用する方法についても説明します。これはSwiftの用語であり、各ドライブで議論されていないようです。
各ディスクに対して別々のXFSを実行すると、実際に大きな違いが発生します。。巨大な無料の inode マッピングの場合、各ディスクには個別の XFS と個別の使用可能なリストがあります。また、小規模書き込み時のRAID5の損失を防ぎます。
Swiftのようなものを使用してレプリケーション/ロードバランシングを処理するのではなく、ファイルシステムをオブジェクトストレージとして直接使用するソフトウェアを構築した場合は、少なくともすべてのファイルを1つのディレクトリに配置することを回避できます。 （ファイルを複数のディレクトリに配置する方法を説明するSwiftドキュメントは見えませんが、そうなると確信しています。）
ほとんどすべての一般的なファイルシステムでは、同様の構造を使用すると役立ちます。
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
約10,000個の項目が適切である可能性があるため、均等な間隔の4文字のオブジェクト名を取得し、それをディレクトリとして使用するのが簡単な解決策です。完全にバランスを取る必要はありません。奇妙な100,000のディレクトリはおそらく明らかな問題ではないでしょうし、いくつかの空のディレクトリも問題ではありません。
XFS多数の小さなファイルには適していません。これはできることですが、より大きなファイルのストリーミング書き込みに最適化されています。それでも一般的に使用するのはかなり大丈夫です。ENOSPCそのディレクトリインデックスは（私が知る限り）競合がなく、何百万ものエントリがあるディレクトリを処理できます。 （しかし、少なくとも1つのツリーレイヤーを使用することをお勧めします。）
デイブチナー大規模なinode割り当て時のXFSパフォーマンスに関するいくつかのコメントその結果、パフォーマンスが低下しますtouch。割り当てる空き inode を見つけるには、空き inode ビットマップが断片化されるため、CPU の時間がかかり始めます。これは、1つの大きなディレクトリと複数のディレクトリの問題ではなく、ファイルシステム全体で使用される多くのinodeの問題です。ファイルを複数のディレクトリに分割すると、OPのext4ブロックの問題など、いくつかの問題を解決するのに役立ちますが、空き領域を追跡するディスク全体の問題は解決されません。 Swiftのディスクごとの別々のファイルシステムは、RAID5の巨大なXFSと比較してこの問題を解決するのに役立ちます。
わからないBTFSかなり上手ですが、そうかもしれません。 Facebookが上級開発者を雇う理由はあると思います。 ：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
- これで、多くのファイルを含むフォルダにそのファイルをゼロにしました。エラーを回避するには、次のコマンドを順番に実行します（私の場合、実際のフォルダは/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 {} +