私のデータで何が起こっているのかを確認しようとしています。
歴史に入る前に、これら2つの出力の違いを説明できる人はいますか？
# du --si /var/media/footage/k0/09/99/88
1.6G /var/media/footage/k0/09/99/88
そして
ls -ltr /var/media/footage/k0/09/99/88
total 1501128
-rw-r--r-- 1 root root 0 Mar 9 16:38 k0099988-4k.mov
-rw-r--r-- 1 root root 0 Mar 10 15:57 k0099988-hd.mov
-rw-r--r-- 1 root root 0 Mar 10 15:58 k0099988-preview.mp4
-rw-r--r-- 1 root root 0 Mar 10 15:58 k0099988-wmprev.mp4
-rw-r--r-- 1 root root 0 Mar 10 15:58 k0099988-thumb.mp4
du1.6Gbを報告するのにすべてのファイルが0バイトであるのはなぜですか？
歴史 ストレージシステムから次のメッセージを受信しました。 「ボリュームに書き込み不可能な書き込みストレージキャッシュデータがあります。（ディスクグループ：不明な名前、ボリューム：不明な名前、SN：00c0ff287a86000004815a5901000000）キャッシュスペースの1％を占めます。」
LVMボリューム（123Tb）がオフラインになった直後です。ボリュームを再マウントするには、サーバーを再起動する必要があります。これを行ったところ、何千ものファイルサイズが0バイトであることがわかりました。 LVMボリュームは、101Tbと23Tbの2つのPVで構成されています。最近追加された後、23Tb PVにあると思われる最新のファイルが破損の影響を受けるようです。ファイル自体はディスクに書き込まれ、ほとんどアクセスされません。アクセスすると読み取り専用です。ファイルシステムへのほとんどのアクセスはNFS経由のROです。
一ヶ月前までも同様の出来事があったが、被害は少なかった。プライマリストレージシステム（HP MSA）では問題は報告されていません。
一晩ボリュームを確認しましたが、xfs_check12時間後も継続実行中で停止しました。何も変わらなかった。
バックアップを確認する必要がありますか？それとも私のデータを回復するための魔法はありますか？ファイルシステムの問題ですか、それともハードウェアを確認する必要がありますか？この種の事故の発生を最小限に抑えるために、より頻繁に実行する必要がある作業はありますか？
よろしくお願いします、Dermot
CentOS release 6.3
XFS_INFO (v3.1.1)
meta-data=/dev/mapper/video2-lv01 isize=256 agcount=123, agsize=268435455 blks
= sectsz=4096 attr=2, projid32bit=0
data = bsize=4096 blocks=32947259392, imaxpct=1
= sunit=1 swidth=256 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0