WinnyからHDDを守るツールを作ろう Part2.1

WinnyのHDDアクセスはHDDに優しくないらしい
このスレはWinnyのHDDアクセスを、優しいものに変えるツールを作るテスターさんの連絡所です

ツール配布先
http://www.geocities.jp/ny2scan/
解説サイト
ttp://www.geocities.jp/ny2scan_kaisestu/

基本的な原理
・nyは64kB毎にファイルを分割して受送信するのでこれを同時に複数行うとHDDのヘッドが激しく右往左往する
・そこでファイルごとにRAM上に数MBのバッファを作ることでHDDへの読み込み/書き込み回数を減らす 例えば
　2つのファイルの1MB分を読み出して送信する際、そのままではヘッドが離れた領域の間を32回動いて読み出しを
　する事になるが　このソフトを使えば2回1MBの読み出しをするだけで済む！
・ただし、先読みしたデータを必ず全て使うとは限らないので無駄に先読みしてそのぶんHDDに負荷をかける場合も有るかな…

ということでこのソフトを実用的に使えるまで開発協力をしてくれるテスターさんを募集してます
とりあえず正しい使い方であればOS・ハードが破損することはありません。ただし、場合によっては扱うファイルが壊れることはあります。
テスタをするのに必要なもの
・対象のアプリ：お好きなものをどうぞ　ただし動かないかも(推奨はwinny2b7.1)
・本体：作者のサイトの(名称未定)→ExtraFileCacheTest。最新ver.は0.1911 かならずSetup.exeを差し替えましょう。
・観察用ソフト:最初は作者のサイトのStatHddActivityのみでOK
やり方
最初はStatHddActivityの付属ドキュメントに書いてあるやり方で行ってこのスレに書き込んでください
慣れて来たら自分が思うHDDの負荷を示す数値(温度等)も一緒に測定するといいかも
お約束
・全ては自己責任。転んでも泣かない
・ソース厨は保守要員です。大切に無視しましょう
・作者に過度の期待・要望・要求・強要は止めましょう　「〜すれば使用者が増える」よりもあなたがテスタをするために必要なことを書いてください
・分からないことがあったらこのスレで聞いてしまいましょう

vipに荒らされて見事にスレ消えてるね

過去スレ
WinnyからHDDを守るツールを作ろう Part2 ← ﾀﾞｳｿ板のスレが大量に落ちた時に落ちた
http://tmp5.2ch.net/test/read.cgi/download/1123773154/
http://makimo.to/cgi-bin/dat2html/dat2html.cgi?tmp5/2/download/1123773154/

WinnyからHDDを守るツールを作ろう Part1.3
http://tmp5.2ch.net/test/read.cgi/download/1116770018/
http://makimo.to/2ch/tmp5_download/1116/1116770018.html

WinnyからHDDを守るツールを作ろう ← 保守が間に合わずDAT落ち
http://tmp5.2ch.net/test/read.cgi/download/1113831829/
http://makimo.to/cgi-bin/dat2html/dat2html.cgi?tmp5/2/download/1113831829/

今までの話のまとめ・・・きれないので一部分だけ。(Part2の時のまま)

■何がHDDに酷なのか。
　　　　・長時間稼働しつづける → どうにもならない。
　　　　・休みなしにヘッドが右往左往し続ける → これをキャッシュの追加で改善しよう!

■Winnyの挙動
　　　　・細かく頻繁にファイルアクセスをしている。(1ブロック約64KB)
　　　　・複数のファイルをランダム的な順番でアクセスしている。
　　　　→(ファイルの断片化の状況によらず)HDDのヘッドは右往左往する。

■現状のツールの段階
　　　　・Winnyに使う分には、大きな問題は報告されていない。
　　　　・誰しもが簡単・安直に使えるようには作っていない。使いやすさは後回し。
　　　　・あくまでも実験段階で、HDDの負荷が減ることを確認するためのもの。
　　　　・アルゴリズムは、ファイルアクセスに単純なバッファリング処理を追加する。
　　　　・ただしWinnyのUIの反応が若干鈍くなる。(非同期に読み書きすることで対策できるが、現段階では見送り)

■HDDを冷却したほうがいい。
　　　　→それは激しく同意だが、ソフトウェアからのアプローチもやってみよう。

■Winny自体を改良したほうがいいのでは?
　　　　→◆aBeASKncAIにはWinny自体をいじる気はないです。

■ディスク上で連続した領域にファイルが存在しているとは限らないのに、
　ファイルアクセスをバッファリグして行っても意味がないのでは?
　　　　→YesでありNo。
　　　　すでにディスクに書かれたファイルが激しく断片化していたら意味がない。
　　　　なので、断片化を減らした状態で使わないとあまり効果が出ないと思う。
　　　　一方、まとめて書き込むことで、新たな断片化を予防する効果があるかも。
　　　　OSが賢ければ、まとめてアクセスすることで、HDDのヘッドの動きが少なく
　　　　なるように処理してくれるかも・・・しれない。

■キャッシュをRAMディスクに置いたほうがいいのでは?
　　　　→RAMディスクの容量が少ないので、本質的にはディスクキャッシュと同じ。
　　　　効率を考えると、RAMディスクよりも、ディスクキャッシュのほうが良い。

■Shareにも対応してよ。
　　　　→いちおうWinny専用ではなく汎用を目指してはいるけど、
　　　　Shareの作者さんは開発を継続しているようなので、
　　　　作者の人にお願いしたほうが早いと思う。

■通信相手がランダムにキャッシュの一部分を要求してくるので
　ランダムアクセスになるのは避けられないのでは?
　　　　→Shareと違ってWinnyは、ファイルの先頭から末尾に向かって
　　　　なるべく直線的にキャッシュを転送する傾向があるので、
　　　　1つの相手だけに着目すれば、シーケンシャルな読み込みなので、
　　　　うまくやればなんとかなるかも。

■テスト・評価と言っても、なにをすればいいの? そんなスキルないよ?
　　　　→何ができるのか考え、できることをやってください。
　　　　とりあえずHDDのヘッドの移動量を推定するツール「StatHddActivity」
　　　　を作ったので、ツールの使用有無で比較してみてください。

■どうして使用期限をつけているのか?
　　　　→期限は自分への鞭です。期限を切らないと、ついつい放置してしまうので。
　　　　バグを修正しても、修正前のものを使い続けられても困るという理由もある。

■どうしてGUIがない・ショボいのですか?
　　　　1. このツールには本質的にユーザインタフェースが必要ありません。
　　　　最初に設定をしてしまえば、あとは黙々と動き続けるだけで、
　　　　ユーザが操作すべきことが何もないのです。
　　　　2. まずはツールの本体部分を作るのが先決だからです。
　　　　GUIは作るのに手間がかかるので、フットワークが重くなってしまいます。
　　　　3. 作者がGUI作るのに慣れてない・興味がないからです。

■どうしてユーザがテストしないといけないの?
　テストしてからリリースするのが筋じゃないのか?
　　　　→テストしてからリリースするだけの余裕が作者にありません。

■作者が開発中止を何度も言っていますが?
　　　　→このツールの開発には皆さんのフィードバックが欠かせません。
　　　　フィードバックがないと、ツールの開発が成り立ちません。
　　　　なので、フィードバックがなくなった時点で開発終了にします。
　　　　作者は開発中止でも痛くないので、フィードバックを要求する脅しではないです。

■どうして作者は○○しないの?
　　　　→まずは過去ログを見てください。既出でなければ、このスレで作者に聞いてください。

■敷居が高いぞ、低くしろ!
　　　　→まずは過去ログを見てください。既出でなければ、このスレで作者に聞いてください。

■なんか作者の評判が悪いようですが?
　作者が頭にきてトリップ捨てたとか言ってますが?
　　　　→どういう利害関係かわかりませんが、妨害したい人がいるようです。スルーしてください。

■怖くて使う気になれない
　　　　→どんなバグがあるかわからないので、まずは何が起きても構わないテスト環境で試してください。
　　　　重大なバグがなく、そこそこ安全だということを確認するのも、テストの目的でもあります。

■ソースコードを公開しる!
　　　　→公開しません。様々な理由を総合的に判断したことなので。

■作者は否定ばかりで人の言うことを聞かない!
　　　　→過去ログを注意深く読めば、何を聞いて何を聞かないのかわかります。

うまく動かない場合の報告テンプレ

このツールのバージョン :
OSのバージョン :
Winnyのバージョン :
セキュリティ関係のツール :
その他、何か特殊なツール :
不具合の出るタイミング :
不具合の内容(表示されるエラーメッセージは全てコピペ) :
エラーログのファイルに何か出ているか(出ていればその内容) :



とくに
アドレスどこそこでアクセス違反
という表示の内容(とくにアドレス)は非常に重要な情報です。
それがないと、どこで問題が発生したのかわかりません。

テンプレは以上です。

24時間以上書き込みがないとDAT落ちすることがあるので、
私も気をつけてはいますが、保守できない時もありますので、その時はお願いします。

保守

緊急保守あげしようとした瞬間に落ちたんだよな・・・
>1乙

へ〜、こんなのまで作ってたんだ。
本当に久しぶりにﾀﾞｳｿに来てビックリですわ

全然できてないけどな。

915 ：[名無し]さん(bin+cue).rar [sage] ：2005/09/03(土) 22:21:28 ID:K7D0xApW0
ゴメン、今日何があったの？
鯖�dだ？
それともVIPに荒らされた？？？
どっかにまとめがあったら教えて。


916 ： ◆LASTP6WUAA [sage] ：2005/09/03(土) 22:39:57 ID:vMyMefTS0
>>915
１．tmp5鯖落ち
２．復旧するも設定ファイル消失
３．設定ファイルが消えたことによりスレ立て放題に
４．それを知ったVIP住民その他によるスレ立て荒らし
５．bbs.cgi一時停止
６．設定ファイルがtmp4からコピーされ復旧
７．圧縮に次ぐ圧縮で既存スレ落ちまくり
８．落ちたスレを住人が一生懸命建て直し

こんな感じでいいのかな。

保守

shareのキャッシュ変換時が一番HDDに負担かかってそうな音する　（＞＜）

保守

ほ

Winnypには使えないのか。残念。

ほしゅ

>>19
nypだとどうなります?

nyp使ってないのでわからないのですが。

保守

ほしゅ

保守

ほしゅ

作者さんがんがれ

知らんけどテスト報告ないとがんがりようがないんじゃね？

sage

保守

ほしゅ

SpecialFileHeadAreaへのWriteで
非SpecialFileHeadArea部分のバッファもフラッシュされる問題と
Close後すぐにOpenされる場合に
キャッシュ処理が裏目に出る問題を何とか改善できねっすかね。

Close後もすぐに破棄せず5件ぐらいキャッシュ保持しておいて
次新しいファイルOpenされた時にキャッシュがまだあれば再利用
なければ古いキャッシュから破棄する、とか。

>>27
前スレで出た問題に対処中です。
すこし時間がかかっているだけで、行き詰まっているわけではないです。

>>30
概ねその方向で作成中です。
今のバージョンのテスト期限が切れる前にはupしたいですが、どうなることやら。

保守

ＨＤＤ死ね！！！！
ふざけんな！！！！俺が一生懸命放熱対策してやったのに！！
なんだこのザマは！！！カクン！カクン！とか呼びかけやがって！！
聞きたくねぇんだよそんな音！！！！
どうしてくれんだ俺の大事なファイルたちを！！！！
いいか！そのクダラネェ円盤回してないで、耳かっぽじってよく聞け！！！
お前はすでに時代遅れなんだよ！！！俺たち人間様はぁな！
「しかたなく壊れやすいＨＤＤ使ってやってる」んだよ！！！！
だいたい２１世紀にもなって「円盤回して磁気で記録してます」とか
アホかと！！！？？？てめーエジソンの時から大して進化してねぇだろうが！！
それにな！！！アップルがiPod出したからっていい気になてんじゃねーぞゴラ!
一回地面に落としたら終わりだチクショウ！！！！
悔しかったらダンプカーに踏まれても壊れないぐらいになってみろよ！！！
Ｇショックを見習え！！
「精密機械は壊れやすいんです」とかほざきやがって！！！
　　　　　！！！！！！！！甘えるな！！！！！！！！！！！！
最悪な事に「ＴＶ録画でも時代はＨＤＤ」なんてキャッチコピー打ち出しやがって、
バカヤロウ！！！！何十年前の技術だっつーんだよ！！！！！
円盤回してチマチマ記録して、
ヒュロ長い針みたいのを浮かして記録なんてちーせー事しやがって！！
いいかげんにしろＨＤＤ！！！！！！！！！！！！！

てめぇなんか早くこの世から消えうせろ！！！！

パソコン用のＨＤＤなんて消耗品、はっきり言って使い捨て。
それに２４時間酷使しても２年くらいは充分耐える。
だから２年使って捨てればイイ。

>それに２４時間酷使しても２年くらいは充分耐える。

冷却大前提でな

保守

俺も保守

ならばオレも

それならばオレも

いえいえ私は・・・どうぞおさきに。どうぞどうぞ。

漏れも

>>35
4年もってるが?

基本だけど、キャッシュ変換してる最中に無理やりアプリ立ち上げたりとか、
ムービーやDVDを置くHDDと、Nyのキャッシュフォルダを物理的に同じHDDに
するとかしないで使えばそうとうにもちますよ。

ちなみに漏れのはこわれるこわれるっていわれたSmoothチップのアレですよ。

例のアレを冷却無視の24時間4年なんて信じない

冷却無視つーか、PC全体でエアフローそれなりなら特にHDDの冷却
考えなくてもそんなに熱くはならんと思うけどな

hosh

ソース厨でもつれてきて保守させる？

いくら民生品の安物たって２年くらいはもつ。
ことが多い。
旧IBMは耐久性よかった。

24時間ランダムアクセスで話してるよな？

リブートしない方がかえって長持ちしそうだけど

古くなってアラレちゃんなHDDは、旧車みたいに使用する前にしばらくそのままでアイドリングさせておくと、あの音が消えるよ。

×消えるよ
○消えることがあるよ

バージョンまだ〜？
明日までしか使えないよ

hosyu

hosh

ついに、今日限りになっちゃった。
さて、今日中に新バージョンは出るのでしょうか？

　　　　ﾁﾝ　　☆　　ﾁﾝ　　　　　　　☆　　　　　　　
　　　　　　　ﾁﾝﾁﾝ　　　　　　　　　　　ﾁﾝﾁﾝ　　　　　♪　　　　　　　　　
　　　　　　　　　　　♪　　　☆ ﾁﾁﾝ　　　　　　　　　　　　
　　　　♪　　　　　　　　　　　　　　　 .☆ バージョンまだ〜
　　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧ 　 ＿＿__ 　　　　　
　 　 　 　 　　ヽ　＿＿_＼（・∀・　）／＼＿／　　　　
　　 　 　 　ﾁﾝ　 ＼＿／⊂　　 　 つ　　 ‖　　　　
　　 　 　 　 　 ／￣￣￣￣￣￣￣／|　 ‖　　　
　　　　　　　　| ￣ ￣￣￣￣￣￣:|　:| ／|＼
　　　　　　　　|　　 夜露死苦　　　|／　

あと3時間！

コードは書いた。
あとはテストとドキュメントとup作業。

間に合うかな・・・。

う〜ん　間に合わなかったね…

version 0.19.12と0.20.1をupしました。

0.19.11→0.19.12での変更点
・設定ファイルにEnableDeleteFileOnAggregatingDirectoryがない場合に、無効になっていたので有効に変更した。
・メモリの確保に失敗した場合に、その旨をエラーログに出力するようにした。
　(メモリが足りないという状況では、ログに出力することすらも失敗する可能性があるが・・・)

※リードオンリーでオープンしたファイルに書き込もうとしたエラーが出る件は、
前スレにて、ログの追加すると書いていましたが、やはりやめることにします。
バグが入り込みそうな場所にログを仕掛けようとしたのですが、怪しい場所がないことと、
ログ量を抑えつつ出力するには本来の動作よりも複雑なロジックが必要になるなど、
いまひとつ乗り気がしないもので。

0.19.12→0.20.1での変更点
・バッファの先頭部分とその後続の部分について、バッファのRead/Writeモードを個別に管理するようにした。
　(暫定仕様: モニタで表示するRead/Writeは、後続の部分のモードです。)
・ファイルを閉じても、設定時間・設定個数のバッファ(Readのみ)を破棄せずに保持し続けるようにした。(デフォルト無効)

※↑はデフォルト無効ですので、注意してください。

( ノﾟДﾟ)ﾖｯ!

nyCacheVerifierのversion0.2
nyCacheRepairerのversion0.1
をセットにしてupしました。

Verifierの変更点は表示のメッセージだけです。
V6キャッシュの場合には全体ハッシュのチェック結果を表示しないようにしました。

Repairerは新規です。

バッファリングのアルゴリズムについては、もう一段階、改善の余地があります。

たとえば、多重DLなど、
1つのファイルにシーケンシャルなアクセスが複数同時に行われる
という場合、現状のものですと、ほとんどバッファリングの効果が出ません。

作者様乙です。

作者乙

version 0.20.1はバグっている模様。

・・・orz

(　ﾟдﾟ)､ﾍﾟｯ

version 0.20.2をupしました。

変更点
・0.20.1のバグを修正。


バグによって何が起こるかというと・・・。
ダウンロードしたファイルは、先頭部分が0で埋まってると思われます。
キャッシュはブロック0が破損していると思われます。

version 0.20.1を使っている時にダウンロードしたファイルについては、
MD5ハッシュをチェックし、違っているものは破棄してください。
キャッシュのほうは、キャッシュ修復ツールにかけてください。

乙です。
まぁ、人間失敗は付き物ですから。

過去ログを見ていない方にもう一度お願いです。

このツールにはバグがあることがあります。
ファイルに異常が生じていないかどうか、常に確認するようにしてください。

最低限やっていただきたいことは、
・ダウンロードしたファイルは、MD5ハッシュ値が正しいことを確認。(V5キャッシュのみ)
・UPフォルダからキャッシュに変換した場合、さらにキャッシュからファイルに変換して、ファイルが一致することを確認。
・ダウンロードしたキャッシュについては、破損チェックツールで破損していないことを確認。
の3つです。

ツールを使わない場合とファイルを比較するのも、大切です。

>>69
それ>>1のサイトかテキストに書いた方がよさげ

>>69

> ・ダウンロードしたファイルは、MD5ハッシュ値が正しいことを確認。(V5キャッシュのみ)
キャッシュを変換したファイルのMD5ハッシュとnyで表示されるハッシュが同じということ？

>>70
特定のアプリでの検証方法については、このスレのテンプレに書く、ということで。

>>71
同じです。

※V4キャッシュの場合は違います。

>>70
解説サイトの方に書こうとは思うけど

>・ダウンロードしたファイルは、MD5ハッシュ値が正しいことを確認。(V5キャッシュのみ)
>・UPフォルダからキャッシュに変換した場合、さらにキャッシュからファイルに変換して、ファイルが一致することを確認。
>・ダウンロードしたキャッシュについては、破損チェックツールで破損していないことを確認。

の中で
>・ダウンロードしたファイルは、MD5ハッシュ値が正しいことを確認。(V5キャッシュのみ)
の具体的な作業を確認させて。
(a)変換後にハッシュチェックを行うnyか補助ツールを使うようにする
(b)ハッシュチェックを算出するソフトを使ってファイルのハッシュを調べてny上のものと同じ事を確認する
どっち？

なんか変です。
これを見てください。
http://up.mugitya.com/img/Lv.1_up1740.jpg
http://up.mugitya.com/img/Lv.1_up1739.jpg
Winnyと関係ない物がでてきます。

新手のブラクラか？

いや。ﾌﾞﾗｸﾗじゃないって。

ほんとwinnyと関係ないものがキャッシュされてるんだって

うちのところでは今のところそんな現象はない

nyp.dllとか入ってるように見えるが
nypが他のファイルを読んでるんじゃないの？

マカフィー？とVBランタイム？

マカフィーは分かるんですがなぜVBランタイムなんでしょ

>>74
環境を書いておいたほうが作者は対応しやすいと思う。
あと不具合が出ているならその現象も

とりあえずSetup.exeの「OSに直に処理させる」のところに該当拡張子を
書いてしまうというのは考えられるけど、exeはどうなのかなぁ…

はい、じゃあ書いときますね。
CPU　CeｌD　2.93GHz
Mem　256MB
OS　WinXP　SP2
バージョンは0.20.2で、1ファイルのメモリーバッファを2MBにしている以外デフォルト。

Winnyのバージョンはｽｸｼｮにもあったように7.26です。
ちなみに再現率は分かりません。
今回のバージョンが初めてです。

nyCacheVerifierは使ってみましたか？

何度もスイマセン　ウザかったらスルーして下さい

あ、すみません。
そのときはキャッシュ自体ありませんでした

hrg

>>73
(b)です。

nyは変換後にハッシュをチェックするのではなく、変換しながらチェックしています。
nyからは正常なファイルとして書き込んでいるつもりでも、そのOSへのリクエストは、
このツールを通して処理されてからOSに渡されるので、nyから正常に見えても、
ファイルが正常に書かれているとは、限らないからです。

ただ、ツールを使ってnyで変換したファイルと、
ツールを使わずにnyで変換したファイルを比較するという手もあります。
手間を考えたら、MD5ハッシュ値をチェックするツールを使ったほうが楽だと思います。

なお、出まわっているキャッシュ変換ツールの中には、
部分ハッシュだけをチェックしていて、
全体ハッシュをチェックしていないものがあるかもしれません。
以前にどこかで見かけた何かのツールのソースコードでは、そうなっていました。
ですので、キャッシュ変換ツールで変換できても安心しないほうが良さそうです。

スレ違いだがWinny用ファイルリネームツール、管理ツールを作る人いないか？
()や【】でジャンルや作者が分類されてるし、それでも順番が統一されてなかったりするし
Winnyに特化したツールならかなり需要あると思うのだが。

>>74
c:\progra~1\mcafee.com\vso\mcvsescn.exe
C:\WINDOWS\system32\stdole2.tlb
の2つのファイルがキャッシュの対象になっている、ということですが、
結論からいうと、そういうこともありうるので、>>81さんの言うように処理対象から外すのが無難です。

それらのファイルは、nyがアクセスしているのではなく、
nyのプロセス内に読み込まれている、
いずれかのDLLがアクセスしているのだと思われます。

このツールは(現在のバージョンでは)、アプリ本体だけではなく、
アプリが使っているDLL、
アプリが使っているDLLが使っているDLL、
アプリが使っているDLLが使っているDLLが使っているDLL、
・・・
によるファイルアクセスのAPI呼び出しもフックしてキャッシュ処理をしています。
(すべてのAPI呼び出しをフックしているわけではないのですが、
そのあたりの話は難しいのと、とりあえず手っ取り早く作ったために、
一時的な事柄が多量に含まれてるので、省略。)

アプリケーションが明示的に操作しているファイル以外をキャッシュするのは、
いらぬトラブルの原因になる恐れが少しだけあるので、そのうち、
・指定したディレクトリにあるファイルだけを処理対象にする
・指定したディレクトリにあるファイルは処理対象にしない
といった選択的にキャッシュするようにする機能を付けようと思ってはいました。
ずっと先でいいと思っていましたが、少し早めに付けた方が良さそうですね。

ほしゅ

保守

ｈ

保守

解説サイトの更新しました。
追加内容は0.20.1への対応と
>>69
>>74
のところの追加

要望
NoInterventionFileExtのところはフォルダ指定でもいいけど
指定した拡張子のファイルのみキャッシュ処理/指定した拡張子を除くファイルをキャッシュ処理
のオプション希望

>>94
わかりました。
次バージョンでオプション付けます。

OS:WinXP Pro SP2
ターゲットアプリ：Winny2b7.1
使用Ver:0.20.2
HDDの容量:250GB(Maxtor 7Y250P0)
キャッシュフォルダのドライブ番号:1(キャッシュのみに使用)
ダウンフォルダのドライブ番号:0
デフラグしてからの測定かどうか: デフラグしない
HDDのアクセス音・アクセスランプの点滅の感じの比較 ツール使った方が気持ち少なめ
その他　errorlog:無し,ファイル破損:5,Moniter:on,CacheKeep:1
使用時間：1時間4分
　　　　　　　ny起動前温度　　　　 メモリ使用量　　　　　　 　使用後温度 メモリ使用量
　　　　　　　 　　D0 D1　 　　ny起動前　ハッシュチェック後 　 　D0 D1
tool不使用　　　48　40　　　　　340　　　　　　418　　　　　　　　 46 39　　　　　495
tool使用　 　　　47 38　　 　　　342　　　　　　456　　　　　　　　 46 40　　　　　518
　　　　　　　　　　tool不使用　　　　tool使用
総送信量　　　 　1.812 GB　　　3.319 GB
総受信量　　　 1.172　　GB　　　179.20 MB
平均送信速度 488.69 KB/s　　888.35 KB/s
平均受信速度 316.20 KB/s　　46.83 KB/s

ドライブ0
�A総転送量 882,605 セクタ(451,893,760 バイト)
�B総ヘッド移動量 115,311,886,904 セクタ
�C総応答時間 127,303,240,362 nsec
�D総IOP数 12,631 個
�E連続した領域へのアクセス 7,885 回
�A÷�@=1秒あたりの転送量 226 セクタ(116,138バイト)
�B÷�@=1秒あたりのヘッド移動量 29,635,540 セクタ
�C÷�@=稼働率 3.2717 %
�D÷�@=1秒あたりのIOP数 3.25 個
�E÷�@=1秒あたりの連続した領域へのアクセス 2.03 回
�B÷�A=1セクタあたりのヘッド移動量 130,649 セクタ
�A÷�D=1IOPあたりの転送量 69.88 セクタ
�B÷�D=1IOPあたりのヘッド移動量 9,129,276 セクタ
�A÷�E=1連続アクセスあたりの転送量 111.93 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 14,624,208 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.60 個
ドライブ1
�A総転送量 5,449,048 セクタ(2,789,912,576 バイト)
�B総ヘッド移動量 2,149,609,592,813 セクタ
�C総応答時間 517,607,368,850 nsec
�D総IOP数 57,109 個
�E連続した領域へのアクセス 26,184 回
�A÷�@=1秒あたりの転送量 1,400 セクタ(717,016バイト)
�B÷�@=1秒あたりのヘッド移動量 552,456,847 セクタ
�C÷�@=稼働率 13.3027 %
�D÷�@=1秒あたりのIOP数 14.68 個
�E÷�@=1秒あたりの連続した領域へのアクセス 6.73 回
�B÷�A=1セクタあたりのヘッド移動量 394,492 セクタ
�A÷�D=1IOPあたりの転送量 95.41 セクタ
�B÷�D=1IOPあたりのヘッド移動量 37,640,469 セクタ
�A÷�E=1連続アクセスあたりの転送量 208.11 セクタ

�B÷�E=1連続アクセスあたりのヘッド移動量 82,096,302 セクタ
�D÷�E=1連続アクセスあたりのIOP数 2.18 個
↑不使用　使用↓
ドライブ0
�A総転送量 934,229 セクタ(478,325,248 バイト)
�B総ヘッド移動量 65,348,145,039 セクタ
�C総応答時間 101,670,059,352 nsec
�D総IOP数 12,123 個
�E連続した領域へのアクセス 7,032 回
�A÷�@=1秒あたりの転送量 239 セクタ(122,741バイト)
�B÷�@=1秒あたりのヘッド移動量 16,768,833 セクタ
�C÷�@=稼働率 2.6089 %
�D÷�@=1秒あたりのIOP数 3.11 個
�E÷�@=1秒あたりの連続した領域へのアクセス 1.80 回
�B÷�A=1セクタあたりのヘッド移動量 69,948 セクタ
�A÷�D=1IOPあたりの転送量 77.06 セクタ
�B÷�D=1IOPあたりのヘッド移動量 5,390,426 セクタ
�A÷�E=1連続アクセスあたりの転送量 132.85 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 9,292,967 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.72 個
ドライブ1
�A総転送量 8,407,730 セクタ(4,304,757,760 バイト)
�B総ヘッド移動量 1,398,697,832,689 セクタ
�C総応答時間 508,932,905,370 nsec
�D総IOP数 72,962 個
�E連続した領域へのアクセス 18,737 回
�A÷�@=1秒あたりの転送量 2,157 セクタ(1,104,633バイト)
�B÷�@=1秒あたりのヘッド移動量 358,916,559 セクタ
�C÷�@=稼働率 13.0596 %
�D÷�@=1秒あたりのIOP数 18.72 個
�E÷�@=1秒あたりの連続した領域へのアクセス 4.81 回
�B÷�A=1セクタあたりのヘッド移動量 166,358 セクタ

�A÷�D=1IOPあたりの転送量 115.23 セクタ
�B÷�D=1IOPあたりのヘッド移動量 19,170,223 セクタ
�A÷�E=1連続アクセスあたりの転送量 448.72 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 74,648,974 セクタ
�D÷�E=1連続アクセスあたりのIOP数 3.89 個

感想：涼しくなってきたなぁ…

保守

ホシュ

保守

もう一週間経った・・・秋の足並みは早いですね・・・。

>>96-99
報告ありがとうございます。
ファイル破損5が気になります。使用前は0でした?

>>103
現在の検査ツールだとそうチョクチョク出来ないんで
2・3日に1回がいい所かな。
例えば
検査→ツール無し→検査→ツール有り→検査
をやるとなると半日かかってしまう。

キャッシュの量を50Gとか減らすかな。

タイムスタンプが新しいファイルだけ検査するのも手かも。

とりあえず、検査するときだけ、別フォルダに移すとかしてみてはどうでしょう。
ツール自体に、日付を見てスキップする機能を持たせるのも手ですが・・・。

ほしゅ

ほ

OS:WinXP Pro SP2
ターゲットアプリ：Winny2b7.1
使用Ver:0.20.2
HDDの容量:250GB(Maxtor 7Y250P0)
キャッシュフォルダのドライブ番号:1(キャッシュのみに使用)
ダウンフォルダのドライブ番号:0
デフラグしてからの測定かどうか: デフラグしない
HDDのアクセス音・アクセスランプの点滅の感じの比較:
その他　errorlog:無し,ファイル破損:0,Moniter:on,CacheKeep:2,DiskFreeSpaceMargin:2560
使用時間：1時間00分
　　　　　　　ny起動前温度　　　　 メモリ使用量　　　　　　 　使用後温度 メモリ使用量
　　　　　　　 　　D0 D1　 　　ny起動前　ハッシュチェック後 　 　D0 D1
tool不使用　　　49 28　　　　　342　　　　　　423　　　　　　　　 49 41　　　　　534
tool使用　 　　　47 38 　　 　　341　　　　　　479　　　　　　　　 47 38　　　　　578
　　　　　　　　　　tool不使用　　　　tool使用
総送信量　　　 　1.785 GB　　　　2.082 GB
総受信量　　 　 299.17 MB　　　893.92 MB
平均送信速度　521.82 KB/s　　570.83 KB/s
平均受信速度　　85.39 KB/s　　239.27 KB/s
ドライブ0
�A総転送量 978,287 セクタ(500,882,944 バイト)
�B総ヘッド移動量 186,810,608,355 セクタ
�C総応答時間 269,520,827,450 nsec
�D総IOP数 19,864 個
�E連続した領域へのアクセス 14,965 回
�A÷�@=1秒あたりの転送量 274 セクタ(140,303バイト)
�B÷�@=1秒あたりのヘッド移動量 52,327,901 セクタ
�C÷�@=稼働率 7.5496 %
�D÷�@=1秒あたりのIOP数 5.56 個
�E÷�@=1秒あたりの連続した領域へのアクセス 4.19 回
�B÷�A=1セクタあたりのヘッド移動量 190,956 セクタ
�A÷�D=1IOPあたりの転送量 49.25 セクタ

�B÷�D=1IOPあたりのヘッド移動量 9,404,480 セクタ
�A÷�E=1連続アクセスあたりの転送量 65.37 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 12,483,167 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.33 個
ドライブ1
�A総転送量 3,791,662 セクタ(1,941,330,944 バイト)
�B総ヘッド移動量 2,462,473,249,983 セクタ
�C総応答時間 410,757,037,584 nsec
�D総IOP数 45,641 個
�E連続した領域へのアクセス 26,076 回
�A÷�@=1秒あたりの転送量 1,062 セクタ(543,790バイト)
�B÷�@=1秒あたりのヘッド移動量 689,768,417 セクタ
�C÷�@=稼働率 11.5058 %
�D÷�@=1秒あたりのIOP数 12.78 個
�E÷�@=1秒あたりの連続した領域へのアクセス 7.30 回
�B÷�A=1セクタあたりのヘッド移動量 649,444 セクタ
�A÷�D=1IOPあたりの転送量 83.08 セクタ
�B÷�D=1IOPあたりのヘッド移動量 53,953,095 セクタ
�A÷�E=1連続アクセスあたりの転送量 145.41 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 94,434,470 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.75 個
↑使用　不使用↓
ドライブ0
�A総転送量 1,013,176 セクタ(518,746,112 バイト)
�B総ヘッド移動量 116,469,744,957 セクタ
�C総応答時間 224,620,096,640 nsec
�D総IOP数 19,098 個
�E連続した領域へのアクセス 13,709 回
�A÷�@=1秒あたりの転送量 266 セクタ(136,619バイト)
�B÷�@=1秒あたりのヘッド移動量 30,674,149 セクタ
�C÷�@=稼働率 5.9157 %
�D÷�@=1秒あたりのIOP数 5.03 個

�E÷�@=1秒あたりの連続した領域へのアクセス 3.61 回
�B÷�A=1セクタあたりのヘッド移動量 114,955 セクタ
�A÷�D=1IOPあたりの転送量 53.05 セクタ
�B÷�D=1IOPあたりのヘッド移動量 6,098,530 セクタ
�A÷�E=1連続アクセスあたりの転送量 73.91 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 8,495,860 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.39 個
ドライブ1
�A総転送量 7,324,768 セクタ(3,750,281,216 バイト)
�B総ヘッド移動量 1,189,955,597,365 セクタ
�C総応答時間 470,001,937,446 nsec
�D総IOP数 64,117 個
�E連続した領域へのアクセス 15,717 回
�A÷�@=1秒あたりの転送量 1,929 セクタ(987,695バイト)
�B÷�@=1秒あたりのヘッド移動量 313,393,625 セクタ
�C÷�@=稼働率 12.3782 %
�D÷�@=1秒あたりのIOP数 16.89 個
�E÷�@=1秒あたりの連続した領域へのアクセス 4.14 回
�B÷�A=1セクタあたりのヘッド移動量 162,456 セクタ
�A÷�D=1IOPあたりの転送量 114.24 セクタ
�B÷�D=1IOPあたりのヘッド移動量 18,559,127 セクタ
�A÷�E=1連続アクセスあたりの転送量 466.04 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 75,711,369 セクタ
�D÷�E=1連続アクセスあたりのIOP数 4.08 個

>>105 フォルダ移動でかなり楽になりました。thx

守れ

>>108-110
あ〜コレStatHddActivityの結果逆だ。上がツール不使用、下がツール使用ね。

守

ho

shy

（・∀・）

>>108
報告ありがとうございます。

ファイルの破損はないようですし、
こちらでも1週間動かして気がつくような異常はないので、
以前のバージョンと同じくらいには安定しているようですね。

保

出かける前に

>>117
ん〜多分ny2pを使ったのが破損の原因じゃないかと
やはり想定してないソフトに使うと破損する可能性は高いよね
そもそも素のny2pがどうなのかって問題もあるし

nyを素で使っていても、破損になることもあるので、なかなか難しいです。
たとえば、メモリが微妙に不良だと、気がつかずに使い続けてしまうこともあると思います。


不良のメモリを掴んでしまったことが2回ありますが、恥ずかしながら、すぐには気がつきませんでした。

1つは、Windowsが普通に起動して、一見何事もなく使えるのだけど、週に1度くらいアプリが落ちる。
ここで、Windowsはやっぱり不安定だからな、なんて思ってしまうと、原因がわからなくなってしまう。
ちゃんとしたPCでは1年くらいはノートラブルで動き続けると信じて、メモリをチェックしたら判明。

もう1つは、メモリのチェックにもパスするけど、Windowsのインストールが、たまに失敗する。
やり直すと正常にインストールできるし、一旦インストールできれば正常かのように見える。
たまにDVD-Rを焼き損じるけど、安物メディアだからな、なんて思ってしまうと、やはり原因に辿り着けない。
Windowsのインストールが一度でも失敗するなら、どこか異常なんだ、
日本製のDVD-Rの品質がそんなに低いわけがないんだと信じて調べまくったら、
メモリのチェックのソフトが見逃すタイプのメモリの不良だと判明。

MXをやっていた頃、交換したAVIがしょっちゅう途中で壊れていた
当時は「MX自体がそういうもんなんだろう」位の認識だった

んで、同時進行で時々OSの98SEもフリーズしてた
こっちも「そろそろ再インスコかなぁ」位の認識だった
(98SEやMeまでのWinは定期的にHDD初期化しての再インスコをしないといけなかった)

しかしいざ再インスコしようとしても、CDのファイルをHDDにコピーする段階でエラー頻発
CD焼直してみても、借り物のプレスCD使ってもエラーが出る
ここに到って、やっとBIOSの設定でメモリチェックしてみたところ、見事エラー

メモリを変えると今までのトラブルが嘘のように安定しましたとさ