要望：ベリファイ動作の改善

[JAMES]

こんにちは、いつもFastCopyを便利に使っております。

題記の件ですが、HDDからLTOへLTFS(使っている方は珍しいと思いますが)を使って
ファイルコピーする際、LTOへのベリファイ動作でテープのリポジショニング
(通り過ぎてしまったファイルのある場所までテープを巻き戻す)動作が頻繁に発生して、
実効速度が大幅に低下しております。

なおLTOからHDDへファイルコピーする際には、テープのリポジショニングはそれ程発生していない事から、
ベリファイ動作仕様に由来した現象(ファイルの読み込み動作が不連続になっている？)ではないかと考えております。

つきましては、ファイルのベリファイ動作(ファイルの読み込み)が連続して行われるように改善の
ご検討をお願い致したく、宜しくお願いします。
(現在Ver2.11を使用中ですが、来歴を見る限り最新版でも同じ動作ではないかと考えてあります)

[Hiroaki SHIROUZU]

テープとは珍しいですね（笑）

ファイルログを取っている場合、ベリファイが終わった順にファイル名が書かれますので、

それを確認してみてください。（書き込みと同じ順序で読んでいるはずです）

通常の読み込みシーケンスでは、１つ１つのディレクトリに関して、

１．ディレクトリエントリの一括読み取り（直下の全ファイル名やファイルサイズ情報の取得）

２．上記１で得られた各ファイルの open/read/close

というシーケンスになりますが、ベリファイ時は１の情報は既にあるため、２のみが実施されます。

ここからは推測になりますが、２の実施前に１を実施しないとテープの場合、各ファイルについて

毎回メタ情報アクセスで無駄なシークが発生する（１が直前に実施されていればキャッシュ済み

でアクセス不要）、といった話があるのかもしれません。

ただテープ用に本来は必要のない１を行うというのは、ちょっと微妙ですので、

ベリファイをOFFでコピーしたのち、

CTRL+リストアップ、で「同一と判断されたファイル同士のベリファイ機能」で確認してもらうのが

よいかもしれません。（SHIFTキーも一緒に押すとロギングも行われます）

今のところ、CTRL+リストアップは、コマンドラインでは動作できないので、その拡張は検討しておきますね。（上記の仮説が正しければですが）

[JAMES]

早速のレスポンスありがとうございます。

現在ファイル転送作業中なので、連休明けに確認してみます。

なおLTFSの場合メタ情報はオンメモリで持っているので、

メタ情報への
リードアクセスに伴ったシークの発生は無さそうに見えます。

テープが珍しいのは、ドライブが高価(特に日本の場合)なのが
一番効いております。(汗)

[Hiroaki SHIROUZU]

あと、ベリファイは全書き込みが終わった後だけではなく、オンメモリで保持できる書き込みファイル情報の

上限に来たタイミングでも行われます。

通常は2-4万ファイル程度（パス名長に依存）、ベリファイされない書き込みファイル情報が溜まると、

書き込みを一旦停止して、ベリファイ動作に移行します。

ですので、そのタイミングでシークが起きるのは止むを得ないところですが、上記の通り、頻繁に起こるものでもないです。

可能であれば、sysinternal の process monitor で、どのファイルアクセスがシークを発生させているのかをモニタ

して報告して頂けると、もう少し突っ込んだ話ができるかもしれません。

[seattl...@gmail.com]

こんにちは。

レスパスビジョン株式会社でMac版FastCopyであるRapidCopyを開発しています。澤津健吾です。

Mac OS用のLTFS運用フロントエンドなんかも作っています。

http://www.lespace.co.jp/topics/2015/11/18/ltfs-quicktools_news/

RapidCopyではLTFS専用のモードを用意している関係で動作や理論についてそれなりに詳しいので、原作者さまに代わって回答します。

例はIBM製のドライブ及びLTFSドライバでお話ししてますが、他社製でも基本的には全て同じ動作になります。

＞題記の件ですが、HDDからLTOへLTFS(使っている方は珍しいと思いますが)を使って
＞ファイルコピーする際、LTOへのベリファイ動作でテープのリポジショニング
＞(通り過ぎてしまったファイルのある場所までテープを巻き戻す)動作が頻繁に発生して、
＞実効速度が大幅に低下しております。

これはLTFSのsync、及びLTOドライブ内部ファームの挙動が原因です。

FastCopyの動作挙動による現象ではありません。

windows版のLTFSではお使いの環境にもよりますが、5分に一回LTFSパーティションのsync動作というものが発生します。

sync動作はLTFSのデータブロックのコミットのようなものです。

基本的には急な電源断やosフリーズ時などに必要なリカバリ時間を短縮させるため、5分に一回syncが発生します。

このsync動作により、一時的にfastcopyが動作を停止しているような状態になります。

windows版ではこのsync間隔はGUIでは変更できません。Macでは変更可能です。

(winでもC:\Program Files\IBM\LTFS\LtfsMain.exeに引数を渡すことで変更できるかもしれないが、未検証。。)

また、sync以外にもLTOドライブの内部メカ制御の都合で、read/writeが止まることがあります。

これもデバイス側の問題なので、FastCopyでは全く関与できません。

FastCopyは現状でテープデバイス(シーケンシャルアクセスデバイス)に対しては理想的なI/Oを投げていますので、

syncの時間間隔変更さえすれば、間違いなく理論値でwriteするはずです。

(拙作のMac版では、LTO5及びLTO6の理論値でのRead/Write性能を達成しています)

LTFS固有の話題については私の以下の投稿も参考にしてみてください。

また、もっと詳しいことをお聞きしたい場合は以下に質問して頂ければ私の方で回答します。

https://groups.google.com/d/msg/rapidcopy_jp/xVtPPd3cUTQ/fHo7xPn6eDEJ

https://twitter.com/KengoSawa2

[Hiroaki SHIROUZU]

詳しい説明、ありがとうございます。私も参考になりました。

昔は、容量密度のAITと信頼性のDLTで覇を競っていた印象がありましたが、最近はほとんどDLTに収束したんですかね。

[JAMES]

>あと、ベリファイは全書き込みが終わった後だけではなく、オンメモリで保持できる書き込みファイル情報の

>上限に来たタイミングでも行われます。

大量のファイルがある場合、30kファイル程度ごとにベリファイが発生する事は承知しております。

只今追試しておりますので、後程判った事を書きます。

[JAMES]

>可能であれば、sysinternal の process monitor で、どのファイルアクセスがシークを発生させているのかをモニタ

>して報告して頂けると、もう少し突っ込んだ話ができるかもしれません。
CTRL+リストアップを実行した際にsysintermalでキャプチャしたファイルアクセスとプロセス/スレッド(FastCopy)の一部を切り出しました。

－－－－－
23:09:03.4711480    FastCopy.exe    4296    CreateFile    L:\100EOS1D\DN3Q2425.CR2    SUCCESS    Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, No Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
23:09:03.4899562    FastCopy.exe    4296    QueryInformationVolume    L:\100EOS1D\DN3Q2425.CR2    BUFFER OVERFLOW    VolumeCreationTime: 2015/11/08 22:16:34, VolumeSerialNumber: B4B2-3CBB, SupportsObjects: True, VolumeLabel: 110ӧ
23:09:03.4899878    FastCopy.exe    4296    QueryAllInformationFile    L:\100EOS1D\DN3Q2425.CR2    BUFFER OVERFLOW    CreationTime: 2015/11/25 20:04:47, LastAccessTime: 2015/11/25 20:04:47, LastWriteTime: 2013/02/11 11:18:18, ChangeTime: 2015/11/20 1:04:02, FileAttributes: A, AllocationSize: 21,581,824, EndOfFile: 21,578,094, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x100000000050f, EaSize: 0, Access: Generic Read, Position: 0, Mode: Sequential Access, No Buffering, Synchronous IO Non-Alert, AlignmentRequirement: Byte
23:09:03.4901063    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2425.CR2    SUCCESS    Offset: 0, Length: 16,777,216, I/O Flags: Non-cached, Priority: Normal
23:09:03.7044371    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2425.CR2    SUCCESS    Offset: 16,777,216, Length: 4,800,878, I/O Flags: Non-cached, Priority: Normal
23:09:03.7344182    FastCopy.exe    4296    CloseFile    L:\100EOS1D\DN3Q2425.CR2    SUCCESS   
23:09:07.3271419    FastCopy.exe    4296    CreateFile    L:\100EOS1D\DN3Q2426.CR2    SUCCESS    Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, No Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
23:09:07.3544981    FastCopy.exe    4296    QueryInformationVolume    L:\100EOS1D\DN3Q2426.CR2    BUFFER OVERFLOW    VolumeCreationTime: 2015/11/08 22:16:34, VolumeSerialNumber: B4B2-3CBB, SupportsObjects: True, VolumeLabel: 110ӧ
23:09:07.3545293    FastCopy.exe    4296    QueryAllInformationFile    L:\100EOS1D\DN3Q2426.CR2    BUFFER OVERFLOW    CreationTime: 2015/11/25 20:04:47, LastAccessTime: 2015/11/25 20:04:47, LastWriteTime: 2013/02/11 11:18:18, ChangeTime: 2015/11/20 1:04:02, FileAttributes: A, AllocationSize: 21,610,496, EndOfFile: 21,609,688, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x1000000000510, EaSize: 0, Access: Generic Read, Position: 0, Mode: Sequential Access, No Buffering, Synchronous IO Non-Alert, AlignmentRequirement: Byte
23:09:07.3546486    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2426.CR2    SUCCESS    Offset: 0, Length: 16,777,216, I/O Flags: Non-cached, Priority: Normal
23:09:07.5584873    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2426.CR2    SUCCESS    Offset: 16,777,216, Length: 4,832,472, I/O Flags: Non-cached, Priority: Normal
23:09:07.5881126    FastCopy.exe    4296    CloseFile    L:\100EOS1D\DN3Q2426.CR2    SUCCESS   
23:09:07.6215068    FastCopy.exe    4296    CreateFile    L:\100EOS1D\DN3Q2427.CR2    SUCCESS    Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, No Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
23:09:07.6292427    FastCopy.exe    4296    QueryInformationVolume    L:\100EOS1D\DN3Q2427.CR2    BUFFER OVERFLOW    VolumeCreationTime: 2015/11/08 22:16:34, VolumeSerialNumber: B4B2-3CBB, SupportsObjects: True, VolumeLabel: 110ӧ
23:09:07.6292658    FastCopy.exe    4296    QueryAllInformationFile    L:\100EOS1D\DN3Q2427.CR2    BUFFER OVERFLOW    CreationTime: 2015/11/25 20:04:48, LastAccessTime: 2015/11/25 20:04:48, LastWriteTime: 2013/02/11 11:18:20, ChangeTime: 2015/11/20 1:04:02, FileAttributes: A, AllocationSize: 21,352,448, EndOfFile: 21,349,856, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x1000000000511, EaSize: 0, Access: Generic Read, Position: 0, Mode: Sequential Access, No Buffering, Synchronous IO Non-Alert, AlignmentRequirement: Byte
23:09:07.6293641    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2427.CR2    SUCCESS    Offset: 0, Length: 16,777,216, I/O Flags: Non-cached, Priority: Normal
23:09:07.8140747    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2427.CR2    SUCCESS    Offset: 16,777,216, Length: 4,572,640, I/O Flags: Non-cached, Priority: Normal
23:09:07.8436030    FastCopy.exe    4296    CloseFile    L:\100EOS1D\DN3Q2427.CR2    SUCCESS   
.
. (この間は時間のジャンプ無しにベリファイ動作)
.
23:09:12.1125746    FastCopy.exe    4296    CreateFile    L:\100EOS1D\DN3Q2443.CR2    SUCCESS    Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, No Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
23:09:12.1197118    FastCopy.exe    4296    QueryInformationVolume    L:\100EOS1D\DN3Q2443.CR2    BUFFER OVERFLOW    VolumeCreationTime: 2015/11/08 22:16:34, VolumeSerialNumber: B4B2-3CBB, SupportsObjects: True, VolumeLabel: 110ӧ
23:09:12.1197430    FastCopy.exe    4296    QueryAllInformationFile    L:\100EOS1D\DN3Q2443.CR2    BUFFER OVERFLOW    CreationTime: 2015/11/25 20:04:51, LastAccessTime: 2015/11/25 20:04:51, LastWriteTime: 2013/02/11 11:18:24, ChangeTime: 2015/11/20 1:04:05, FileAttributes: A, AllocationSize: 21,270,528, EndOfFile: 21,267,932, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x1000000000521, EaSize: 0, Access: Generic Read, Position: 0, Mode: Sequential Access, No Buffering, Synchronous IO Non-Alert, AlignmentRequirement: Byte
23:09:12.1198614    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2443.CR2    SUCCESS    Offset: 0, Length: 16,777,216, I/O Flags: Non-cached, Priority: Normal
23:09:12.3239289    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2443.CR2    SUCCESS    Offset: 16,777,216, Length: 4,490,716, I/O Flags: Non-cached, Priority: Normal
23:09:12.3517842    FastCopy.exe    4296    CloseFile    L:\100EOS1D\DN3Q2443.CR2    SUCCESS   
23:09:15.9521595    FastCopy.exe    4296    CreateFile    L:\100EOS1D\DN3Q2444.CR2    SUCCESS    Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, No Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
23:09:15.9708788    FastCopy.exe    4296    QueryInformationVolume    L:\100EOS1D\DN3Q2444.CR2    BUFFER OVERFLOW    VolumeCreationTime: 2015/11/08 22:16:34, VolumeSerialNumber: B4B2-3CBB, SupportsObjects: True, VolumeLabel: 110ӧ
23:09:15.9709066    FastCopy.exe    4296    QueryAllInformationFile    L:\100EOS1D\DN3Q2444.CR2    BUFFER OVERFLOW    CreationTime: 2015/11/25 20:04:51, LastAccessTime: 2015/11/25 20:04:51, LastWriteTime: 2013/02/11 11:18:24, ChangeTime: 2015/11/20 1:04:06, FileAttributes: A, AllocationSize: 21,479,424, EndOfFile: 21,475,538, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x1000000000522, EaSize: 0, Access: Generic Read, Position: 0, Mode: Sequential Access, No Buffering, Synchronous IO Non-Alert, AlignmentRequirement: Byte
23:09:15.9710190    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2444.CR2    SUCCESS    Offset: 0, Length: 16,777,216, I/O Flags: Non-cached, Priority: Normal
23:09:16.1843555    FastCopy.exe    4296    ReadFile    L:\100EOS1D\DN3Q2444.CR2    SUCCESS    Offset: 16,777,216, Length: 4,698,322, I/O Flags: Non-cached, Priority: Normal
23:09:16.2144337    FastCopy.exe    4296    CloseFile    L:\100EOS1D\DN3Q2444.CR2    SUCCESS   
－－－－－

ファイルアクセスごとにバッファオーバーフローが発生している所が気になります。
なおLTFS側のファイルアクセスは、sysinternalでは直接確認できないようです。
(LTFSは独自のファイルシステムにより動作)

[JAMES]

澤津さん、こんにちは。

>windows版のLTFSではお使いの環境にもよりますが、5分に一回LTFSパーティションのsync動作というものが発生します。

今回の現象は、ベリファイ動作時にのみ頻繁(数秒～

数１０秒位の間隔)で発生しているので、sync動作によるものではないと
見えております。

>また、sync以外にもLTOドライブの内部メカ制御の都合で、read/writeが止まることがあります。

>これもデバイス側の問題なので、FastCopyでは全く関与できません。

データ転送レートの調整でR/Wが止まってテープの速度を再設定したり、トラッキング状態が
悪い時にイジェクト/再ローディングする場合はありますが、それとも違うようです。
(USB接続で使用しておりますので、LTO6のフルスピードは頑張っても出ません)

只今追試中ですので、ある程度傾向が見えてきた所で書きますので宜しくお願いします。

[JAMES]

>澤津さん
本投稿と同じ内容で投稿されておりました先の投稿を自分の投稿共々間違って削除してしまいました。
問題がありましたら再度投稿お願いします。

[Hiroaki SHIROUZU]

ご報告有難うございます。

buffer overflow に関しては下記と同じ内容なので、気にしなくてよいのではと。

 http://blogs.technet.com/b/markrussinovich/archive/2005/05/17/buffer-overflows.aspx

さて、もともと知りたかった情報は、シーク動作がどのAPI&パラメータによって引き起こされるか、という点でした。

ですが、LTFS へのAPI発行が確認できないということで、一番知りたい部分が取れていないようです。

ただ、CTRL+リストアップの場合、行っている動作は src と dst で同じはずなので、だとすると（連続しているはずの）ファイルオープンに時間が掛かっているように見えますね。

API Monitor だと、カーネルに飛び込む前のDLL内syscallを捕まえるので、もう少し分かり易いかもしれません。

[seattl...@gmail.com]

こんばんは、レスパスビジョンの澤津です。

JAMESさんの投稿からするに、確かにsyncの問題でもなさそうですね。

ただ、弊社のWindows Server2008(2012でも) + fastcopy v2.11環境ではベリファイ有りのLTFSコピーではトータル60MB/sec出ているのですよね。。

(LTO-5のアクセス速度のRead/Write理論値が130MB/secくらいなので、ほぼ理論値であり妥当な値かと)

弊社のLTFS環境のスクリーンショットを貼っておきますので、参考にしてください。

SAS接続で、HBAはLSI。ドライブはIBM社のハーフハイトのTS2350及びTS2360です。

以下、ちょっときになるところを書いておきます。

・USB接続特有の問題ということはありませんか？

　USBのLTOはUSBドライバ実装がUNITEXさんのはずです。UNITEXさん経由で解析して貰うのもありかもしれません。

　(弊社ではUSBのLTOはテストでちょっと使用したくらいで、運用実績はありません)

・マシン再起動で直ったりしませんか？

　windowsのLTFSドライバはなにが原因かさっぱりわかりませんが、ずっと使用しているとOSが重くなったりするので、時折再起動が必要だったりします。

・単純なドライブ劣化ということはありませんか？

　私見ですが、Mac OS X + HP社製のドライブは数百本取ったところで、意味不明のパフォーマンスダウンが発生しました。

　(書き込み中にすぐシークっぽい動きになってしまい、writeシステムコールが頻繁にストップ、性能ダウン著しい。。)

windowsのLTFSドライバはMinGWでIBMさんが開発したプロプライエタリなもので、FUSE経由でLTOに書き込む仕掛けです。

SHIROUZUさんの見解からするに、FUSEの中で遅延しているか、FUSEの奥のデバイスドライバ側で遅延しているのでは？と言う気もします。

参考にしてみてください。

[JAMES]

API Monitorでの罠掛けをしましたが、キャプチャログのどの部分にフォーカスして欲しいかご教授願いたく。

[JAMES]

>澤津 さん

|・USB接続特有の問題ということはありませんか？

|　USBのLTOはUSBドライバ実装がUNITEXさんのはずです。UNITEXさん経由で解析して貰うのもありかもしれません。

使っているのがTS2260(Option 5760)なので、IBMさん経由の問い合わせになりそうです。

USB対応の方法ですが、ドライブ内にUSB3.0<>SAS(

3G)ブリッジコントローラ(市販品はないのでFPGA辺りで構築？)が
入っていて、PC側のドライバ(サイズは数kB)でSAS HBAのソフトウェアインタフェースを構成しているように見えます。
LTO6カートリッジ使用時の実効転送能力はWrite時で120MB/s弱が最大でしたので、ベリファイ込みで50MB/s程度は
出ても良さそうですが、実際には30MB/s中盤程度しか出ておりません。

|・単純なドライブ劣化ということはありませんか？

LTO→HDDへのコピーでは、リポジショニングが大幅に減る(転送速度が向上)ので、
ドライブの不良という線は薄いです。
(稼働開始から500hも経過しておりません)

|・マシン再起動で直ったりしませんか？

いろんなタイミングでコピー作業させておりますが、傾向は変わっていないように見えました。

[Hiroaki SHIROUZU]

duration が異常に長い行（＝APIがなかなか戻ってこない）がシーク発生時のAPIである可能性が高いです。

（発現のトリガとなったAPI＝原因とは限らないのが面倒なところですが…）

１．（見えている一覧の範囲では）#2669 の NTReadFile がシーク発生APIの可能性が高い

　　（また、LTFSにアクセスしているのはスレッド4にみえるので、それのみを表示or注目すると見易いはず）

２．当該ハンドル 0x...634 を追うと#2663 でオープンしている

　　→ #2663 を選んで POBJECT_ATTRIBUTES の奥深くを辿ると、オープン要求のパス名が記載されています

３．その直前にアクセスしたファイル名は #2655より少し上にあるはずの thread4 の NTCreateFile の POBJECT_ATTRIBUTES に記載されているはず

上記の２と３のパス名が書き込み順と異なっていれば、シークが発生するということになります。

（それ以外にシーク位置を変更するようなAPI発行は無いように見えるので）

なお、FastCopyでの書き込み順（及びCtrl+リストアップ時のベリファイ順）は、src側ディレクトリを FindFirstFile/FindNextFileで列挙した時に得られた順序になります。なお、API側の挙動は下記の通り。

 1) NTFSの場合、大文字/小文字を無視した文字コード順。

 2) FAT系の場合、原則は初回作成順（ただし削除と作成を繰り返すと崩れていく）

また、FastCopy固有の動作として、ディレクトリ処理は後回しという特徴があります。例を挙げると、

 Dir + dir1 + file1

     |      + file2

     |

     + file4

     + file5

上記のような構成がある場合、処理順は file4, file5, dir1, file1, file2 となります。

API Filterで、NT Native -> Objects -> ntdll.dll -> NTClose もチェックしておくと NTCreateFile等で作られたhandleのcloseも見えます。（同じハンドルIDが再利用された場合に混同せずにすみます）

また可能でしたら、API Monitorのログを送って頂ければ、私の方でも見てみます。

[JAMES]

先程、API Monitorのログをお送りしましたので、確認お願いします。

[Hiroaki SHIROUZU]

拝見しました。

ベリファイ用読み込みで連続アクセスしているのに、シークが発生しているように見えますね。

ただし、下記の仮定が正しいとすればですが。

・過去のFastCopy の書き込み順がファイル名順になっている。（ログで確認可能のはずです）

・LTFSはAPIで書き込んだ順にテープに書かれる

・差分更新等は行っていない

詳細は下記の通り。（下記が全シーク発生APIです）

 No  Time         T API                                               sec

 195 11:40:35.694 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1169.CR2" ) 0.0006577

 198 11:40:35.700 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1169.CR2" ) 21.8145196 ← シーク発生（先頭ファイルのため）

  :

 345 11:41:01.500 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1184.CR2" ) 0.0006419

 351 11:41:01.515 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1184.CR2" ) 0.1617242

 355 11:41:01.782 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1185.CR2" ) 0.0006098

 361 11:41:01.796 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1185.CR2" ) 4.1514434 ← シーク発生

  :

 505 11:41:09.942 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1200.CR2" ) 0.0006098

 508 11:41:09.956 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1200.CR2" ) 0.1515888

 515 11:41:10.208 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1201.CR2" ) 0.0005748

 521 11:41:10.222 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1201.CR2" ) 4.1716808 ← シーク発生

  :

 665 11:41:18.317 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1216.CR2" ) 0.0007304

 671 11:41:18.333 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1216.CR2" ) 0.1586930

 675 11:41:18.608 4 NtCreateFile( "Z:\test2b\100EOS1D\DN3Q1217.CR2" ) 0.0006316

 683 11:41:18.829 4 NtReadFile  ( "Z:\test2b\100EOS1D\DN3Q1217.CR2" ) 3.8166793 ← シーク発生

  :

以下も同様

 858 11:41:27.374 PM 4 KERNELBASE.dll NtReadFile  () STATUS_SUCCESS  3.7423098 ← シーク発生

1023 11:41:35.743 PM 4 KERNELBASE.dll NtReadFile  () STATUS_SUCCESS  3.5583442 ← シーク発生

1198 11:41:44.073 PM 4 KERNELBASE.dll NtReadFile  () STATUS_SUCCESS  3.7049363 ← シーク発生

[JAMES]

テープへのファイル書き込み順が影響しているか、FastCopyのSRC(HDD)とDST(LTFS)を入れ替えて
テストしてみましたが、同様にシークが発生しておりました。

先程データを送りましたが、LTFS→HDDへのコピー動作では、転送開始直後のテープの頭出し、
転送速度調整(テープの速度をホスト側の転送能力に調整)及びテープ端での折り返しに伴う
シーク以外は発生しない状態でした。

以上より、先の仮定とは違った結果になっているような気がします。

[Hiroaki SHIROUZU]

新しいログも拝見しました。

仮定で推測した通り、書き込み順も読み込み順と同じ名前順に行っていることが確認できました。

ただし、にもかかわらず、読み込み時にシークが発生しているということは書き込み時点で、

何らかのフラグメントのような状態が発生していることになります。

考えられるのは書き込み時に行っている処理で、

 - ファイルブロックの連続確保（ただしファイルシステムのセクタサイズ粒度に切り上げ）

 - 書き込み終了後にセクタ単位未満の末端を切り詰め

という動作が、更新処理と似た問題を起こしている可能性です。

お手軽に上記仮説が正しかどうかを試すには、一般設定→ I/O設定のOSキャッシュ設定で、

NTFS系の欄をKB単位指定で書き込みファイルサイズ以上に設定してみてください。

（例えば、100000等(==100MB)）

上記設定で書き込みを行ったLTFSに対して、読み込みやベリファイを行ってシークが発生するかどうか確認してみてください。

[seattl...@gmail.com]

ご参考までです。

IBMさんが出しているLTFS向けのプログラミングガイド？の仕様上はSetEndOfFileは出してもokとなっているようです。

http://www-01.ibm.com/support/knowledgecenter/STQNYL/com.ibm.storage.hollywood.doc/ltfs_supported_functions_win.html

http://pic.dhe.ibm.com/infocenter/ltfs/cust/index.jsp

拙作のMac OS X版ではSetEndOfFileに相当するftruncateを出していますが、同様の事象は確認したことがありません。

win版のLTFSは各社のプロプライエタリ製品なため、ソースを読んで追えないのが残念なところですね。。