背景

私は走っているミュージックブレインピカードUSB経由で接続され、autofsを使用してマウントされた500GB NTFSディスク（Transcend StoreJet）で〜11M oggファイルを更新しました。ドッキングステーションを介して接続します。わからないいつも正しく削除してください。

私の心配は、仕事が長すぎるということでした。フォルダ全体が数分で処理されると予想しましたが、数時間かかった可能性があります。私が吹くときアイオトップ(1)、これは〜25K / sのディスク書き込みを報告し、そのうち〜99％はピカードプロセスに関するものです。 （Picardは完全にフリーズしません。GUIは数分以内に更新または応答します）。

いくつかの進歩を見るためにlsofをチェックしてください。全体の出力は次のとおりです。

$ lsof /mnt/greeno-ntfs
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
picard  2885 amahdal  mem    REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   14u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   16u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg

しかし、私はすべての観察を実際に理解することはできません。ただいくつかの仮定しかできません。それで、ここに聞いてみようかと思いました。

質問

• ファイルにFDが3つあるのが正常ですか？ 1つの「メモリ」と2つの「一般」？

  私はファイルを開いて更新するための簡単なスクリプトを書いてみましたが（間にスリープするのに長い時間がかかります）、通常のFD（5u）しかないので、通常のオープンはこのようには機能しません。

  仮説：これは、Picard（またはそのライブラリ）が意図的に解釈した潜在的に長いファイルI / Oを処理するための（おそらく普遍的な）技術の結果です。では、誰かを説明できますか？ （例えば、なぜ2+1なのか？）

• 私が見たように、SIZE / OFFSET列は実際には縮小 時間が経つにつれて。

  仮説：これはPicardが実際に内部ファイルを見つけて更新するのと一致します。そうですか？

ランダム仮説 - この時点で考えられる原因として理解される仮説はありますか？

• Picardにはバグがあります（更新/縮小効率は非常に非効率的です）。

• ディスクにエラーが発生しました（はい5歳以上...)、

• ファイルシステムのマウントエラー（ntfsを最適にマウントする方法を知っている人はいますか？）

• ドッキング解除/ドッキングによってファイルシステムが破損しています（chkdskがないため確認できません）...

それでは、次は何ですか？何が起こっているのかを理解するために、次に何を見ることができますか？