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

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の負荷を示す数値(温度等)も一緒に測定するといいかも
お約束
・全ては自己責任。転んでも泣かない
・ソース厨は保守要員です。大切に無視しましょう
・作者に過度の期待・要望・要求・強要は止めましょう　「〜すれば使用者が増える」よりもあなたがテスタをするために必要なことを書いてください
・分からないことがあったらこのスレで聞いてしまいましょう

2

過去スレ

WinnyからHDDを守るツールを作ろう Part2.1　←保守間に合わず
http://tmp5.2ch.net/download/kako/1125/11257/1125745687.html

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



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

テンプレ張り終わり。

>>1
にゅ

>>1
おちゅ

自治厨が立てた糞スレの典型だな。
そもそもHDDがそれくらいで壊れるもんじゃない罠。

同意、こんなツール作るのもそだが、使うやつもバカの典型

2日こなかったら落ちてたのか
MXの影響かね・・・
まだ安泰だけどやっとくわ

>>12-13
はいはい自演乙自演乙。
nyやりはじめたばかりの素人は黙ってろよ。

>>1
乙です。

Part2.1の過去ログは、
http://makimo.to/cgi-bin/dat2html/dat2html.cgi?tmp5/2/download/1125745687/
でも見れます。

せっかくの保安要員なんだから
そう邪険に扱わなくても。

ソース厨も居付くかと思ったらすぐ逃げ出したしなぁ…

ただ…前スレも保守の書き込みがかなりを占めていたわけで
テスト報告のないこのスレは確かに糞スレ
報告が増えるような仕組みが必要かも

開発の進行が遅くなっていて、あんまりネタがない、というのもあるのかも。

ソースの行数が増えるにつれて、どんどん変更しにくくなっているんですよねぇ。

>>1
乙なんだが最新ver.の所とかは直して書いてね

version 0.19.12Aをupしました。

0.19.12のテスト期間を約2ヶ月延長したものです。

0.20.xで不具合があった場合の比較に使ったり、
期限ぎりぎりで新しいのが出ても追いかけきれない方、
追いかけるのに疲れた方、
とりあえず そこそこ使えるものが欲しい方は、
しばらく0.19.12Aを試してください。


version 0.20.2の次のものは、
とりあえずコードは書いたものの、
まだ1度もテストしていない & まだSetup.exeを変更してない
ので、もうしばらくかかります。

FireFileCopyっぽくディスクアクセスする、
DisableOsBufferAndCache=1ですが、
バグ修正以来、様子を見てきましたが、
いまのところ問題なさそうです。
(すべてのパターンは網羅していませんが、
それなりにテストもしてあります。)

ディスクが溢れたり、異常終了したりしなければ、
問題はないだろうと思います。


DisableOsBufferAndCache=0のほうが良いと思われるケース
・Winny専用機で、他の作業のレスポンスは、気にしない場合。

DisableOsBufferAndCache=1のほうが良いと思われるケース
・Winnyを使いながらだと、ディスクキャッシュの効きが悪くなる場合。
・メモリが不足しがちな場合。

version 0.20.3をupしました。

変更点
・バッファのフラッシュで、先頭部分と後続部分の片方だけで十分なのに両方行っていた場合があったので、
　片方だけ行うように修正した。
・指定した拡張子のファイルのみをキャッシュ対象にする機能(InvertNoInterventionFileExt設定)を追加した。
・キャッシュ処理を無効にする機能(DisableCache設定)を追加した。
　これによりディレクトリ集合と空き容量の調整のみを使うことも可能になった。
・指定したディレクトリのファイルのみをキャッシュ対象にする機能(CacheOnlyExplicitDirectory設定)を追加した。
・指定したディレクトリのファイルへの書き込みを捨てる機能(DiscardWrite設定)を追加した。

※Setup.exeは、下3つの設定には、対応していません。

CacheOnlyExplicitDirectoryとDiscardWriteが、
ディレクトリ集合の設定に間借りしているため、
若干わかりにくくなってしまっています。

DiscardWrite設定を使うと、
特定のディレクトリにあるファイルを読取専用にすることができます。
(このプログラムにバグがなければ)それらのファイルへ書き込みは行われなくなります。

Winnyで使うと、
・キャッシュのヘッダの内容を更新しなくなります。
・読取専用属性のファイルであっても、Winnyがキャッシュとして認識するようになります。
・このツールのバグでキャッシュを破損することが予防できるかもしれません。
などの効果があります。

こまめな更新乙
正式版まだかな

otu

激しく乙

乙

いつも乙

キャッシュ専用のHDDくらい安いものだし、まる2年間動かしっぱなしだけどまだ大丈夫だ。

解説の更新も何とか…今回は結構変更点が多いので間違ってたらゴメン

話は変わりますがやっと「winnyの技術」発売決定みたい
ttp://nmag.jp/modules/wordpress/index.php?p=23

ほしゅ

ほしゅ

203いまんとこ不具合らしき不具合はなさげヽ( ´ー｀)ノ

>>25
まだまだ先になると思います。

多重ダウンロードや、1つのファイルを複数の相手にアップロードの時に、
現状のバッファリングのアルゴリズムだと、激しく効率が悪くなる

UIまわりがプアすぎる

Winny以外のアプリでも安全に動くようにする

などなど、正式版までにやらないといけないことが山積みです。


>>31
おつかれさまです。

一通り見させていただきましたが、
私がうまく説明できなかったことが、
わかりやすく説明されていて、素晴らしいです。

47氏の本は・・・Winny崩壊の引き金にならなければよいのですが・・・。


>>33
テストありがとうございます。

バグ報告だけでなく、普通に動いてるよ、という報告もありがたいです。
それがないと、動いているのか、動いていないのか、誰も試していないのか、まるでわからないので。

ほしゅ

ソース公開汁厨のぼくが戻って来ましたよ。

昨日このスレを知り、試しにv0.19.12Aを使わせてもらっています。
現在開発中なのは0.20.x系のようですが、v0.19.12AでのStatHddActivity結果も
開発の足しになりますか？
参考になるようでしたら計測して貼ります。
動作に関しては今のところ特に不具合もなく動いています。

>>37
ツールなし、v0.19.12A、v0.20.3で、StatHddActivityしてみました。

windows 2000
dual CPU
winny2.0 b7.1
WINTC
DisableOsBufferAndCache=1

toolなし　�@計測開始から0日01時間33分25秒 (5,605秒)

ドライブ2
�A総転送量 2,907,011 セクタ(1,488,389,632 バイト)
�B総ヘッド移動量 351,893,745,863 セクタ
�C総応答時間 173,577,082,316 nsec
�D総IOP数 29,378 個
�E連続した領域へのアクセス 24,500 回
�A÷�@=1秒あたりの転送量 518 セクタ(265,546バイト)
�B÷�@=1秒あたりのヘッド移動量 62,782,113 セクタ
�C÷�@=稼働率 3.0968 %
�D÷�@=1秒あたりのIOP数 5.24 個
�E÷�@=1秒あたりの連続した領域へのアクセス 4.37 回
�B÷�A=1セクタあたりのヘッド移動量 121,050 セクタ
�A÷�D=1IOPあたりの転送量 98.95 セクタ
�B÷�D=1IOPあたりのヘッド移動量 11,978,138 セクタ
�A÷�E=1連続アクセスあたりの転送量 118.65 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 14,363,010 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.20 個

v0.19.12A �@計測開始から0日01時間40分11秒 (6,011秒)

ドライブ2
�A総転送量 5,269,816 セクタ(2,698,145,792 バイト)
�B総ヘッド移動量 66,728,180,643 セクタ
�C総応答時間 110,712,935,564 nsec
�D総IOP数 30,221 個
�E連続した領域へのアクセス 24,195 回
�A÷�@=1秒あたりの転送量 876 セクタ(448,868バイト)
�B÷�@=1秒あたりのヘッド移動量 11,101,011 セクタ
�C÷�@=稼働率 1.8418 %
�D÷�@=1秒あたりのIOP数 5.03 個
�E÷�@=1秒あたりの連続した領域へのアクセス 4.03 回
�B÷�A=1セクタあたりのヘッド移動量 12,662 セクタ
�A÷�D=1IOPあたりの転送量 174.38 セクタ
�B÷�D=1IOPあたりのヘッド移動量 2,208,007 セクタ
�A÷�E=1連続アクセスあたりの転送量 217.81 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 2,757,932 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.25 個

v0.20.3　�@計測開始から0日01時間56分59秒 (7,019秒)

ドライブ2
�A総転送量 14,941,859 セクタ(7,650,231,808 バイト)
�B総ヘッド移動量 190,615,002,831 セクタ
�C総応答時間 305,780,873,165 nsec
�D総IOP数 100,831 個
�E連続した領域へのアクセス 75,687 回
�A÷�@=1秒あたりの転送量 2,128 セクタ(1,089,931バイト)
�B÷�@=1秒あたりのヘッド移動量 27,157,002 セクタ
�C÷�@=稼働率 4.3565 %
�D÷�@=1秒あたりのIOP数 14.37 個
�E÷�@=1秒あたりの連続した領域へのアクセス 10.78 回
�B÷�A=1セクタあたりのヘッド移動量 12,757 セクタ
�A÷�D=1IOPあたりの転送量 148.19 セクタ
�B÷�D=1IOPあたりのヘッド移動量 1,890,440 セクタ
�A÷�E=1連続アクセスあたりの転送量 197.42 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 2,518,464 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.33 個

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

結論以外を略せば1レスですむんでは?

ソース公開汁

ファイルアロケーション（ファイル情報テーブル）への
書き込みは大丈夫なのかな。

h

o

s

>>45
もう少し詳しくお願いします。

NTFSは仕組みを知らないからあれだけど
FATはファイルのデータ部分以外に
どのファイルがどのセクタに書き込まれているかの情報を記録する部分があると思う。
その書き込みがメモリにきちんとバッファされるのかなと思いまして。
当方過去に外付けUSBのHDDを新規購入時に書き込みエラーが頻発して
データが9割がたあぼーんしたことがありましてエラーメッセージに
「ファイルアロケーションテーブへの書き込み云々」という事がありました。
こうなるとデータはあっても探せない状態起きるわけで。

>>49
馬鹿が何やってるん？

>>51
うるせーよ馬鹿ｗｗｗｗｗ

何度も実験してないので、偶然なのか仕様なのか判別できてないのですが、
ツールを起動している場合は起動していない場合に比べて
UPフォルダのキャッシュチェックにかかる時間が長いように思います。

断片化している1Gのファイルをチェックするのに、
ツール有り：30分で15%も進まず
ツール無し：5分かからず終了
といったことがありました。

>>50
このツールは、ファイルシステムの管理領域の読み書きには、一切手を触れていません。

いくらファイルの中身へのアクセスを連続したものにしても、
ファイルの中身と管理領域の間でヘッドが交互に移動するのではないか、
という心配はあるとは思います。

それには3つの答えがあります。

(1)
ヘッドの移動量を究極まで減らすことではなく、
それなりに減らせれば十分で、
危険なことをしてまでヘッドの移動量を減らすのは、割りに合わないと思います。

(2)
ファイルシステムの管理領域へのアクセスの順序をいじることは、
NTFSを台なしにしてしまうことなので、やるべきではないと思います。

(3)
ファイルの中身と管理領域の間でヘッドの移動はあるけれども、
パフォーマンスが問題になるほどは頻繁にならないようにOSのファイルシステムが工夫している。

>>54
頭大丈夫？

>>53
それは先読みが激しく無駄になってしまっているからだと思われます。
それは、どのバージョンで発生しましたか?
バージョン0.20系では、大幅に改善している・・・はずなのですが・・・

お手数ですが、このツールのアクセスログを有効にして、
ログファイルから、UPフォルダをチェックしている部分を切り出して、
ここに貼っていただけませんか?

そうすれば、原因がわかりますし、対策できるかもしれませんので。

> 対策できるかもしれませんので。

どーせ対策なんかしないくせに。

デバックでいろいろ見ましたが、ちょっとした仕掛けがしてありますね。
少しでもプログラムかじってるなら一度でバックかけて見ましょう。
いろいろ驚く事実がわかりますので。
当然私は踏み台にされたくはありませんので、使わないですが（笑

やっぱりなんかあるのかな。
やばそうかな。

踏み台ってトロイとかって意味かな。

少しでもプログラムをかじっている人間なら
　>デバックでいろいろ見ましたが、
こんな言葉は出てこないと思った。

>>58はスルーしる。
スレに粘着している荒らしが何の根拠もなく言ってるだけだ。

本当に変なものが仕込まれているなら、具体的にどんな悪さをするのか、
その発動条件がどうなっているのか、詳細に解説して丸裸にするだろう。
ついでに、警察にも通報したりするだろ。トロイを作るのは犯罪なのだから。

保守乙

> 本当に変なものが仕込まれているなら、具体的にどんな悪さをするのか、
> その発動条件がどうなっているのか、詳細に解説して丸裸にするだろう。

わざわざ求められてないものを解説する必要もないと思われ。

> ついでに、警察にも通報したりするだろ。トロイを作るのは犯罪なのだから。

何て罪？

トロイ罪

本日の透明あぼーん推奨IDは
7cy+YhIv0
です。
こいつの言ってることは真に受ける必要なし。スルーしる。

55 名前：[名無し]さん(bin+cue).rar[maage] 投稿日：2005/09/28(水) 00:54:31 ID:7cy+YhIv0
>>54
頭大丈夫？

57 名前：[名無し]さん(bin+cue).rar[] 投稿日：2005/09/28(水) 01:01:05 ID:7cy+YhIv0
> 対策できるかもしれませんので。

どーせ対策なんかしないくせに。

64 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2005/09/28(水) 02:14:42 ID:7cy+YhIv0
> 本当に変なものが仕込まれているなら、具体的にどんな悪さをするのか、
> その発動条件がどうなっているのか、詳細に解説して丸裸にするだろう。

わざわざ求められてないものを解説する必要もないと思われ。

> ついでに、警察にも通報したりするだろ。トロイを作るのは犯罪なのだから。

何て罪？

いつもどおりのスレだな

>>66
他人にはスルーを要求しているにもかかわらず、
何で藻前はスルーできないの？

しかし何度もDAT落ち＝需要が無いってのに作者も粘着だねぇ。

キャッシュチェックに時間のかかるファイルへ差し掛かった所のログを抜粋しました。
ファイルのパス名は******と加工してます。
実際のログには、5MBほどキャッシュチェックした時点で
そのファイルに関する記述が約1600行ほどありました。

08:27:52.312 handle=19C Open K:******
08:27:52.312 handle=19C App-> Read 0-FFFF 65536bytes
08:27:52.312 handle=19C ->Sys Read 0-7FFF 32768bytes
08:27:55.953 handle=19C ->Sys Read 8000-1407FFF 20971520bytes
08:27:56.140 Read Cache hit=0, miss=2, ratio=0.00 / Write Cache delay=0, flush=0, ratio=0.00
08:27:56.140 handle=19C Close (with cache)
08:27:56.171 handle=230 Close (no cache)
08:27:56.234 handle=230 Open K:******
08:27:56.234 handle=230 App-> Read 10000-1FFFF 65536bytes
08:27:56.406 handle=230 ->Sys Read 10000-140FFFF 20971520bytes
08:27:56.593 Read Cache hit=0, miss=1, ratio=0.00 / Write Cache delay=0, flush=0, ratio=0.00
08:27:56.593 handle=230 Close (with cache)
08:27:56.593 handle=230 Open K:******
08:27:56.593 handle=230 App-> Read 20000-2FFFF 65536bytes
08:27:56.765 handle=230 ->Sys Read 20000-141FFFF 20971520bytes
08:27:56.968 Read Cache hit=0, miss=1, ratio=0.00 / Write Cache delay=0, flush=0, ratio=0.00
08:27:56.968 handle=230 Close (with cache)
08:27:56.984 handle=22C Open K:******
08:27:56.984 handle=22C App-> Read 30000-3FFFF 65536bytes
08:27:57.156 handle=22C ->Sys Read 30000-142FFFF 20971520bytes
08:27:57.343 Read Cache hit=0, miss=1, ratio=0.00 / Write Cache delay=0, flush=0, ratio=0.00
08:27:57.343 handle=22C Close (with cache)

◆aBeASKncAIですが、もう完全に頭にきました
このトリップも捨てました、というか頭に来てカッカしてしまって
ソース入ってるＨＤＤ消してしまい、同時にトリップも消えてしまいました。
まぁもう名無しに戻るので、トリ喪失も関係ないですがwww

とりあえずもうここには書きませんし、二度と見ません。
お前らの低レベルには完全に頭に来ましたから。

書き忘れました。
バージョンは0.20.3です。

CacheKeepCountも書いた方がいい気がする

>>71
偽？

>>74
>>7

>>70
ログのコピペありがとう。

設定ファイルの
CacheKeepCount=0
を、とりあえず
CacheKeepCount=10
に変更してみてください。

iniファイルを直接編集するのではなく、GUIで設定する場合には、
「ファイルを閉じてもすぐにReadバッファを破棄せずに□個まで保持する。」
という設定のところで、□の中に10と書いて、[終了(X)]ボタンで設定画面を閉じてください。

それでもNGという場合は、別の対策を考えます。



バージョンアップした時に、
前のバージョンの挙動に近い動作をする設定をデフォルト値にする
というのを、なんとなく方針にしているのだけど、
今回は、それが裏目に出てしまいました。
せっかく、機能を改善したのに、デフォルトだとそれが無効なわけで・・・。

>>76
CacheKeepCountを0から10に変更したところ、
キャッシュチェックの速度がツール非使用時と同等程度まで早くなり、
改善されました。

このツールを咬ませてNYやるの無理かなぁと思っていたところでした。
ありがとうございます！

たもつ

保守

たもつまもる

◆aBeASKncAI もスルーを憶えてよかった

保守

ほしゅ

保

っしゅっしゅ

しゅっしゅしゅ

ちゅちゅちゅ

保守

ほっしゅ

あげ

◆

こういう保守ばかりのスレは削除に該当すると思われます。
削除依頼。

保守で4日目にもなるのか。
いい加減私的にスレを占有していることに気付けよ。
頼むからこれ以上続けたいなら自サイトで掲示板開いてそっちでやってくれ。

作者さん、こんな煽りはスルーですよ。

>94
いやいや、保守だけのスレが削除に該当なら構う方が妥当かとｗ
もしくは保守じゃなく、｢期待sage｣とか
あー 作者さんのチラシの裏でもいいな

次落ちたらソフト板かWin板あたりに移動した方がよくないかな

>>93
自治厨乙

ばーじょんマダ〜
とでも書いておくか

じゃあ雑談でもするか(´ー｀)y-〜

保守だけになってしまったスレはスレストだろうけど、
保守だけというわけではないからなぁ。
ちょっと進行がﾏｯﾀﾘしているだけだろう。

書き込みの間隔があいたときに、運悪くDAT落ちしてるだけで、
それも3回のうち2回は、VIPPER襲来とMX閉鎖騒動だしな。

>>96
ﾀﾞｳｿにｶｴﾚと言われ続ける希ガス

作者のチラシの裏は、私的にスレ占有と叩かれるだろうから、このツールに関する話をしよう。

設定どうしてる?
Winnyの最適設定どうすればいいか、よくわからない。

version 0.20.3での設定例です。

■新しい機能も試す場合
[Global Configuration]
DisableOsBufferAndCache=1
EnableActivityLogging=0
CacheSizePerEachFile=0
DiskFreeSpaceMargin=2048
SpecialFileHeadArea=32
DirectoryAggregation=0
DirectoryAggregationStrategy=1
EnableDeleteFileOnAggregatingDirectory=1
ApiHookStrategy=2
NoInterventionFileExt=txt|ini
ChildProcessTimeout=60
EnableMonitor=1
CacheKeepTimeSec=60
CacheKeepCount=10
InvertNoInterventionFileExt=0
DisableCache=0
CacheOnlyExplicitDirectory=0

■新しい機能は避ける例
[Global Configuration]
DisableOsBufferAndCache=0
EnableActivityLogging=0
CacheSizePerEachFile=0
DiskFreeSpaceMargin=2048
SpecialFileHeadArea=32
DirectoryAggregation=0
DirectoryAggregationStrategy=1
EnableDeleteFileOnAggregatingDirectory=1
ApiHookStrategy=2
NoInterventionFileExt=txt|ini
ChildProcessTimeout=60
EnableMonitor=0
CacheKeepTimeSec=60
CacheKeepCount=0
InvertNoInterventionFileExt=0
DisableCache=0
CacheOnlyExplicitDirectory=0

補足説明

EnableMonitorを1にすると、Winnyのキャッシュ変換などが若干遅くなります。
CacheKeepCountは大きな値にすると、それだけメモリを消費します。

メモリ消費量は概ね、
(アプリケーションが同時に開いているファイルの数 + CacheKeepCountの数) x CacheSizePerEachFile
となります。

たとえば、
CacheSizePerEachFile=0 (この場合、現在のバージョンでは10と見なされます)
CacheKeepCount=10
の場合、ULとDLがそれぞれ5の場合、約200MBのメモリを消費します。

CacheKeepCountの値の選び方は、Winnyの使用状況によって、かなり変わってきます。
とりあえず、UL本数 + 1〜5くらいにすると、いいかと思います。

俺、メモリ2G乗っけてて結構余裕あるから
値おっきくしてもいいのかな？

大きくしても大丈夫です。
いきなり大きくすると、メモリが足りなくなった時に悲惨なので、様子を見ながら、設定値を大きくしてください。

ただ、あまり大きくしても、効果が変らない or 逆効果になることが予想されます。
CacheKeepCountを大きくすると、無駄にメモリを食うことになりかねません。
CacheSizePerEachFileを大きくすると、先読みが無駄になる量が増えます。

■■■■■■■■■■■■■■■■
■　　　　　　　　　　　　　　　　　　　　 ■　　違う板にコピペすると、四角の枠の中に
■　　　　　　　　　　　　　　　　　　　　 ■　　メッセージとURLが現れる不思議な絵。
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　（その仕組みがリンク先に書いてある）
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　この原理を応用すると、まったく新しい
■　　　　　　　　　　　　　　　　　　　　 ■　　コピペが作れる予感。
■■■■■■■■■■■■■■■■

ほしゅ。

SetupやMonitorのウィンドウサイズを、
画面が1024x768以上を前提に、
今よりも、もっと大きくしていいかなぁ。

そろそろタブコントロール等で分割しようかとは思っているのだけど、
タブって、作る側も使う側も、いちいち切り替えないといけないので、
もうしばらくは、ウィンドウを大きくして済むなら、大きくしようかと。

もっとつめるのはどう？
あとチェックボックスとかのキャプションはiniのkey名にして
説明はツールチップに押し込むとか。


ファイルを閉じてもすぐにReadバッファを破棄せず[＿＿]個まで保持する。
　　　↓
CacheKeepCoun[＿＿]
チップに「ファイルを閉じた後、Readバッファを破棄せずに保持する数」

□ディスクアクセスの様子をログに記録する。（若干重くなり、巨大なログガイルができる。）
　　　↓
□EnableActivityLogging
チップに「ディスクアクセスの様子をログに記録する。（若干重くなり、巨大なログファイルがサマソ。）」

（ ´_ゝ｀）

ヽ(冫､)ﾉ

iniファイルでの名前を使うと、iniファイルやReadmeと表記が一致して良い面もあるのだけど、
iniファイルと同じ表記なら、iniファイルを直接編集するのと大差なく、GUIにする必要がない気がします。

ウィンドウのサイズについては、どうですか?

俺は大きくても問題無いっす。

version 0.20.4をupしました。

変更点
・モニタに出力する情報を増やした

こういう人にあこがれるです
俺も皆に見返りを求めない、尽くすプログラマンになりたかとです('∀`)

>>113
本当にお疲れ様です(　´∀｀)σ)∀`)

モニタに、新たに「統計情報など」という欄を増やしました。
そこには、↓のような表示が出ます。

---------------------------------------------------------------------------
現在キャッシュに使用しているメモリ： 0 MB

ファイルアクセスの累計
Readキャッシュ： ヒット 2 回、ミス 617 回、ヒット率= 0.32 %
Writeキャッシュ： 遅延 0 回、フラッシュ 0 回、遅延率= 0.00 %
ReadFile呼び出し回数： アプリから 634 回、OSへ 629 回、Ratio= 99.21 %
ReadFileバイト数： アプリから 38,381,277 バイト、OSへ 38,378,461 バイト、Ratio= 99.99 %
WriteFile呼び出し回数： アプリから 222 回、OSへ 222 回、Ratio= 100.00 %
WriteFileバイト数： アプリから 112,538 バイト、OSへ 112,538 バイト、Ratio= 100.00 %
---------------------------------------------------------------------------

ReadFile、WriteFileというAPIの呼び出しが、
アプリ→このツール→OS
というルートで行われます。
「アプリから」というのは、このツールがアプリから受けとったAPI呼び出しで、
「OSへ」というのは、このツールがOSに行ったAPI呼び出しです。

ヒット率、遅延率は、ヒット+ミス、遅延+フラッシュに対するヒット、遅延の割合です。
Ratioは、「OSへ」に対する「アプリから」の割合です。

キャッシュ処理中のファイルの欄には、Openしているファイルしか表示されません。
Open→読み書き→Close
をくり返すアクセスは、ほんの一瞬しか表示されないので、見えないと思います。

前のバージョンから、Writeキャッシュについて、
「ヒット」→「遅延」、
「ミス」→「書き出し」or「フラッシュ」
のように表記を変えています。

一時停止のチェックは、表示内容の更新を一時的にやめているだけで、内部ではカウントしています。
一時的に集計から除外する目的では使えません。

統計情報欄は、コピペしようとして範囲選択しても、内容が更新されると、選択が解除されてしまいますので、
コピペしたいときは、表示を一時停止させてください。

副作用として、表示をしないことで、ディスクアクセスが若干軽くなります。
たとえば、フォルダのチェックなどは、5割ほど速くなるようです。

作者タン、いつも感謝してますｱﾘｶﾞﾄ!(´▽｀)

御疲れさんです

なんか0204にﾊﾞｰｼﾞｮﾝしたら
不完全キャッシュになる事が多くなったような気がする

>>119
変更点をよく読んでから書き込もうね

いつも乙

これってHDDの負担が減るのかもしれないが
PC自体の負荷は増えそう。
よくあるのがRAID組んだら返って遅くなったっていうパターンにならないかな。

>>119
今回はバッファリング処理はいじってないはずなのですが・・・。

・今の状態
・設定ファイル以外をversion 0.20.3に戻した状態
の2つで、どのような違いが出るか、比較してみてください。

以前の設定ファイルが残っているなら、
・version 0.20.3の時の状態
・設定ファイル以外をversion 0.20.4のもので入れ換えた状態
の2つで、どのような違いが出るか、比較してみてください。


>>122
それは負荷を測定してみないことには、何とも。

もしも、
このツールの負荷よりも、
このツールの働きによって他の部分での負荷が減れば、
トータルでは負荷が減ります。

前スレで出ていた、
キャッシュのUPで、先読みが激しく無駄になっている件、改善しましたでしょうか。


バッファリングについては、あと3点ほど残課題があり、ぼちぼち改善中です。

■OpenとCloseを頻繁に繰り返される
Readバッファについては対処しましたが、
Writeバッファについてはまだです。

おそらくキャッシュのヘッダにある被参照量を更新しているのだと思うけど、
それを1ブロック読む度にやっていて、なおかつ都度ファイルを閉じているので、
現状のようにCloseされた時にWriteバッファをファイルに書きだしていては、
無駄なディスクアクセスが生じてしまう。

また、OSがファイルの最終更新時刻や最終アクセス時刻を記録しているので、
ファイルの中身だけではなく、管理領域をも頻繁に書き換えることになってしまう。

■1つのファイルを複数の場所で読み書きする
多重ダウンロード等、1つのファイルを複数の箇所でシーケンシャルアクセスしている。
それぞれに注目すればシーケンシャルだが、ファイル単位で見ればランダムアクセスに見える。

Writeバッファは働きが悪くなるだけなのでいいが、
Readバッファは先読みが無駄になるので良くない。

■最適なバッファ容量
10MBで十分だとは思うけど、
先読みに関しては10MBだと多すぎる場合もあり・・・

◆aBeASKncAIさん乙です！

version 0.20.5をupしました。

変更点
・コンパイラの最適化を有効にしてみた。
・アプリがWinnyの場合は、exeファイルへの書き込みを阻止するようにした。←これはReadme.txtには書いていません。

このツールの中で例外が発生した時に、
ログに十分なデバッグ情報が記録されなくなる(かもしれない)代わりに、
ほんの少し、動作が軽くなると思われます。
(このデバッグ情報の出力機能は、一度も出番がないようなので・・・)

exeファイルへの書き込みを阻止する機能はオマケです。
この機能をあてにせず、ウィルス対策をしっかりしてください。
御守りみたいなもので、ないよりは、あったほうがいいけど、滅多に役に立たないでしょう。
とはいえ、役に立つこともあるので、ぜひとも、このツールを併用すべきです。(完成版じゃないけど・・・)
個人的には、Winnyを生で使うのは、ウィルス感染のリスクがかなりある、と思っています。
怪しいファイルをクリックしなければいい、と思っている人は、自信過剰だと思います。
落とし穴は思わぬところにあるものです。

なお、>>124については、このバージョンでは未対応です。

このツールにトロイの木馬でも入れてるんじゃないか? とか言われそうだなぁ。
そんなものは入れていません。

なんで急に、こんな機能を付けたのかというと、47氏の本が発売になったからです。
私はまだ読んでいないのですが、Webで公開されている目次を見たところ、
Winnyをターゲットにしたウィルスが、今までとは別次元の凶悪さを持つ可能性があるからです。

なんでここでウィルス、exeファイルが出てくるのかな。

それを説明しはじめると、悪意のある人にヒントを与えることになりかねないので・・・。

それでは貴方が首謀者になりかねませんよ。
少なくともここに書き込んだ以上は。
プログラム開発に携わるもの、その辺のモラルはしっかりしておかないと。
47氏の本からセキュリティホールを見つけて
「こうなる可能性がある」と危険をい匂わせることを書き込むのは
自分でもウィルスを作れますよと言っているのと同じです。
はっきり言ってそんな人がWebサイトや掲示板で大っぴらに
「こういうソフトを作っています」という資格があるのでしょうか。
このスレも含めてログは残ります。

「自分は具体的にセキュリティホールを見つけられなかったが、
詳細が公開された以上、ひょっとしたら誰かが重大なセキュリティ
ホールを見つけ、悪用するかもしれない。
念のためにセキュリティを強化しておこう」
って心理は理解できないかな？

ある程度複雑なプログラムを書いた経験のある者なら理解できると思うが
そういう経験があるにもかかわらず、理解できないのならセキュリティに
対する危機感が足りない、と言わざるを得ないが

それではこのソフトでセキュリティが守られるのですか？
これはあくまでもキャッシュの書き込みを最適化して
ハードディスクの負荷を軽減するものでしょう。
いきなり実行ファイル云々とか、47氏の本が出版されるとすぐに
こういった事を書き込むのはある意味表現の裏返し
もっと言えば「俺はこれだけのものが作れるんだ」という
ハッカー精神の表れではないでしょうか。
問題の書き込みは>>129です。

面倒なんで箇条書きで

１　このソフトはセキュリティを守るためのものではない

２　「この部分が危ないかもしれない」と思ったとして、既にWinnyは47氏の手を離れている以上
　連絡して穴を塞いでもらう、等の手段は取ることが出来ない

３　２を踏まえて「その部分」を公言することを控えるのは当然

４　２、３を踏まえて該当しそうな部分をセキュアなコードに変更するのは褒められこそすれ
　非難されるようなことではない

まぁなんだ、文句は自分で同等かそれ以上のものを公開してからにしろ

２の補足

場合や条件にもよるけど、現実にWinnyがかなりのノード動作してる以上、勝手にセキュリティ上の穴を
ふさいだVerをリリースすることが出来たとしても大半のノードは移行しないことが予想される
そういう状態でセキュリティホールを公言するのはいかにも不味い、ってのも考慮してくれ

眠くて判断力が低下しているので、今はとりあえずレスは保留させてください。
とりあえずversion 0.20.5の公開を一時停止しておきました。

けっこうな人達が、知っていながら沈黙を守ってきた事柄だと思うので、下手に書くと薮蛇になるので、難しい。
とりあえず47氏の本の内容をチェックしたほうが良さそうですね。目次だけ見て先走ってはいけないから。

なぜ公開を停止されるのでしょうか？
バグでもあるのでしょうか。それともオプションのプログラムに問題でもあるのですか。
なぜ>>129、そして>>127のような書き込みをされたのか。
「私はセキュリティホールを知っていますよ」と公言しているようなものでしょう。
それを私が指摘したからといって公開を停止されるのはおかしいのではないでしょうか。
このソフトはハードディスクの負荷を軽減するもの。
Winnyのセキュリティとは関係無いはずですが。

閉鎖的な住人のせいで製作者が迷惑を被る典型例だな
部外者はあまり口出さないほうがいいぞ

おれのパソコンで重くならずに動くなら別にどんな機能つけてもかまわん

◆aBeASKncAI
スルーよスルー。思い出すのよ！！

閉鎖的な雰囲気の中
内部犯の仕業に見せかければ
疑心暗鬼でぐだぐだになる。

つまり保守乙

ようはwinny自体がウイルスと置き換えられてた場合のことじゃないの？

昨晩は、眠くて、ちゃんとレスできなくて、すみません。

version 0.20.5の公開一時中止は、
とりあえず公開続行するよりも、
とりあえず公開一時中止するほうが、
よく考えていない状態では、
フェールセーフ側だと思い、そうしました。

まず先に、すべての疑問に対して答えられないことを了承ください。

47氏の技術に陶酔している人達から睨まれるし、
大した技術もない私が、人様の為したことについて、
とやかく言うべきではないので、あまり言いたくないのだけど・・・

ソースのようなものを見て、
Winnyはネットワークを使って他者と通信するソフトの割には、
セキュリティに対して全体的に配慮がされていないという印象を受けました。

それを言うと、
そういうことはお前がWinny以上のものを作ってから言え
というお叱りを受けると思うし、
Winnyが危ないという話が広がればユーザが減ってしまうし、
もし具体的に問題点を見つけて指摘しようものなら、
バージョンアップがなくなって終焉へと向かっているのを加速してしまうので、
ソースのようなものを見た人の多くが、そこで見たことを黙っているのだと思います。

気休め程度だけど、
EXEファイルへの書き込みくらいは阻止しといたほうがいいかな、
ということで、機能を追加したわけですが、

EXEファイルへの書き込みを阻止したくらいで、
このツールを使えば大丈夫だよ、とは言えません。
そういった生兵法は、かえって危険です。

また、本当にEXEファイルをダウンロードすることを望む人にとっては、
このツールは、ユーザの意図を妨害する、悪いツールに見えもしましょう。

ということで、version 0.20.5は公開をやめます。
オマケなんていう生半可なことで、
セキュリティ向上を狙った機能を実装するのは間違いでした。

それから・・・

荒らしの人が、このツールへの不信を煽っていますが、それに惑わされないでください。

ウィルスのように出どころの特定が難しいものと違って、
Webで公開しているソフトにトロイの木馬を仕込むことは、かなりの蛮勇というか馬鹿だと思います。
私は釣られやすい馬鹿ではあるけれども、トロイの木馬を仕込むほど馬鹿ではありません。

シェアウェアにトロイの木馬を仕込んだ人の前例がいくつかありますが、
そのあまりに低いモラルと、解析されたりはしないだろうという図太い神経には、呆れるばかりです。

さらに・・・
蛇足だし、スレ違いだけど、皆さんのためを思って、書いておきます。

セキュリティを確保するためには、全てを疑うことが基本です。
オープンソースの有名なソフトでさえ、脆弱性が見つかったりしています。

しかし、Winnyは、脆弱性の有無のチェックは行われていないでしょうし、
もし第三者がチェックして発見しても、修正されないでしょうから、
何らかの脆弱性があるのにパッチが出ていないソフト
と見なして扱ったほうがいいです。

凶悪なウィルスに感染しても被害が出ないように、
しっかり隔離した環境で使うべきです。

ただ単にWinny専用PCで使うだけでは、
LAN上の他のPCにも感染が広がってしまうので、
ファイアウォール等により他のPCとの通信をすべて遮断すべきです。

・・・

問題点を見つけて具体的に指摘するでもなく、
そういうことを言うのは、よくないだろ

というツッコミを入れる無粋な人が現れる予感。

ちなみに、まだ47氏の本は読んでいません。
47氏がPDFで配布すると言ってるので、それを待ってます。

すでに読んだ人の書き込みを見ると、
Winny互換クライアントや、
キャッシュ捏造ツールが、
いくつも出てくる嫌な予感がします。

今まで、自力で逆アセンブルした人や、ソースのようなものを読んだ人は、
技術的には可能でも、やっていいことと悪いことの区別がつく人達だったけど、
敷居がぐっと下がることで、どうなることやら・・・

>>147-148
ここでソフト開発する事についてはとやかく言うつもりは無いが
ここは貴方の日記じゃないんだから、そういう事について
あれこれ言いたいなら、自分のサイトでやってくれ。

というか、Windowsの場合。パッチを当てさせるために、
店頭にCDを配布したりしたよね。
あまりに広がったソフトである以上。
国としては、悪意ある集団（個人かもしれないけど）が
ネットを破壊してしまうなんて
最悪な事態も考える私としては。Y2K問題並に対策はすべきと考えるのは、
少々大げさではあるが、影響がどのくらいかは知りたい

結局EXEとかファイルになにかしようっていうツール。

Windowsは使うなとは言えないし、パッチで解決できる。
Winnyはパッチは作れないから、使うなと言うしかないだろ、政府は。

印象とか言ってるわけで、◆aBeASKncAIが問題を発見したわけではないのだろ。
なら、そんなに大騒ぎすることないんじゃないか?

◆aBeASKncAIは、やたら警告するのが好きな性格らしいから、スルーしようぜ。

あやしい。

>>153
OK.
ここは貴方の日記じゃないんだから、そういう事について
あれこれ言いたいなら、自分のサイトでやってくれ。

どっちにしても開発中止になってるね。

　

>>58
>>143

第3者から見ると根拠も示さず危険性を煽っている
とういう意味では非常に良く似ている。違いはせい
ぜいトリップの有無くらいなもの。

本当に根拠があると思うなら
ttp://jvn.jp/index.html
ttp://www.ipa.go.jp/index.html
あたりに連絡すれば？非公開で対応してくれるだろうし
作者は対応できなくても本当に問題があればセキュリ
ティベンダが何らかの対応を考えるだろうし

デバッグのことをデバックとか言ってる時点で釣りだから

またやってるの？

保守乙

hoge.txtを登録しておいたらリネームされてて
hoge.txt 　　　　　　　　　　　　　　　　　　.exe
が出来ていたとかそんなところジャマイカ

なんだその天から見下ろしたような態度は。そんなんだから疑われるんだよ
って結局想定通り結果になったな。
単にファイル落として喜んでるやつばかりいるんじゃないと思われ。
某社の工作社員か。

もし開発が続いてたらセキュリティの問題は解決されてたんじゃないの？

もう何をしてもダメだろ。もう退路はないよ。
ずっぽり罠にはまって、抜け出そうとすればするほど、どんどん深みにはまる。
作者はこの件について、何を言われようと、一切口をつぐむしかない。

セキュリティのバグってどのレベルのバグなんだろう。
Winny使ってるやつの個人情報が問答無用で流出してしまうようなレベル？
そうなら百万単位で広まってしまったソフトの責任として47氏に警察がUpdateを依頼したりして。

どうでもいい事に反応して急に荒らしが増えたな。
まあ、保守になるからいいけど。

作者は2chでやるのをやめたほうがよくないか。

Winnyの欠点を補おうとしている作者を、
47氏の技術にケチを付ける輩だとして、叩いてみたり、
とくに理由もなく荒らして悦にいってみたり、
そんな相手する価値のないような屑人間の巣窟だぜ。
何かの理由があって妨害したい工作員もいるだろう。

2chにはまともな人が大勢いるけれど、VIPとこの板だけは例外だ。
とくにこの板は、犯罪者の巣窟だし、47氏を利用しておきながら、
その責任は負わないような連中ばかりだ。

作者が善意でやっていても、本当に感謝する人間なぞいない。
トラブルに巻き込まれて大変な目にあう前に、やめるべきだ。

今ターミネーター３を見た
よくわからんソフトウェアが世界中のパソコンに散らばってそれぞれの端末が人間に反発しだすらしい
中枢がないので止められないらしい


うぃにーもそういうソフトウェアに改造されるということですね！
作者はそれを心配しているのですね！！１１１１１

Winnyのバージョンアップは望めない、欠陥が見つかっても直しようが無い、バグを見つけても
直せないので報告してもいたずらに不安を煽るだけで意味が無い。
こんなことはわかってるくせにそれでも報告するもんだから叩かれる。
不安を煽ってでも具体的なことは一切言えません。アホか。だったら最初から何も言うな。

後悔してます。
もっとドライにやらないとダメだったんです。

何か秘密の機能が仕込まれているのではないかという書き込みがあっても気にせずに、馬鹿正直に言ったりせずに黙って対策機能を忍ばせるか、
さもなくば、
対策機能を付けることができても、あえてそれをせず、被害が出たとしても、自分の責任ではないと気にしないか、
どちらか、betterなほうを選ぶべきだった。

ついつい欲を出して、存在しないbestを選ぼうとして、失敗してしまったわけです。
それと、口は災いのもとだから、なるべく余計なことは言わない、ということですね。

以上、
この件については、これを最後のまとめとし、
この件については、以後は発言しませんので、
この件については、質問等を書くのはやめてください。
Winnyの安全性については、このスレのテーマではないので、
必要であれば、別のスレで行うようにしてください。

ということで、この件は終わりにして、
HDDアクセスを改善する機能について作業します。

version 0.20.4からモニタにだす情報を増やしたのですが、どうですか。
キャッシュはどれくらいヒット・遅延していますか?
ReadFileはどれくらい無駄に先読みしてしまっていますか?

乙。がんがれ。

>>171
＞口は災いのもとだから、なるべく余計なことは言わない、ということですね。
とか言いつつもう余計なこと言ってんじゃん

この人、相当神経質というか2ちゃん向きじゃないね

>>173
それはかなり前のスレでも言われてたな。
したらばあたりの自前板でやればスレの意向に左右されることなく
妙な煽りにイライラすることもなくできると思うんだけどなぁ。
掲示板の設置が面倒なのかね。

有志が使い方サイトまで設置してくれたんだから
ついでに掲示板管理もたのんじゃえばいいのにな。

>>171
ドライじゃなくてすこーし餅つけばいいと思うよ。
すでにnyには何かしかホールがあるらしいことはアンタの弁で皆気付いちゃったんだし。

どうせny側で塞がれないホールなら今のうちから対策ツールとして広めちゃえば
それこそ神扱いされるんじゃね？
ま、nyとの関連性をサイトの記述レベルで気にする作者だから
そんなもん発表したくはないのかもしれないがね。

ratio=△△%とか出るけど
どの項目が多いほど良いのかがわかりにくい

ここは日記帳じゃないんで。
そういった開発日誌は自分でブログでも作ればいいのに
２ちゃんのルールに触れるようなら削除依頼出しますよ。

>>171

このスレは、おまえの個人所有物ではなかろう。
おまえみたいなやつを鼻持ちならない奴と言う。

ny脆弱性をほのめかしているが、
そういう根拠の無い仄めかしは、
ペテン師か単に実力の無い者の常套手段だ。

プヒー

2chに向いてない作者だな

来てみたらタッグを組んで頑張ってくれてるね
保守を気にしなくてよさそうだ

保守代わりになっていいよな。

公開止めればいいのに

S:WinXP Pro SP2
ターゲットアプリ：Winny2b7.1
使用Ver:0.20.4
HDDの容量:250GB(Maxtor 7Y250P0)
キャッシュフォルダのドライブ番号:1(キャッシュのみに使用)
ダウンフォルダのドライブ番号:0
デフラグしてからの測定かどうか: デフラグしない
HDDのアクセス音・アクセスランプの点滅の感じの比較:何よりもVerifyやってるときがHDDに悪そう
その他　errorlog:無し,ファイル破損:0,Moniter:on,CacheKeep:2,DiskFreeSpaceMargin:2048,キャッシュ対象:拡張子無しのみ
ファイルアクセスの累計
Readキャッシュ： ヒット 81,906 回、ミス 4,036 回、ヒット率= 95.30 %
Writeキャッシュ： 遅延 18,078 回、フラッシュ 4,995 回、遅延率= 78.35 %
ReadFile呼び出し回数： アプリから 86,151 回、OSへ 4,300 回、Ratio= 4.99 %
ReadFileバイト数： アプリから 2,603,084,171 バイト、OSへ 18,764,722,549 バイト、Ratio= 720.86 %
WriteFile呼び出し回数： アプリから 18,291 回、OSへ 5,091 回、Ratio= 27.83 %
WriteFileバイト数： アプリから 885,330,638 バイト、OSへ 859,335,647 バイト、Ratio= 97.06 %
　　　　　　　ny起動前温度　　　　 メモリ使用量　　　　　　 　使用後温度 メモリ使用量
　　　　　　　 　　D0 D1　 　　ny起動前　ハッシュチェック後 　 　D0 D1
tool不使用　　　46 46　　　　　342　　　　　　432　　　　　　　　 47 47　　　　　590
tool使用　 　　　49 50　　 　　　345　　　　　　473　　　　　　　　 46 47　　　　　630
　　　　　　　　　　tool不使用　　　　tool使用
総送信量　　　 　2.23 GB　　　2.75 GB
総受信量　　　 638.78 MB　　　1022.5 MB
平均送信速度 665.9 KB/s　　660.8 KB/s
平均受信速度 186.3 KB/s　　340.1 KB/s

Headactiveの記録
tool不使用
�@計測開始から0日00時間57分41秒 (3,461秒)
ドライブ0
�A総転送量 992,109 セクタ(507,959,808 バイト)
�B総ヘッド移動量 199,495,064,600 セクタ
�C総応答時間 342,860,226,464 nsec
�D総IOP数 18,956 個
ドライブ1
�A総転送量 5,212,051 セクタ(2,668,570,112 バイト)
�B総ヘッド移動量 2,335,962,728,809 セクタ
�C総応答時間 500,548,024,354 nsec
�D総IOP数 57,714 個
�E連続した領域へのアクセス 27,299 回
tool使用
�@計測開始から0日01時間12分24秒 (4,344秒)
ドライブ0
�A総転送量 1,114,582 セクタ(570,665,984 バイト)
�B総ヘッド移動量 137,351,922,051 セクタ
�C総応答時間 168,123,476,242 nsec
�D総IOP数 18,934 個
�E連続した領域へのアクセス 13,448 回
ドライブ1
�A総転送量 9,593,460 セクタ(4,911,851,520 バイト)
�B総ヘッド移動量 1,372,369,443,933 セクタ
�C総応答時間 534,145,295,250 nsec
�D総IOP数 82,761 個
�E連続した領域へのアクセス 20,590 回

dll足りないから起動できないって出る。 なんで？

>>175
中身の動作を理解していないと、難しいかもしれないです。
>>183さんの例をもとに、後程解説します。

>>183-184
報告ありがとうございます。

>>185
それだけでは、わかりません。
表示されるエラーメッセージを正確に書き写してください。
また、>>8の報告テンプレにも記入をお願いします。

>>183さんの例をもとに解説します。

> Readキャッシュ： ヒット 81,906 回、ミス 4,036 回、ヒット率= 95.30 %

ヒット = すでに先読みしてあったので、OSへリクエストを出さずに、アプリにデータを渡すことができた。
ミス = 先読みしてなかったので、OSへリクエストを出して、アプリにデータを渡した。

ヒット率 = ヒット回数 / (ヒット回数 + ミス回数)
パーセンテージが大きいほうが良いです。

HDDは、なるべく連続した領域を連続して読むほうが、
速度が速いですし、寿命も長くなるのではないかと思います。

ヒット率が高いということは、
このツールによって、HDDアクセスが連続したものに加工できている、ということです。


> Writeキャッシュ： 遅延 18,078 回、フラッシュ 4,995 回、遅延率= 78.35 %

遅延 = アプリから渡されたデータをバッファに溜め込んで、OSへリクエストを出さなかった。
フラッシュ = バッファに溜め込んでいたものを、OSへリクエストを出して、ファイルに書きこんだ。

遅延率 = 遅延回数 / (遅延回数 + フラッシュ回数)
パーセンテージが大きいほうが良いです。

HDDは、なるべく連続した領域を連続して書いたほうが、
速度が速いですし、断片化しにくくなるし、寿命も長くなるのではないかと思います。

> ReadFile呼び出し回数： アプリから 86,151 回、OSへ 4,300 回、Ratio= 4.99 %

"ReadFile"というのは、WindowsのAPIの関数名で、
アプリがOSに、ファイルから読むことをリクエストするのに使います。

この例では、
アプリがReadFileを 86,151回 呼び出したが、
このツールがそれをOSの代わりに受け取り、
このツールはOSに対してReadFileを 4,300回 呼び出した
ということです。

Ratio(率) = OSへの呼び出し回数 / アプリからの呼び出し回数
OSのキャッシュをバイパスしない場合には、パーセンテージが小さいほうが良いです。
概ね、
100% - Readキャッシュのヒット率 = このRatio
という関係になるはずです。

OSのキャッシュをバイパスする場合には、この値は評価が難しいです。
現状のOSのキャッシュをバイパスする処理が、その仕組みの都合上、
リクエストを分割するので、場合によっては100%を越えることもあります。

> ReadFileバイト数： アプリから 2,603,084,171 バイト、OSへ 18,764,722,549 バイト、Ratio= 720.86 %

この例では、
アプリがReadFileを呼び出すことで、約2.6Gバイトを読み出したが、
このツールがそれをOSの代わりに受け取り、
このツールはOSに対してReadFileを呼び出すことで、約18.8GBを読み出した
ということです。

現状では設定されたバッファのサイズいっぱいまで先読みをします。
たとえば、アプリから1バイトの読み込みのリクエストが来たら、
その1バイトだけでなく、その先の約10Mバイトをついでに読みこんでしまいます。
アプリが、後で、先読みした部分を読み込もうとした場合には、
Readキャッシュヒットとなり、HDDへのアクセスを省くことができますが、
アプリが先読みした部分を読み込まない場合には、まるで無駄になってしまいます。

Ratio(率) = このツールが読みこんだバイト数 / アプリが読みこんだバイト数
この値が大きいほど、先読みが無駄になっていることを示しています。
つまり、この値は小さいほうが良いです。

かといって、このパーセントが小さくなる(先読みが無駄になる量が少なくなる)ように、
先読み量を減らしてしまうことは、Readキャッシュのヒット率をも下げることになります。

> WriteFile呼び出し回数： アプリから 18,291 回、OSへ 5,091 回、Ratio= 27.83 %
> WriteFileバイト数： アプリから 885,330,638 バイト、OSへ 859,335,647 バイト、Ratio= 97.06 %

"WriteFile"というのは、WindowsのAPIの関数名で、
アプリがOSに、ファイルに書き込むことをリクエストするのに使います。

ReadFileと似た説明は省きます。

WriteFileの場合は、先読みではなく、遅延です。
連続した領域へのアクセスなのに、時間をおいてバラバラにリクエストが来ると、
その間に他のアクセスが割り込んでしまい、HDDのヘッドが動いてしまうので、
リクエストが来てもすぐには書き込まず(遅延)、バッファが一杯になるか、
ファイルの離れた場所への書き込みがくるか、そのどちらかになるまで、
バッファに溜め込み続け、なるべく1まとめでHDDに書き込むようにします。

このWriteFileバイト数のRatioは、100%前後になるはずです。
100%を若干切るのは、アプリがファイルの同じ場所に上書きしているからです。
バッファに溜めていて、まだ実際にはHDDに書き込んでいない部分に、
アプリが上書きしようとした場合、バッファ上で上書きを処理するので、
上書きされたデータは、OSには渡されません。

呼び出し回数、バイト数ともに、OSのキャッシュをバイパスする設定の場合には、
ReadFileと同様、そのしくみの都合上、かなり違った数字になります。

さらに、考察します。

> Readキャッシュ： ヒット 81,906 回、ミス 4,036 回、ヒット率= 95.30 %
> Writeキャッシュ： 遅延 18,078 回、フラッシュ 4,995 回、遅延率= 78.35 %
> ReadFile呼び出し回数： アプリから 86,151 回、OSへ 4,300 回、Ratio= 4.99 %
> ReadFileバイト数： アプリから 2,603,084,171 バイト、OSへ 18,764,722,549 バイト、Ratio= 720.86 %
> WriteFile呼び出し回数： アプリから 18,291 回、OSへ 5,091 回、Ratio= 27.83 %
> WriteFileバイト数： アプリから 885,330,638 バイト、OSへ 859,335,647 バイト、Ratio= 97.06 %

比較しているわけではないので、私の直感的な評価ですが、
Readキャッシュは十分にヒットしているが、先読みの無駄がちょっと多く、
Writeキャッシュはヒットしているものの、ちょっとヒット率が低い。

> 総送信量　2.75 GB
> 総受信量　1022.5 MB
> �A総転送量 1,114,582 セクタ(570,665,984 バイト) ← ダウンフォルダのあるドライブ
> �A総転送量 9,593,460 セクタ(4,911,851,520 バイト) ← キャッシュフォルダのあるドライブ

このツールがOSに、約18.8GBの読み込み + 約0.9GBの書き込み = 約19.7GBのアクセスをしているが、
OSがディスクに行ったアクセスは、2台合せて約5.5GBと、約19.7GBよりも少なく抑えられていて、
OSのキャッシュが良い仕事をしている、ということがわかる。

なるほど。解説thx

ならば、OSのキャッシュがあるのだから、このツールは不要じゃないかというと、そうでもない。

ツール無し
> �A総転送量 5,212,051 セクタ(2,668,570,112 バイト)
> �B総ヘッド移動量 2,335,962,728,809 セクタ

ツール有り
> �A総転送量 9,593,460 セクタ(4,911,851,520 バイト)
> �B総ヘッド移動量 1,372,369,443,933 セクタ

これを見ると、転送量は増えているけれども、ヘッドの移動量は減っている。

※ツール無しと有りで、別の時間に別の処理をアプリがしているのだから、
同じことをしたときに、ツールの有無でどういう違いがあるのか、
というデータではないので、そのまま直接比較することはできない。

今回のケースでは、
> 　　　　　　　　　　tool不使用　　　　tool使用
> 総送信量　　　 　2.23 GB　　　2.75 GB
> 総受信量　　　 638.78 MB　　　1022.5 MB
ということなので、さほどアプリのファイルアクセスに違いがあったわけではないので、
大まかな傾向としては、このツールを使ったほうがヘッドの移動量が減る傾向がある、
といっていいと思う。

こういったデータがあってはじめて、
バッファリングのやり方のどこを改善すべきなのか見えてきます。

様々な方の環境での稼働データがあれば、
何が共通していて、何が共通しないことなのか、
ということが見えてきます。

他の方も、データのupをお願いします。

情報集めて何をやらかすつもりなのか
negiでも使って接続先見たほうがよさそう

まったくだ
このツールは危険です！！

作者殿はお元気で何よりです。朝晩気温の差が広がり夜はめっきり寒くなりました。私は、掛け布団が分厚くなりました。

鉄は、熱くなると膨張し、冷えると収縮する性質があります。
レスの状況に合わせた柔軟な発言に、作者の知的さを感じています。

それはともかく、データーが欲しいとおっしゃいましたが、
それに見合う見返りなぞございましたら、教えていただければと、思います。

Winnyを使うと、断片化される→ヘッドが休みなく動く→HDDの寿命が縮むというロジックですが。特殊な物ではないと、考えます。windowsをやる以上さけられない現象が目立っているだけであり、断片化はHDDも想定内であると思います。

あるHDDの発売元のデータに
起動/停止回数（最低） 50,000回以上
コンポーネント設計寿命（最低） 5年
年間不良率（ARR） 1%未満

とあり、WinnyがWindowsの想定範囲内の動作であり、WindowsがHDDの想定内の動作をする以上は、問題ではありません。
もし、壊れやすいのであれば、M＄やHDDを製造している会社が、データを集め解決・改善・改良すべきだと考えます。
HDDの内部キャッシュやOSのブラックボックスなど不確定要素が大きい以上、個人ではどうしようもないのが現状です。

私は、WinnyからHDDを守ると言われても、これらの考えから遠巻きに、見物さしてもらいます。

※少し斜めのレス

遠巻きなヤツは長文レスしない。

作者さん、わかりやすい解説乙です！

HDD制御＆監視ツール使うとHDDが壊れる俺様が来ましたよ。

>>171
>自分の責任ではないと気にしないか
ひどいなこれ。

ひどいというのなら、どうすればいいのか書いてやれよ。

ひどいなこれ、としか言わないお前も、ひどいぞ。

>>201
ひどいなこれ。

作者が後悔として
＞対策機能を付けることができても、あえてそれをせず、被害が出たとしても、自分の責任ではないと気にしないか
と考えるってことはつまり、他人が作ったソフトの穴を見つけたから
対処しないと見つけた人間の責任と考えて今回の機能を追加したということだよな。
いくらなんでも思い込みが激しすぎる。

映画で言うと「普段大人しいのに拳銃を手にしてしまったがために不可抗力で人を殺し、
パニックを起こして事態を更に悪化させるタイプ」。
さっさと2chから撤退すれば内々に事態収拾できたろうに、いつまでも2chという
自分の手にあまる開けた場所で店広げてるからこういうことになる。

あんたがよく言えばﾄﾞｼﾞっ子属性、悪く言えば注意力散漫な思慮浅い人間なのはよくわかった。
よくわかったから頼むから自サイトに掲示板つけてそっちでやってくれ。
今回のことも含めてここでやるのは迷惑にしかならないし、自分がそういう人間だと自覚した上で
自分の手が届く範囲に事態を置くようにしてくれ。
そうすれば誰も文句は言わないだろうし、例えまた同じミスをしても早期に収拾することができる。

ホント頼むよ。

>>204
お前のほうが2chに向いてないと思う(＾ω＾；)

いや、釣りだから2chに向いてる
本気で>>204書いてたらキモイ

保守乙

このソフトの作者さんへ
いくらキャッシュに特化したソフトでも大元はこれではないでしょうか
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\＊＊＊＊
以下はご自分で。

version 0.20.6をupしました。

ファイルの先読みの効率向上のためのテスト版です。
検討・実験のためのものなので、よくわからない人はスルーしてください。
ちょっと時間がなくて、私のほうでは1度もテストしていないので、もしかしたら動かないかも。

変更点
・先読み量を設定(ReadAheadSize)で変更できるようにした。(デフォルトはバッファサイズめいっぱい)
・先読みが、OSのキャッシュにヒットしやくする機能(ReadAheadModulo)を追加した。(デフォルトOFF)

これらはGUIでは設定できません。
iniファイルに設定を書き足してください。

今回は、先読みが裏目に出すぎているというのを、どうやったら改善できるのか、
検討したり実験したりしたりするための、データ取りのための機能です。

先読みが裏目に出ている場合に、先読み量を減らすことで、どうなるか。
先読みが裏目に出ている場合に、ReadAheadModulo=1にすることで、どうなるか。
試して報告してください。

ReadAheadSizeの説明

ReadAheadSizeの設定がiniファイルにない場合、
従来通り、バッファのサイズいっぱいまで、先読みします。

ReadAheadSizeの設定がiniファイルにある場合、
設定したサイズを上限に、先読みします。

なお、ReadAheadSize=0に設定した場合、先読みを行わなくなるはずです。


先読みが激しく無駄になっている場合には、
この設定で先読み量を抑制することで、効率が良くなるかもしれません。

ReadAheadModuloの説明

ReadAheadModulo=0の場合、
ファイルのどこからどれだけ読もうとしているかに関係なく、一定量を先読みします。

たとえば、アプリケーションが、
ファイルの位置100MB目から1MB読み込み
ファイルの位置200MB目から1MB読み込み
ファイルの位置101MB目から1MB読み込み
ファイルの位置201MB目から1MB読み込み
ファイルの位置102MB目から1MB読み込み
ファイルの位置202MB目から1MB読み込み
というアクセスをしてきた場合、
ファイルの位置100MB目から1+9MB読み込み
ファイルの位置200MB目から1+9MB読み込み
ファイルの位置101MB目から1+9MB読み込み → OSのキャッシュは101MB目から9MB分がヒット。110MB目から1MB分がミス。
ファイルの位置201MB目から1+9MB読み込み → OSのキャッシュは201MB目から9MB分がヒット。210MB目から1MB分がミス。
ファイルの位置102MB目から1+9MB読み込み → OSのキャッシュは102MB目から9MB分がヒット。111MB目から1MB分がミス。
ファイルの位置202MB目から1+9MB読み込み → OSのキャッシュは202MB目から9MB分がヒット。211MB目から1MB分がミス。
ということになってしまい、OSのキャッシュがミスになるので、ディスクへのアクセスが発生してしまいます。

ReadAheadModulo=1の場合、先読み量を調整することで、
ファイルの位置100MB目から1+9MB読み込み
ファイルの位置200MB目から1+9MB読み込み
ファイルの位置101MB目から1+8MB読み込み → OSのキャッシュにヒット
ファイルの位置201MB目から1+8MB読み込み → OSのキャッシュにヒット
ファイルの位置102MB目から1+7MB読み込み → OSのキャッシュにヒット
ファイルの位置202MB目から1+7MB読み込み → OSのキャッシュにヒット
のようにすることで、OSのキャッシュにヒットするので、ディスクへのアクセスを抑制できると思われます。

>>197
このスレの主旨は、みんなでツールを作る、ということです。
テストをしてデータを取って報告することも、作る作業の一部です。

いっしょに作ろうという気がない人、ボランティアしたくない人には、
無理に一緒に作りましょう、とは呼びかけません。

>>208
話がさっぱり見えないので、
書けない理由がなければ、もっと詳しく書いてもらえませんか?

誤解している人が多いようなので、いちおう書いておきます。

私が一人で作ったツールのサポート等の、私とユーザとのやりとりの場のためであれば、
2chにスレを立てるのは激しく不適切であり、私のWebページでやりなさい、という話は尤もです。

しかし、そうではありません。
今のところ、テストプログラムを書いて公開しているのが、私一人なだけで、
本来目指しているところは、
・みんなでアイデアやテストプログラムを書いてみて
・みんなでテストプログラムを試して結果を報告しあう
ことで、スレタイのように、
WinnyをやってもHDDの壊れやすくならないようにするツールを、
2chのみんなの力で作り上げることです。

個人の掲示板ではなく、2chでやっているからには、
そういったことは暗黙の了解として理解されていると思っていたのですが・・・

普通ユーザーの情報交換は２ちゃんで
VerUpは自身Webサイトで
これが通常の流れではないですか？

>>214
通常の流れなんかあるのか？

>誤解している人が多いようなので
多いのは荒らしでしょ、相手しなくていいよ。
>2chのみんなの力で作り上げることです。
ﾀﾞｳｿの力は相当弱いけどねｗ

みんなで作ろうってスレだからWin板やソフト板に移動しようって話があがったんじゃなかったっけ？

◆aBeASKncAIですが、もう完全に頭にきました
このトリップも捨てました、というか頭に来てカッカしてしまって
ソース入ってるＨＤＤ消してしまい、同時にトリップも消えてしまいました。
まぁもう名無しに戻るので、トリ喪失も関係ないですがwww

とりあえずもうここには書きませんし、二度と見ません。
お前らの低レベルには完全に頭に来ましたから。

ここまで必死な荒しも珍しい
せめてトリップ解析できて成りすませるようになってから書けばいいのにｗ

よっぽど恨みか妬みでもあるんだろうな。

>>217
ﾀﾞｳｿにｶｴﾚと言われる悪寒

保守乙

>>212
あれ？このソフトはキャッシュ関係なのに
このレジキー以下を知らないのは関係無いってことかな
でもここをいじれば明らかにパフォーマンスは変わってくるけど。
ていうかこのソフトってまっさらなHDDを前提にしてないかな。
次から次へDLするんだから結局フラグメンテーションは発生するし
あとクラスタサイズも関係があるね
NTFSは4KBだけどFATは任意で変えられるし、一度デフラグソフトで終わるまでよーく眺めてみてはどうかな。
ついでに通信速度も関係してくるよ。
結局あいだに何かかませたらパフォーマンスはたいてい低下するんだよね。
自前のログとかじゃなくて一般のベンチマークテストのほうがはるかに信用できる。

レジとかややこしいとこはいじらずに少しでもヘッド移動を減らしてやろうって趣旨じゃ・・・

>>222
もうちょっとWindowsのことを勉強して出直したほうがいいぞ。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
の下にはWindowsの様々な設定が大量にあるので、
「このレジキー以下」なんて言ってもエスパーでもないと伝わらない。

レジストリチューニングで頻出の
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
\Session Manager\Memory Management\LargeSystemCache
のことを言いたいのだろうけど、そう単純な話ではないだろ。

それで解決するというのなら、データを取って示したほうがいい。
知ったかぶりの知識披露ではなく、説得力のある話をしようぜ。

ちなみに、NTFSのクラスタサイズは4KB固定ではないし、
大きくしたほうが断片化の確率が減ることは、既出。
しかし、NTFSは容量に余裕があれば、1クラスタ単位で
割り当てたりはしないので、クラスタサイズと断片化は、
必ずしも関係するわけではない。

答え言っちゃってどうするのよ
>>1の反応が楽しみだったのに。

このソフト使うとどの程度HDDの寿命が延びるの？

知ったかって笑えるね

>>226
今のところ全く未知。
HDDに書き込むデータを纏めて送ればヘッドが細かく動くことが減るだろうから
寿命が延びるんじゃないかな？という不確かだが理論ではなんとなく
効果がありそうに思えることが開発動機になっている。

各自のPC環境により因果関係がはっきりしないためスパシーボ効果な可能性は高い。

スパシーボ効果：
実在するフラシーボ効果（偽薬効果）から派生した2ch語。
効果も因果関係も再現性も全く不明だが自分は確かに実感したことがある効果のこと。

レスがついたね。
要は>>228の言うとおり。フラシーボ（スパシーボ？）効果程度だと思う。
>>224
よく分かったね。そこをいじればどうにでもなる。このソフトはほとんど関係無いんだよね
もし効果があるとしても言ったようにHDDがまっさらな状態で「書き込む」場合のみ
それも数個のファイルのみ。部分キャッシュが山のようになったら意味ないし。
なんのためにデフラグってツールがあるのか。
期待できるは効果は>>228程度。
WriteとReadとCopyの違いって分かるかな？
それにWinny自体の転送速度とデバイスよる転送能力ね
SATA・IDE・USB・IEEEそれぞれ違うし。管理してるのはOSだから
そのあいだに何かはさむのはそれだけでメモリーも食うしCPUの負荷にもなる。

>>229
プラシーボ（228は間違えた）効果とスパシーボ効果は似て否なるものだよ。
プラシーボ（プラセボ）効果はそんな効果が無いもので言った通りの薬効や体内変化が（客観的に見て）起こること。
スパシーボ効果はそれを実感した当人にしか証明ができないこと。要はマユツバ・ジンクス的なこと全般。

>>217
それらの板では、Winnyという固有名詞を出すと、それはそれで叩かれるような気がします。
どうなんでしょう。私にはどうしたらいいのか、よくわかりません。

>>226
本当に寿命が伸びるかどうか、わかっていません。

開発の発端は、自作PC板などで、
頻繁にデフラグしたりWinnyを使うとHDDが壊れて当然
というような書き込みをよく見かけたことです。

Winny使いは氏ね、という書き込みも散見されるので、
違う意味での書き込みかもしれないですけどね。

私がこのツールを使った範囲内では、
・1000KB/sec以上のスピードで複数のファイルをダウンロード
・キャッシュからファイルへの変換
において、HDDがガリガリいわなくなりました。
(※場合によっては、かえってガリガリいうこともあります。)

まぁ、効果無いと思うなら使わないでいいと思うよ
他者を否定して精神安定を計りたいなら知らんが

>>222
>>229
断片化に関する話は、すでに議論になっていますので、
まずは、過去ログを読んでください。

また、デフラグしていなくても効果があることは、
実際に試した方のデータが示しています。

> 結局あいだに何かかませたらパフォーマンスはたいてい低下するんだよね。
低下しない場合もあると思います。

たとえばOSやHDDの持つディスクキャッシュも、間に噛んでいるいるわけですが、
それらはパフォーマンスを劇的に改善してくれています。

> 自前のログとかじゃなくて一般のベンチマークテストのほうがはるかに信用できる。
信用できる一般のベンチマークテストがあるなら、ぜひ教えてください。おねがいします。
既にあることを知らなかったので、自前でStatHddActivityを作ってしまいましたよ、とほほ。

> このソフトはほとんど関係無いんだよね
関係ないことを、実験してデータで示してほしいです。

> そのあいだに何かはさむのはそれだけでメモリーも食うしCPUの負荷にもなる。
メモリやCPUを消費してでも、HDDアクセスでのヘッドの移動を減らしたほうがいいと思います。

> WriteとReadとCopyの違いって分かるかな？
何の話でしょうか。

HDBENCHの項目のことですか?
だとしたら、このツールは、
ReadやWriteのスコアに比べて圧倒的に小さな値になるCopyのスコアを、
ReadやWrite並みに高める働きをしますよ。

> それにWinny自体の転送速度とデバイスよる転送能力ね
> SATA・IDE・USB・IEEEそれぞれ違うし。
これも何の話なのかわかりません。

Winnyの転送速度とHDDの転送速度の話としては、
Winnyのファイルの読み書きよりも、
HDDのシーケンシャルな読み書き速度のほうが1桁以上速いので、
このツールは成立しています。

もし、HDDのシーケンシャルな読み書きが非常に低速(たとえばUSB1.1接続)な場合には、
このツールを使うと、パフォーマンスがかなり悪くなってしまうでしょう。

>>231で
かえってガリガリいう
について説明しておきます。

このツールを使わない場合、
Winnyのファイルアクセスは、とても短い間隔で少量ずつ行われます。

このツールを使った場合、
ファイルアクエスは、やや間隔をおいて、しかしアクセスするときには大量に連続して行います。

そのため2つのことにより、かえってガリガリいうようです。

1つ目は、断片化によるものです。
断片化していてヘッドが大きく動く場合、
少量ずつ間隔をあけて読むより、
間隔をあけずに、まとめて多量に読んだほうが、
時間あたりのシーク回数やヘッドの移動量が大きくなるのです。
音としては、前者が「チッチッチッチッ・・・・」とずっと音がし続けるのに対して、
後者は「ガガガガ、(しばらく無音)、ガガガガ、(しばらく無音)」となります。

総量は同じでも、長時間に分散したのと、短時間に集中したのとでは、
どちらがHDDのメカにとって負担が大きいのかは、私にはよくわかりません。

HDDの断片化がそれほど酷くなければ、あまり気にしなくていいと思います。

2つ目は、他のファイルアクセスと重なることによるものです。

Winnyがファイルを読み書きしている時に、ファイルのコピー等を行った場合、
このツールを使わない場合に比べ、このツールを使った場合のほうが、ガリガリいいます。

ファイルのコピーによるディスクアクセスをC
WinnyによるディスクアクセスをWで表わすと、

ツールを使わない場合は、
CCCCWCCCCCCCCWCCCCWCCCCCCCWCCCCCCCWCCCCCWCCCCCCWCCCCW

ツールを使った場合は、
CCCWCWCWCWCCCCCCCCCCCCCCCCCCCCWCWCWCWCCCCCCCCCCCCCCCC

といった具合になります。


これに関しては、
・他のプログラムが激しくHDDにアクセスしている間は、ファイルアクセスを一時停止させる
・ファイルアクセスする時は、他の激しくHDDにアクセスしているプログラムにpauseをかける
ということで、緩和できると思いますが、まだ作っていません。

◆aBeASKncAI はあくまでも早くなると主張したいわけね
晒しあげ。

まあ使って自分で検証すれば早いのでは？

＞総量は同じでも、長時間に分散したのと、短時間に集中したのとでは、
＞どちらがHDDのメカにとって負担が大きいのかは、私にはよくわかりません。

これでは実験する意味が無い気がする。
問題の前提がわからないのにやるの？

指摘しても「そんなことはない」と言い切るからなんともね
それと作者は検索をあまり知らないようだ
レジストリも知らなかったようだし。

レジストリ弄ってＨＤＤのヘッドの動きが少なくなるの？

作者人格攻撃はウザイが、技術ツッコミはいろんな意味で見てて面白いｗ

ﾊﾞｰｼﾞｮﾝ前
Readキャッシュ： ヒット 6,551 回、ミス 426 回、ヒット率= 93.89 %
Writeキャッシュ： 遅延 4,676 回、フラッシュ 207 回、遅延率= 95.76 %
ReadFile呼び出し回数： アプリから 6,997 回、OSへ 7,583 回、Ratio= 108.38 %
ReadFileバイト数： アプリから 228,767,731 バイト、OSへ 481,750,689 バイト、Ratio= 210.59 %
WriteFile呼び出し回数： アプリから 4,898 回、OSへ 4,817 回、Ratio= 98.35 %
WriteFileバイト数： アプリから 292,006,086 バイト、OSへ 292,462,313 バイト、Ratio= 100.16 %

ﾊﾞｰｼﾞｮﾝした(ReadAheadSizeは未設定&ReadAheadModulo=1)
Readキャッシュ： ヒット 5,001 回、ミス 370 回、ヒット率= 93.11 %
Writeキャッシュ： 遅延 4,947 回、フラッシュ 117 回、遅延率= 97.69 %
ReadFile呼び出し回数： アプリから 5,406 回、OSへ 3,129 回、Ratio= 57.88 %
ReadFileバイト数： アプリから 172,742,494 バイト、OSへ 195,036,352 バイト、Ratio= 112.91 %
WriteFile呼び出し回数： アプリから 5,168 回、OSへ 5,110 回、Ratio= 98.88 %
WriteFileバイト数： アプリから 318,405,626 バイト、OSへ 318,453,051 バイト、Ratio= 100.01 %


ReadFile呼び出し回数の減少率がUP(=改善)
ReadFileバイト数の増加率がDown(=改善)
おおむね良好、ということでおｋｋ？

ほらよhttp://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF%E3%83%86%E3%82%B9%E3%83%88%20%E3%83%8F%E3%83%BC%E3%83%89%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF&num=50

>>240
レジストリの話はただ単に208が意味不明だっただけじゃん。

>>208とか>>222とか>>229って莫迦だね

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

◆aBeASKncAI信奉者うぜえ。

◆aBeASKncAIアンチうぜえ。

こんなツール意味ねーよって言ってるやつは、
このスレに来なければいいのに・・・。
頭おかしいのかな？(ﾟдﾟ)

こんなツール意味ねーよって言ってるやつは、
スルーすればいいのに・・・。
頭おかしいのかな？(ﾟдﾟ)

こんなツール意味ねーよって言ってるやつは、
スルーすればいいのに・・・。
頭おかしいのかな？(ﾟдﾟ)

こんなツール意味ねーよって言ってるやつは、
スルーすればいいのに・・・。
頭おかしいのかな？(ﾟдﾟ)

保守乙

荒れるなあ・・・・

ちょっWinnyの技術まじおもしれー^^

スパシーボ効果、なぜか「ありがとう」と言いたくなる語感。
作者乙。

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

ReadAheadModuloについては、
StatHddActivityで、OSからHDDへのアクセス量も見てください。


どういうことかというと・・・

ReadAheadModuloは、先読み量を、単純平均で、だいたい半分にします。
簡単な算数で、(1+2+ ・・・+ (n-1) + n) / n の計算です。
しかしそれは、副作用であって、この機能の目的ではないです。

ディスクアクセスは
アプリ→このツール→OSのキャッシュ→HDD
という経路で行われます。

ReadAheadModuloが狙っているのは、
このツール→OSのキャッシュ
ではなく
OSのキャッシュ→HDD
のアクセスを減らすことです。

>>255
そうか？こんなもんだろ。

>>237
このツールは、ディスクアクセスを速くすることが目的ではないですよ。

>>239
わからないですが、
総量を激減させてしまえば、メカの負担が減るのではないか、
という根拠のない仮定に基づいてます。

>>244
Googleで「ベンチマークテスト ハードディスク」で検索してどうしろと。

失礼だけど、釣られてしまったような気がします。

HDDのヘッドの移動量を減らすことの副作用で、
HDDのヘッドの移動待ちがネックで遅いのが改善されたりもするかもしれないが、
それは狙いじゃないんですよ。

ああ言えばこう言う
誰かさんみたい。

その"ああ言えば"が、正論ならともかく、デタラメだからなぁ。

いいかげんスレを荒らすのはやめたらどう?
ここは、悪ふざけをする場所でも、人をからかって楽しむ場所でもない。

頭のおかしな人には気をつけましょう

利用者が増えるに従って、頭のおかしな人もそれなりに出没するようになって来ています。
頭のおかしな人に関わるとなにかと面倒なことが起こる可能性があるので、注意しましょう。

いつも保守係の俺が全く出番がない件について

どうもありがとう

>>1が隠れながら常駐してるな。
これだけ叩かれるのはプログラマとしての資質が
書き込みの内容からして疑問に思われてるからだろう。
だいたいプログラムの公開は自分のWeb上で
意見や不具合の報告は掲示板でというのが例えば２ちゃんブラウザとかでも一般的。
作りました>テストはしてません>不具合があっても知らないよ>あったら書き込め
って最悪の流れ。もしこのプログラムが真に役に立つのならもっと報告があってもよさそうなのに。荒らしや煽りが多いの答えはただ一つ。
「信頼されてない」以上。

>>265
OK.
ここは貴方の日記じゃないんだから、そういう事について
あれこれ言いたいなら、自分のサイトでやってくれ。

>>265
全部既出ですが何か？

>>265
　　　　　　r;ｧ'N;:::::::::::::,ｨ／　　　　　 >::::::::::ヽ
.　　　 　 〃　　ヽﾙ1'´　　　 　 　 ∠:::::::::::::::::i
　　 　 　 i′　　___,　-　,. = -一　 ￣ｌ:::::::::::::::ｌ
.　　　　　 ! , -＝=､´r'　　　　　　　 　 l::::::/,ﾆ.ヽ
　　　　　　ｌ　　　　　　　　_,, -‐''二ゝ　 ｌ::::l fﾞヽ |、 ここはお前の日記帳じゃねえんだ
　　　 　 　 ﾚー-- ､ヽヾﾆ-ｧ,ﾆ;＝、_　　 !:::l ） } ト
　　　　　　 ヾ¨'７"ry､｀ 　 ｰﾞ='ニ,,,｀　 　 }::ヽ(ノ 　チラシの裏にでも書いてろ
:ｰゝヽ､ 　 　 !´ "￣ 'l,;;;;,,,.、　　　　　　　,i:::::::ﾐ
::::::::::::::::ヽ.-‐ ﾄ、　r'_{　　 __)｀ニゝ、　 ,,iﾘ::::::::ﾐ 　　　
::::::::::::::::::::Vi／l:::V'´;ｯ`ﾆ´ｰ-ｯ-,､:::::`"::::::::::::::;ﾞ　, 　な！
:::::::::::::::::::::::::N. ﾞ､::::ヾ,.｀二ﾆ´∠,,.i::::::::::::::::::::/／／
:::::::::::::::::::::::::::::l　ヽ;:::::::::::::::::::::::::::::::::::::::::::／　／
::::::::::::::::::::::::::::::!　:|.＼;::::::::::::::::::::::::::::::／　／

◆aBeASKncAIですが、もう完全に頭にきました
このトリップも捨てました、というか頭に来てカッカしてしまって
ソース入ってるＨＤＤ消してしまい、同時にトリップも消えてしまいました。
まぁもう名無しに戻るので、トリ喪失も関係ないですがwww

とりあえずもうここには書きませんし、二度と見ません。
お前らの低レベルには完全に頭に来ましたから。

そのエネルギーを他のことに使えばいいのに…

>>264
乙

>>265がスレに常駐して荒らしてて雰囲気悪いからじゃね?

そういう口だけで何もしない人間はスレにいらないんだよ。

書き込みが40分の1程度になった　素晴らしい

保守

>>265
＞「信頼されてない」以上。
お前と比べりゃよほど信頼されてるだろｗｗｗｗｗ

もし265が真に正しい意見ならもっと肯定レスがあってもよさそうなのに。
否定や煽りが多いの答えはただ一つ
どう見ても精子です
本当にありがとうございました。

◆aBeASKncAI乙。

保守

急に誰もいなくなったな。

(´･ω･｀)

保守

>>265
少し言い過ぎた
保守するの面倒だから戻ってきてくれ

ミスリード厨も長持ちしなかったな
次の保守員探してこないとなぁ…

>>265
OK.
ここは貴方の日記じゃないけど、そういう事について
あれこれ言いたいなら、どんどん書きこんでくれ。

あ゛ーすっかり元に戻っているではないか
ほしゅほしゅ

話題が無いので関係しそうな話
http://pcweb.mycom.co.jp/news/2005/10/14/004.html

>たとえば今現在のヘッドの位置とシステムから要求され
>る最初のデータの格納位置が遠く離れていた場合、従来
>のコマンドでは順番通りにそのデータを読みに行ったの
>だが、NCQでは一連の要求のなかでより近い箇所に格納
>されているデータから順不同に先に読み出す。余計なディ
>スク回転を必要とせずに済むことでシーク速度が無駄にな
>らないほか、それによる耐久性能の向上も見込めるという。

何かよさげ

ソフトウェア的だけどこれ使って書き込みしてる時と
素で使ってるときのPCのパフォーマンスってどうなんだろ。
Ctrl+Shift+Escでスレッド数とか調べたらおもしろいかも。
>>286
結局ハードウェアってことかな。

ほしゅ

version 0.20.6で追加した先読みに関する機能について、実験しました。

結論からいうと、ワーストケースにおいては、

ReadAheadModulo=1にすることで、ヘッドの移動量が1/15〜1/50に減少
先読み10MBは無駄で、ReadAheadSize=2〜4程度で十分

ということを実験結果が示しました。

詳細は、
http://www.geocities.jp/ny2scan/ExtraFileCacheTestModuloBenchmark.html
を見てください。

★友好スレ
http://sakura02.bbspink.com/test/read.cgi/onatech/1120374247/

>>286
SCSIには、以前からコマンド・キューイング機能があるのだけど、
Winnyを素で使うと、けっこうドドドドドという音がするので、
過剰な期待はしないほうがいいと思います。
もちろん、役に立たないというわけではないと思いますが。


>>287
パフォーマンスは使ってみてのお楽しみ、ということで。
良くなることと、悪くなることがあります。

現状では、スレッド数は増えません。
アプリケーションのファイルアクセスのAPI呼び出しのコンテキストで処理を行ってます。

最終的には、1スレッド増えるようになるかもしれません。
どうしても、API呼び出しのコンテキスト内では、うまくできないことがありますので。

ちなみに。

今回ついでに、レジストリのLargeSystemCacheの違いもデータを取ったのだけど、
たしかにOSのキャッシュの挙動は変っていますが・・・劇的な変化はなかったです。

LargeSystemCacheを1にすれば、このツールが不要になるわけもなかったです。

乙かれちゃーん

乙っす！

OSのキャッシュをバイパスする機能を付けて以来、それを有効にして使ってきて、
今日、久しぶりに、無効にしてみて、びっくりしました。

PCのレスポンスが悪いんです。
何かする度に、HDDがガリッという。

WinnyがOSのディスクキャッシュを持っていってしまって、
他のアプリが使うファイルがキャッシュから追い出されている模様。

ということは、このツールのキャッシュを一人前の賢さにしないといけない、ということですね・・・。

それってHDDにかえって負荷を与えてない？
システムをいじくるとろくなことないよ。

OSのディスクキャッシュをWinnyが持っていってしまう話は、
このツールを使わない場合でも発生する問題です。

そして、それを解決するために、OSのキャッシュをバイパスする機能を付けたのですが。

ページングが多発してたいへんなことになる予感。
よっぽどメモリー積んでないと。

そもそもページングを行わないといけないほどメモリがギリギリなら
このツールを使う余裕があるのか疑問

無いね

期待ほしゅ　こんなツールを待っていた。

BitCometとかトレント系のはみんな実装してるよね

>>296
>>298
昨日書きませんでしたが、
かえってHDDに負荷を与えているかどうかは、
StatHddActivityでモニタリングしてチェックしてください。

ページングについてはWindowsのパフォーマンスモニタで監視できます。
StatHddActivityでのモニタと合せて、
メモリ量の違いによって、どのような違いが出るのか、レポートしてください。

実験してみないとわからないけど、

OSのキャッシュをバイパスするの、
FireFileCopyの効用と同じで、
ページングが減る可能性もあります。

残りメモリ100MBの場合と、
このツールが50MB使い、残りメモリが50MBの場合とで、
どちらがHDDアクセスが多くなるのかは、興味深いところです。

WinnyがそれなりにUP/DLしていると、
メモリを1GB積もうが2GB積もうが、
キャッシュの多くをWinnyに持っていかれてしまいますし。

>>302
それらを知らないので話が噛み合ってないかもしれないけど・・・

ファイルアクセスについて、最も情報を持っていて適切にコントロールできるのは、
アプリ自信とその作者だから、
できる限り自前でバッファリング & OSのキャッシュをバイパス すべきなんです。


「OSがキャッシュを持っているから、それに任せるのがいい」
これは正しくもあり、間違ってもいます。

OSのキャッシュにできることは限られています。
安全性とのトレードオフで、あまり大胆なことはできません。

アプリケーションからは、
・ニュートラル(これがデフォルト)
・ランダムアクセスするつもりだ
・シーケンシャルアクセスするつもりだ
といったヒントしかもらえません。

それに加え、
実際に行ったファイルアクセスの傾向から、
キャッシュを制御することができません。

ちなみに、WinnyはOSに対して、
・ランダムアクセスするつもりだ
・シーケンシャルアクセスするつもりだ
のいずれも指定していない(デフォルト)です。

これを変更すると、どうなるのか、後日実験してみます。

保守

◆aBeASKncAIですが、もうｒｙ

nyもこのツールもリソースはOSが割り当てるのだから
いくらがんばってもダメなような気がする、のは俺だけか。

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>309
実験してデータﾖﾛ

口先ばっかりの批評家は屑だね。

保守

>>306について実験してみました。

Winnyでやると再現性のない要素がたくさん入るので、
先日と同じく、Winnyのアクセスパターンを再現する方法で測定。
とりあえず、OSの振る舞いの違いを見たいので、このツールのキャッシュはOFF。

LargeSystemCache=0 ( 1の場合でも誤差程度の違いしかなかった。)

CreateFileでフラグ指定無し
�A総転送量 2,106,117 セクタ(1,078,331,904 バイト)
�B総ヘッド移動量 43,482,764,927 セクタ
�E連続した領域へのアクセス 16,565 回
�A÷�E=1連続アクセスあたりの転送量 127.14 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 2,624,978 セクタ

CreateFileでFILE_FLAG_SEQUENTIAL_SCANを指定
�A総転送量 2,127,413 セクタ(1,089,235,456 バイト)
�B総ヘッド移動量 30,436,687,107 セクタ
�E連続した領域へのアクセス 11,839 回
�A÷�E=1連続アクセスあたりの転送量 179.70 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 2,570,883 セクタ

CreateFileでFILE_FLAG_RANDOM_ACCESSを指定
�A総転送量 2,103,621 セクタ(1,077,053,952 バイト)
�B総ヘッド移動量 43,543,527,167 セクタ
�E連続した領域へのアクセス 16,580 回
�A÷�E=1連続アクセスあたりの転送量 126.88 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 2,626,268 セクタ

FILE_FLAG_SEQUENTIAL_SCANを指定すると、OSの先読み量が増えるようですね。

ちょっと待った！
HDDの記憶域（内周・外周）でヘッダの動きは変わってくるんじゃないのか。

どこかに書いた気がするのですが、
StatHddActivityは、その要素を無視しています。

HDDはZBRが導入されて以来、
ゾーンによって1トラックあたりのセクタ数が違うので、
当然、ヘッドの移動量も違ってきます。

しかし、ファイルの分布があまり偏っていなければ、
これは、考慮しなくてもいいと思います。

なお、
>>289と>>313のデータは、
ZBRだけでなく、ファイルシステムのファイルの配置の影響も排除してあります。

具体的には簡単なことで、
テストで読み込みに使うファイルの、ディスク上での位置を変えない
つまり、
同じファイルに対してテストを行う
ということです。

>>315
ダウト!!
＞しかし、ファイルの分布があまり偏っていなければ、これは、考慮しなくてもいいと思います。
ファイル分布がかなり分散するnyキャッシュ用ツールなのにそれを考慮しないとはこれいかに。
つかそこがどうにもならないってわかっているなら転送データをまとめようが細かくしようが
両者は微々たる差ってことになるんだが。

ツールはさむ分他所で遅くなる可能性のほうが高いってのはさんざん言われてるけどさ。
なんか作者の言ってることってまっさらなキャッシュ専用HDD以外には効果無し
って言ってるようにしか聞こえないんだよな。

HDDが逝く１週間前に教えてくれるソフトのほうがありがたいな。

>>317の意見に賛同。
プラス
ディスクキャッシュを無効にする等OSのパフォーマンスに関わる部分に手を加えたら
キャッシュファイルが外付けのHDDであれパフォーマンスに影響が出るのは必死。
作者はフックの横取りとか（常駐メモリープログラム）は詳しいようだけどレジストリには疎いようだ。
もっとOSのファイル関係のレジストリを勉強しよう。

それ本気で言ってるの？
ただの保守？

ついでに言うと
よくあるシェアウェアでOSの起動を早くするとか、インターネットの接続速度を早くするソフトは、ほとんどレジストリの値を変えるプログラムだ。
単に常駐プログラムに手を加えたりするのはOSの基本に手を加えているどころか
OSのパフォーマンス性に逆らっているのでは？
あるプログラムのためにだけに特化したOSなんて無いし、それを作るのは限りなく不可能。
このツールが最高に発揮できる環境は
最高のCPU、最高のメモリ、システム以外の常駐プログラムの停止、Windows不必要なのサービスの停止、そして何もファイルデータが記録されていない新品のHDD。
さらに言えば高い回転数、短いシークタイムを実現したHDD、しかも容量の少ないHDD。

>>320
保守とか余計な口挟むのならそのIDであなたの考えを述べてみてはどうかな。

◆aBeASKncAIですが、もう完全に頭にきました
このトリップも捨てました、というか頭に来てカッカしてしまって
ソース入ってるＨＤＤ消してしまい、同時にトリップも消えてしまいました。
まぁもう名無しに戻るので、トリ喪失も関係ないですがwww

とりあえずもうここには書きませんし、二度と見ません。
お前らの低レベルには完全に頭に来ましたから。

OSが管理するバッファのチューニング等による
パフォーマンス向上とディスクへの負荷軽減は
Winnyにおいてはあまり(全く)期待できない。
経験上からも「NYやるとHDの寿命が短い」と言われているが
それは物理的なHDDのアクセスについて全く考慮されていないNYの設計による所が大きい。
言い換えればブラックボックス化された仮想的で完全なストレージを期待した作りとも言えるが
OSはその期待に答える事はできない(なぜなら汎用OSとしての限界と物理的限界があるから)

＞あるプログラムのためにだけに特化したOSなんて無い
特化OSはあるし汎用OSの方が最近浸透し始めたぐらいなんだが
まあWindowsとWinnyについてはそうじゃないし
前述の通りNYは物理的なHDDについては全く感知してないから、
せめて負荷を軽減(またはパフォーマンスを向上)させるべく
汎用OSの汎用バッファリングルーチンをバイパスさせた上でOSとNYの間にもう一段レイヤーを儲けて
特定のアプリ(この場合NYだが)に特化したバッファリングを行う事により負荷やパフォーマンスのコントロールを試みよう
というのがこのツールの存在意義であり目標だろう(作者のレスなどを見る限り。)

また、「個々の環境によってパラメータをチューニングする事で最大のパフォーマンスに近づけよう」
といったものとは別のアプローチであるため
「OSの起動を早くするソフト」や「ネットの速度を早くするソフト」等の例は的外れだと言える。
それに、何を以って「最高に発揮された」と言えるのかが未定義な状態で
このツールが最高に発揮できる環境などと論ずるのは無意味だ

個人的には、どんな微かな差であっても負荷が減るのならば確かに意味のある試みだと思う。
勿論、価値がないと判断した人に無理やり使わせる強制力など作者にすらあろうはずもないし
単なる興味でこのソフトを見守ってる自分としては
どうでもいいレスに自分の考えを述べても何の得にもならないのはわかってるので
せめて、作者がそんなレスを読んで世を儚む事のないようにとの思いで保守乙とフォローを入れ続けていた次第です

保守。

あごめんID変わってるけど気にすんな

アゴMEN

>>321

> このツールが最高に発揮できる環境は
> 最高のCPU、最高のメモリ、システム以外の常駐プログラムの停止、Windows不必要なのサービスの停止、そして何もファイルデータが記録されていない新品のHDD。
> さらに言えば高い回転数、短いシークタイムを実現したHDD、しかも容量の少ないHDD。

この条件なら容量の少ないHDD以外はどんなプログラムも「最高に」発揮されるんじゃない？
「最高の」って意味が分からんが

Bitcometでいう下の役割をこのツールはwinnyでやろうって事ですよね？

読み込み要求数:221 回(頻度: 3.8 回/s)
読み込み実行数:43 回(頻度: 0.7 回/s),ヒット率:80.5%

書き込み要求数:699 回(頻度: 12.2 回/s)
書き込み実行数:73 回(頻度: 1.2 回/s),ヒット率:89.5%

>>318

でも真似たらアウトですね。

ちょっと保守りますよ

またレジストリ厨がきた

保守がてら戯れてみる

レジストリ弄るのは否定せんがよ
非ny専用PCでレジストリ弄ってnyに特化するのって

【消毒薬だけ】 が不足してる家庭に
「これさえあればどんな時も対応できますよ！」
と置き薬1セットを消毒薬が切れただけで持ってくる

ように見えるな、ny専用なら弄るの否定せんよ？ どう弄るつもりか知らんがなｗ

ていうかこれってレジはいじってないんでしょ。

レジストリ云々はよくわからん。
俺が言いたいことはデフラグ調査すれば判るが
nyする限りキャッシュファイルの断片化はどうあっても防げず
これを防げない限り転送データが大きかろうが小さかろうが
結局は空いているところに書き込みに行くので差は無い。
つーことね。

作者の弁を借りて（>>236）言うなら送るデータ形状が
「CCCWCWCWCWCCCCCCCCCCCCCCCCCCCCWCWCWCWCCCCCCCCCCCCCCCC」
であっても、HDDの空き領域が（極端な例だが）
「空有空有空有空有空有空有空有空有空有空有空有空有空有」
であれば結局アームの動きは抑制できない。
（nyは複数のキャッシュを同時ダウンするので実際はもっとばらつきのある空きが点在することになる）

詰まるところ前述の通りまっさらなHDDでのみこのツールは作者が意図する効果を発揮する。
一度でもキャッシュを消して断片化した空き領域を持つHDDには無意味。
つまりこのツールはHDDを一度でも書き消しを行えば効果が無くなる。

例えば部分キャッシュを複数持っていて
今日はここまで、続きはまた次回なんてときはどうなるんだろう
途中で中断するたびにデフラグするとか
それでもあんまり意味はないかもしれないし。あと多重DLの場合はどうなるんだろ。

>>336
デフラグにかかる時間が長大になるし、デフラグそのものも読み書きなので
このツールの本質的目的である「HDDの寿命を延ばす」からすれば本末転倒。

何かフラグメントをメインに考えてる人多いけど、このツールって
『複数同時に来るキューに対してｳｵｰｻｵｰするヘッドを
　メモリを間に挟む事でフラグメント以外のｳｵｰｻｵｰを減らす』
のが主目的じゃなかったん？

フラグメントとか、Windowsのファイルシステム上
・全て1発完走
・DLは1発ずつ
じゃないとまず防ぎようがないと思ったんだが．．．

すまん、気がついてテンプレ読み直したんだが
作者たんの書いてる事がフラグメント主体なのね．．．

>>317
>＞しかし、ファイルの分布があまり偏っていなければ、これは、考慮しなくてもいいと思います。
>ファイル分布がかなり分散するnyキャッシュ用ツールなのにそれを考慮しないとはこれいかに。

考慮しない場合と考慮した場合で、
ツールによる改善率に、
どれくらいの差が出るのか、
実験してデータを示してください。

私は、偏り→0、t→∞で、改善率の差は0に収束していくと思います。


また、違う角度から言うと、
HDDへのアクセスをどの程度改善できたのかを評価したいので、
あえてZBRの影響を無視したほうが、比較検討しやすいのです。

ZBRを考慮してしまうと、
まったく同じことをしても、
ディスクの先頭1/10で実験した場合と、
ディスクの末尾1/10で実験した場合では、
(HDDの機種にもよるけれども)大雑把に、
ヘッドの移動量に約2倍の違いが出てしまいます。

さらに言うと、
ディスクの先頭1/10で、ツールを使わなかった場合を試し、
ディスクの末尾1/10で、ツールを使った場合を試した場合、
ZBRを考慮してしまうと、
仮にこのツールがヘッド移動量を半分にしていた場合でも、
ヘッドの移動量は変らないという結果が出てしまいます。

>>317
> つかそこがどうにもならないってわかっているなら転送データをまとめようが細かくしようが
> 両者は微々たる差ってことになるんだが。

> ツールはさむ分他所で遅くなる可能性のほうが高いってのはさんざん言われてるけどさ。
> なんか作者の言ってることってまっさらなキャッシュ専用HDD以外には効果無し
> って言ってるようにしか聞こえないんだよな。

実験してデータを示してください。

>>319
> ディスクキャッシュを無効にする等OSのパフォーマンスに関わる部分に手を加えたら
> キャッシュファイルが外付けのHDDであれパフォーマンスに影響が出るのは必死。

日本語がよくわかりませんので、分かりやすく言葉を補って書いてもらえませんか?

> 作者はフックの横取りとか（常駐メモリープログラム）は詳しいようだけどレジストリには疎いようだ。
> もっとOSのファイル関係のレジストリを勉強しよう。

LargeSystemCacheの値を0と1で実験した結果、有意な差は見られませんでした。
他にチューニング項目があるというのなら、教えてください。
できれば、そちらで実験して結果も添えてくれると助かります。

>>321
これも、日本語がよくわかりません。


>>324
フォローありがとうございます。


>>328
すみません、Bitcometは名前しか聞いたことないんです。
でも、やっていることは、おそらく似たようなことだと思います。

>>330
仮に同じことをやっていたとしても問題ないと思います。
特別なことをやっているわけではなく、ごく当たり前のことをやっているのだから。


>>334
このツールはレジストリを変更していません。

だから自分でテストしてから表に出せよ
自分のPCのスペック晒して
そうじゃないと公平にデータ集められんだろ。

>>335
> nyする限りキャッシュファイルの断片化はどうあっても防げず
> これを防げない限り転送データが大きかろうが小さかろうが
> 結局は空いているところに書き込みに行くので差は無い。
> つーことね。

それは違います。

ファイルが断片化していても、
その断片の1つ1つが大きければ、
大した問題ではないです。

断片化していて、デフラグツールで赤く表示されていても、
200MBのファイルが2個の断片に断片化している
200MBのファイルが20個の断片に断片化している
200MBのファイルが200個の断片に断片化している
200MBのファイルが2000個の断片に断片化している
これらは、かなり違うものです。

このツールは、なるべく大きなサイズでまとめて書き込むことで、
断片が大きくなる確率を高めています。

>>335
> 作者の弁を借りて（>>236）言うなら送るデータ形状が
> 「CCCWCWCWCWCCCCCCCCCCCCCCCCCCCCWCWCWCWCCCCCCCCCCCCCCCC」

そのCとWはどういう意味ですか?

> であっても、HDDの空き領域が（極端な例だが）
> 「空有空有空有空有空有空有空有空有空有空有空有空有空有」
> であれば結局アームの動きは抑制できない。

話はそれほど単純ではないのです。

過去ログで出した、nyのキャッシュをファイルに変換した場合の例では、
「有有有有有有有有有有有有有有空空空空空空空空空空空空」
よりも
「空有空有空有空有空有空有空有空有空有空有空有空有空有」
のほうが、ヘッドの移動量が少ない、という結果がになりました。

キャッシュをディスクに書きこむ場合でも、
「空有空有空有空有空有空有空有空有空有空有空有空有空有」
に対して、先頭から順番に空き部分を埋めていくのと、
先頭と中央から交互に空き部分を埋めていくのとでは、
前者のほうがヘッドの移動量が少なくなります。

なので、空き領域が細切れになっていたとしても、
書き込みをバッファリングしてまとめて行ったほうが、
ヘッドの移動量が少なくなると考えられるのです。

実際にどうなのかは、今までに報告されたデータを見てください。

>>336
> 例えば部分キャッシュを複数持っていて
> 今日はここまで、続きはまた次回なんてときはどうなるんだろう

おそらく断片化します。
(断片化しない場合もありますが、話がややこしくなるので。)

こういう場合の断片化を避けるためには、
まだダウンロードしていない部分についても、
ファイルに書きこんで領域を確保してしまう
ことが考えられます。

しかし、
・部分キャッシュが多数あるとHDDの容量を食う。
・Winnyのキャッシュに特化した機能となってしまう。
・もし、Winnyのキャッシュ限定にしない場合、ファイルの末尾にダミーがつくと、
このツールを使わない場合、ダミーが見えてしまって具合が悪い。
などのデメリットが大きいので、今のところやろうとは思っていません。

> 途中で中断するたびにデフラグするとか

既存のデフラグツールは、断片化のない状態にしようとするので、オススメできません。
たとえば1GBのファイルが2つの断片に別れていた場合、これをデフラグするのは
あまり意味がないのですが、既存のデフラグツールは、これをデフラグしようとします。

> あと多重DLの場合はどうなるんだろ。

このツールの現在のバージョンでは、多重DLでは効果が半分になります。
キャッシュのデータ部分については、ツールを使わない場合と同じになります。
キャッシュのヘッダ部分については、書き込みが大幅に抑制されるはずです。
したがって、ヘッドの移動は半分くらいになると思います。
これについては、改善予定です。

>>338-339
フォローありがとうございます。

断片化の話をする人が多いので、その話が多くなっています。

このツールは、
第一に、ランダムアクセスをシーケンシャルアクセスに変える
第二に、断片化を生じにくくする(なるべく断片が大きくなるようにする)
です。

ちなみに、もし完全に断片化がなくても、
ランダムアクセスしたらヘッドが右往左往してしまいます。
そのため、Winnyを素で使う場合は、デフラグの効果は、あまり期待できなかったりします。

また、断片化があるからやっても仕方ないという意見は多いですが、
完璧や完全でなければダメというなら、それは正しいことですが、
よりヘッドの移動量が少なくなればよいなら、正しくはありません。

>>344
ここは表ではなく、テストルームですが、何か。


>>313について、WindowsXP SP2でも実験しました。
(Windows2000に対してXPはキャッシュ周りが違うらしいとうい話をどこかで見たので。)

結論からいうとXPでも2000の場合と同じ傾向になりました。
値については、10%未満の変化は誤差だと思ったほうがよいです。

■総ヘッド移動量
LargeSystemCacheは0 (括弧内はLargeSystemCacheは1)
CreateFileデフォルト設定 17,292,431,819 セクタ (17,271,802,909 セクタ)
CreateFileシーケンシャル設定 11,598,486,193 セクタ (11,217,359,717 セクタ)
CreateFileランダム設定 17,465,709,083 セクタ (17,620,576,363 セクタ)

■1連続アクセスあたりの転送量
LargeSystemCacheは0 (括弧内はLargeSystemCacheは1)
CreateFileデフォルト設定 129.26 セクタ (129.03 セクタ)
CreateFileシーケンシャル設定 192.53 セクタ (195.44 セクタ)
CreateFileランダム設定 129.19 セクタ (129.25 セクタ)

>>349
システムキャッシュの0・1の意味分かってんの？

◆LargeSystemCache
　SystemCacheを大きく確保する為のレジストリ

SystemCacheとは、アプリケーションなどが
使用していない物理メモリをファイルのキャッシュとして利用している領域。
その領域を大きく確保する為に、アイドル状態のアプリケーションなど
OSがページアウトしても良いと判断した使用メモリを
積極的にページアウトさせるか否かを変更するもの。

多量のファイルを扱う場合には有効だが、複数のアプリケーションを併用する場合
利用していないアプリケーションがすぐにページアウトされてしまう等の弊害が出る
ページファイルを無効にしている場合効果はない。

>>350
意味は
リソースキットやInside Windows 2000に書かれている通りで、
このテストでは、0と1で差が出るとは思っていないです。

それでもあえてやっているのは、差が出ないことを示すためです。
説明しても理解してもらえなくても、実際に試した結果を示せば、理解してくれるのではないかと。

ｹｺｰﾝ

おいおい、有効・無効じゃないだろ、この値は。
大丈夫か。

ID:FcRsH+rF0は釣りか? それとも真性の馬鹿か?

XPだとレジストリを直接いじる必要はない。
システムのプロパティの詳細設定のパフォーマンスの詳細設定のメモリ使用量で
次のパフォーマンスを優先するで、プログラムを選択すると0、システムキャッシュを選択すると1。

>>355
それカーネルに関する部分。
キャッシュとは別項目。勉強してね。

何で作者批判してる奴って自演してるん？

本当は保守しにきたんだけど
アンチっぽい言葉並べてみたりIDも毎回変えてみたりして
それを悟られないようにしてる
とってもシャイでいい子なんだよ

◆aBeASKncAIですが、もう完全に頭にきましたよ
このトリップも捨てました、というか頭に来てカッカしてしまって
ソース入ってるＨＤＤ消してしまい、同時にトリップも消えてしまいました。
まぁもう名無しに戻るので、トリ喪失も関係ないですがwww

とりあえずもうここには書きませんし、二度と見ません。
お前らの低レベルには完全に頭に来ましたから。

真昼間からご苦労さんです。

>>356
嘘やネタや荒らしでなければ、具体的に書いたらどうだ。

まぁ勉強すべきなのはそっちだな。
システムのプロパティを変更して、
何をどう変えるとレジストリがどう変るのか、
調べてから出直しておいで。

>>361
わるいわるい間違ってたわ。
そこアプリ関係ね。
でもそこはあまり関係無いんだなあ。
どっかこのスレにキー名が書いてあったけどあれもそんなに関係無いんだなあ。
それとシステムプロパティ部分じゃ設定できないこの手の項目は他にも
最低5箇所くらいあるし。
まあ勇気ある人は思い切ったことしてみるのもいいんじゃない？
OSが壊れても。データーが壊れてもそれこそ「自己責任」。ね。
何も記録されてないハードディスクにのみ有効なソフトだとは思うけど
それでも耐久率が変わるとは思えないな。

>362
後出しじゃんけんのような事ばかりだねぇｗ

さも「自分だけは知ってますよー、えらいんですよー｣な書き方しないといけないのは
このスレの住人相手に仮初めの論破がしたいだけなのかな？ｗ

このスレ(ツール)に貢献したいのであれば、ソースを含め有効な手段を提示すればいいし
荒らしたいだけならもっと低脳気味な文章にしないとダメじゃないか？ｗ

もっと頭使え保守要員君 ｄ(´∀`*)

後出しじゃんけんはここの>>1
レジストリキーについて一つも触れていなかったのに
>>208の書き込み以降で触れるようになってるね。
小出しにしてるつもりはないよ。
ただこういうツールを作る以上は（俺は思いも付かなかったので作者は偉いと思うが）
それくらいは知っていると思ったからね。

それに荒らしじゃないからね
保守してるつもりも無いし。
ただ指摘をしているだけ。荒らしに思えるならレス削除でも依頼したらいい。
削除屋さんの判断に任せるね。
ハードディスクの負荷軽減とシステム全体の負荷、どちらを採るか
両方おいしいことなんて無いよ。

>>365
悪あがきはよせ、みっともないぞ
おまえの完敗だ

なにが完敗なのかな？
知ってるレジストリキーの一つでも挙げて
システムにどう影響するか説明してみ。

そうかそうか、それは失礼。 荒らしと保守要員と言うのは訂正しよう。

> ただ指摘をしているだけ。
> ハードディスクの負荷軽減とシステム全体の負荷、どちらを採るか
> 両方おいしいことなんて無いよ。

これを好意的にくみとって
作者さんの意見も聞きたいので次の事を教えてくれまいか？
もちろん、知ってるなら最低5箇所提示できるはずだ。
まさか、知らないけど情報聞きだすため知ったかぶりしてるわけじゃないよねぇ？

> それとシステムプロパティ部分じゃ設定できないこの手の項目は他にも
> 最低5箇所くらいあるし。

LargeSystemCacheに関しては >352 で本人が述べているように
知っていたが有効では無いと認識していたと明言している
よって、>208無駄な検証をしなければいけなくなっただけに過ぎない。

すまん、ちょっとﾌｧﾋﾞｮってる部分がｗ

誤 : 作者さんの意見も聞きたいので次の事を教えてくれまいか？
正 : 作者さんの意見も聞きたいので次の5箇所の事を教えてくれまいか？

誤 : よって、>208無駄な検証をしなければいけなくなっただけに過ぎない。
正 : よって、>208の発言は無駄な検証をしなければいけなくなっただけに過ぎない。

なんで書かないかわかるかなあ。
作者さんが勉強してOSのシステム周りとこのツールによって引き出される結果が
どのようになるか検討してほしいだけなんだけどね。
なんかのCMじゃないけどいい性能のPCはより早く
それなりのPCはそれなりに
環境に応じて（このツールは記録されてないハードディスクのみ、かな）
変わってくる。場合によっては逆もありうると思う。

そういえばHITACHI製のハードディスクツールに
ドライブフィットネスみたいな名前のツールがあるけど
あれはどんな仕組みなんだろうね。もちろん特許・企業秘密なんだろうけど。

それなら逆に、
作者さんが例の5箇所を知っていて、あえて使っていない
とでも思って見てればいいのでは？

おまいさんは
「作者は知らないはず、漏れは知ってる、漏れ頭いい Foooooooooou!!」
っていう知ったか厨(or荒らしor保守要員)にしか住民からは見られて無いぞｗ

ま、脳内指摘でもしながら
(;´Д｀).｡oO(あぁん、なんであのキー触らないのかなぁ・・・)
って悶々としてろｗ

ハードもひとそれぞれ。
性能も人それぞれ。
一律に平均結果で負荷が下がるなんて統計学的に見ても数万サンプルが必要。
メーカーはそういうテストを膨大な試行を繰り返した上で販売している。
よって劇的な差異は無いと思う。
ましてソフトウェア側でそれを操作することはよほどの知識がないと
逆効果（全体のパフォーマンスの低下）になる。
これがWinnyだけでなく他のファイルの書き込みによる負荷の軽減が出来たなら
それはすばらしい事でしょう。

いろんなソフトに対応できるような設定だと、
nyに特化した最適化がされてないってことを
自分で言ってるようなものだな。

>>354
自分で説明するよりもソースを示したほうが良さそうですね。

Windows2000リソースキット
ttp://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/29933.asp

Windows2003リソースキット
ttp://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/29933.asp

＞ドライブフィットネスみたいな名前のツールがあるけど
＞あれはどんな仕組みなんだろうね。もちろん特許・企業秘密なんだろうけど。

うはｗｗｗｗテラバカｽｗｗｗｗｗｗｗｗｗ
真性だコレｗｗｗｗｗ

355〜374については、
他の方の書き込みで、話に決着が付いているようなので、私からはコメントありません。

＞ドライブフィットネスみたいな名前のツールがあるけど
＞あれはどんな仕組みなんだろうね。もちろん特許・企業秘密なんだろうけど。

晒し上げ

>>377
そのスルーっぷりに感動した。
まあいっちゃなんだがID:HeJ0mrjC0はどう見ても精子です。
本当にありがとうございました

結局このツールは効果があるの？ないの？それもわからずに開発してるの？
作者の言ってることは玉虫色すぎてさっぱりわからん。

異音がするんだけどﾔﾊﾞｲかな？
しかしどれがﾔﾊﾞｲんだか分からないｗ

>>380
効果の有無は、一概には言えないのです。
効果が有る場合もあるし、無い場合もあるし、逆効果の場合もあるので。

また、なるべく効果が出るように、なるべく逆効果になりにくいように、
少しずつ改善しているので、バージョンによっても違うこともあります。

※↑ここまでの話での効果はヘッドの移動を減らす、ということです。


ヘッドの移動を減らすことで、
本当にHDDの寿命が伸びる(縮まなくなる)のかどうかは、
わかっていません。

このツールの効果は、StatHddActivityによって、
ある程度の推定ができるので、それを使ってチェックしてみてください。


ちなみに、
まっさらなディスクや、デフラグした後の状態でないと、
まるで意味がないかというと、そんなことはないようです。

※そのような状態で使ったほうが効果が良く出るとは思いますが。


試しに、何ヶ月もデフラグしていなくて、
デフラグの画面で真っ赤になるようなディスクで、実験してみました。

テストプログラムは、Winnyがキャッシュからファイルに変換するのを模して、
約920MBのファイルを、64KBずつ読んでは、その都度、別のファイルに追記します。

その時の、StatHddActivityの結果と、
デフラグツール(Diskeeper Lite 7.0)のAnalyzeで、ファイルの断片の数をチェックします。

なお、読み込む元ファイルは、ほとんど断片化していません。
(Diskeeper Liteでは、あまり断片化していないファイルについては、断片の個数を表示してくれません。)

OSはWindowsXP SP2
HDDは80GBで、NTFS、クラスタサイズ4KB、空き容量は8%

※なるべく同じ条件になるように、書き込み先のファイルは都度削除しています。
※計測時間は、手動で更新ボタンを押しているので、数秒の誤差があります。
※StatHddActivityに、OSから情報が送られてくるのは、
　ある程度バッファリングされているため、後ろのほうのデータが欠落していることがあります。
　(転送量が少なく出ていることがあるのは、そのためです。)

■このツールを無効(DisableCache=1)
�@計測開始から0日00時間02分22秒 (142秒)
�A総転送量 3,602,455 セクタ(1,844,456,960 バイト)
�B総ヘッド移動量 949,076,918,909 セクタ
�B÷�A=1セクタあたりのヘッド移動量 263,452 セクタ
�A÷�E=1連続アクセスあたりの転送量 163.76 セクタ

断片化個数 : 880個


■(参考)Explorerでファイルをコピーした場合
�@計測開始から0日00時間02分05秒 (125秒)
�A総転送量 3,595,911 セクタ(1,841,106,432 バイト)
�B総ヘッド移動量 1,159,458,478,477 セクタ
�B÷�A=1セクタあたりのヘッド移動量 322,438 セクタ
�A÷�E=1連続アクセスあたりの転送量 141.61 セクタ

断片化個数 : デフラグツールが表示しないほど、少ない

■OSのキャッシュをバイパスしない(DisableOsBufferAndCache=0)
�@計測開始から0日00時間02分22秒 (142秒)
�A総転送量 3,590,071 セクタ(1,838,116,352 バイト)
�B総ヘッド移動量 880,685,673,615 セクタ
�B÷�A=1セクタあたりのヘッド移動量 245,311 セクタ
�A÷�E=1連続アクセスあたりの転送量 182.58 セクタ

断片化個数 : 89個


■OSのキャッシュをバイパスする(DisableOsBufferAndCache=1)
ただし、OSへのリクエストは64KB毎に分割(version 2.0.6と同じ)
�@計測開始から0日00時間01分18秒 (78秒)
�A総転送量 3,632,936 セクタ(1,860,063,232 バイト)
�B総ヘッド移動量 93,484,920,955 セクタ
�B÷�A=1セクタあたりのヘッド移動量 25,732 セクタ
�A÷�E=1連続アクセスあたりの転送量 1490.13 セクタ

断片化個数 : 879個


■OSのキャッシュをバイパスする(DisableOsBufferAndCache=1)
ただし、OSへのリクエストは10MB毎に分割(実験用の特別版)
�@計測開始から0日00時間01分06秒 (66秒)
�A総転送量 3,463,772 セクタ(1,773,451,264 バイト)
�B総ヘッド移動量 24,094,998,298 セクタ
�B÷�A=1セクタあたりのヘッド移動量 6,956 セクタ
�A÷�E=1連続アクセスあたりの転送量 6402.54 セクタ

断片化個数 : 88個

軽くまとめ・考察

■断片化について
OSへのリクエストを、なるべくまとめて行ったほうが、断片化しにくい

64KB単位でリクエストした場合、断片数=880前後(断片のサイズは平均1MB)になる。
・このツールを無効
・OSのキャッシュをバイパスする(64KB毎に分割)

10MB単位でリクエストした場合、断片数=88前後(断片のサイズは平均10MB)になる。
・OSのキャッシュをバイパスしない
・OSのキャッシュをバイパスする(10MB毎に分割)

※Explorerでファイルコピーした場合、
OSにはコピー先のファイルサイズがわかっているため、
断片化がほとんど発生しないのだと思われる。

■ヘッドの移動量について
OSのキャッシュをバイパスしたほうが、ヘッドの移動量が少ない

↑少ない
・OSのキャッシュをバイパスする(10MB毎に分割) = 約24Gセクタ
・OSのキャッシュをバイパスする(64KB毎に分割) = 約93Gセクタ
・OSのキャッシュをバイパスしない = 約880Gセクタ
・このツールを無効 = 約950Gセクタ
・Explorerでコピー = 約1,160Gセクタ
↓多い


■HDDのヘッドが動く音
体感なのであれですが、上記のヘッドの移動量と比例していました。
下3つはガリガリ。
上2つはチリチリ or ココココ でした。
とくに一番上の静かさは、かなりのものでした。

■速度
Explorerを除き、ヘッドの移動量と比例している。
※これは副作用であり、速度向上を狙ってはいません。

↑速い
・OSのキャッシュをバイパスする(10MB毎に分割) = 約66秒
・OSのキャッシュをバイパスする(64KB毎に分割) = 約78秒
・Explorerでコピー = 約125秒
・OSのキャッシュをバイパスしない = 約142秒
・このツールを無効 = 約142秒
↓遅い

OSのキャッシュをバイパスするかどうかで、ヘッドの移動量が大きく違ったのは、予想外でした。

OSのキャッシュを使った場合でも、10MB単位で書き込めば、
OSのキャッシュが書き込んだ内容を覚えておく & 少しライトバックするだけで、
HDDに対して、ほぼシーケンシャルにアクセスしてくれるものだと思っていました。
しかし実際には、キャッシュを経由するとあまりシーケンシャルではなくなるようです。

OSのキャッシュをバイパスする機能について、位置づけを変えないといけなさそうです。

保守

とりあえず、
OSのキャッシュをバイパスする場合に、64KB毎に分割してリクエストをするのを、やめるように改良中。
がしかし、うまく動かない・・・orz

乙

OSキャッシュのバイパスに関しては以前のバージョンで
キャッシュ破損の報告が多かった気がするんでその辺
の確認は念を入れてお願いします

応援保守

保守

期待保守

10Mリク版期待保守

ほっしゅほっしゅ

http://tmp5.2ch.net/download/
上記ルール違反。スレ削除依頼。

良スレを捨てるなんてもったいない!

ルールのどこに違反するの?
スレ削除依頼なんて出てないよ?

やだねぇ僻みは。

これから出すんでしょ
おそらくコテハンスレのことかと。

コテハンスレってのは
簡単に言うと女神系スレから女神が独立して
個人スレ立てたりするようなアレ。
一人一スレみたいになると際限なく個人用のスレが立つから
一部の板以外では大抵禁止されてる

別にコテスレじゃなくて、タイトル通りのスレだろ
今は一人しかできる＆やっている人が無いだけ
これから作者が増える可能性も十分あるしな

現バージョンのテスト期間が先程切れてしまったわけですが、
まだ次のバージョンをupできません。すみません。

現在デバッグ中です。
とても眠いときに書いた部分で2つバグを発見するも、まだうまく動かない。
だめですねー、眠いときにプログラムを書いては。泥縄になってしまう。

>>401
遅くまでお疲れ様。
期待して待ってるぜ！

さらにバグ2つ発見して、動くようになりました。

version 0.20.7をupしました。

変更点
・OSのキャッシュをバイパス(DisableOsBufferAndCache=1)する機能で、
　64KB毎に細かく分割してOSにリクエストするのを変更。
　デフォルトでは、なるべく分割しないようにした。
・モニタの表示のうち、いくつかを右揃えに変更した。
・アプリがファイルを閉じる処理をせずに終了しようとすると、
　例外で落ちることがあったバグに応急処置をした。


OSのキャッシュをバイパスする処理は、しばらく前のバージョンから、
ツールに組み込む前の状態で、テストプログラムにかけてチェックしているので、
以前のようなバグはないと思います、たぶん。
テストプログラムが全てをチェックしきれているわけではないので、
バグ無しを保証することはできないけど。

バッファサイズを64MB以上にしている人は、Readme.txtを見て、
63MB以下に分割してリクエストするように設定してください。


とりあえずWinnyで使ってみていますが、
1,000KB/secでダウンロードしていても、
キャッシュからファイルに変換していても、
HDDが静かです。

静かになるのは、
DisableOsBufferAndCache=1
にした場合です。

ただし、DisableOsBufferAndCache=1にすると、
OSのキャッシュが効かなくなるので、
同じファイルを複数の相手にアップロードする場合、
先読みが裏目に出てしまい、ガリガリいうと思います。

アップロード中心の人はDisableOsBufferAndCache=0
ダウンロード中心の人はDisableOsBufferAndCache=1
にすると良いと思います。

両方のバランスを取る方法については、検討中です。

※誤解している人はいないと思いますが、念のため。
DisableOsBufferAndCache=1にしても、その他のことについても、
このツールの上で動いているアプリだけが対象なのであって、
同じOS上で動いている他のアプリは対象にはなりません。

なるべく
CacheOnlyExplicitDirectory=1
にして、
WinnyのUp、Down、Cacheの各フォルダについて、
EnableCache=1
の設定をするようにしてください。

現状、アプリのAPI呼び出しを広範囲にフックしているので、
そのアプリのプロセス内に読み込まれている、
OSやシステムの一部を構成するDLLのファイルアクセスも、
そのアプリから呼び出すとキャッシュ処理対象になってしまいます。

やはり、System32ディレクトリ等のファイルまでキャッシュするのは、
ちょっと気持ち悪いので、それらを除外するために、
キャッシュ対象のディレクトリを明示的に指定したほうが無難です。

指定したディレクトリだけをキャッシュする設定だけでなく、
指定したディレクトリはキャッシュしない設定もあったほうがいいですね。

ということで、寝ます。

　　　（　　ｵﾔｼﾐ
　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／

キャッシュが破損するってあるけど何百MBのファイルが壊れたら
大きなバグがあったらHDDあぼーんだ
破損した不完全キャッシュ流したらかなり影響するんじゃないか。

>>406
お疲れ様

　　　　　　　　　　　　　　　　　　(ﾟдﾟ　)
　　　　　　　　 ＜⌒／ヽ-、_＿ノヽノ |
　　　　　　　／＜_/＿＿＿＿／ <　<
　　　　　　　￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　(ﾟдﾟ　)
　　　　　　　　 ＜⌒ヽ_ ／ヽ-、_＿ノヽノ |
　　　　　　　／＜___ノ/＿＿＿＿／ <　<
　　　　　　　￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　(ﾟдﾟ　)
　　　　　　　　 ＜⌒ヽ　　　　／ヽ-、_＿ノヽノ |
　　　　　　　／＜___ノ￣￣/＿＿＿＿／ <　<
　　　　　　　￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　　( ﾟдﾟ )
　　　　　　　　 ＜⌒ヽ　　　　／ヽ-、_＿ノヽノ |
　　　　　　　／＜___ノ￣￣/＿＿＿＿／ <　<
　　　　　　　￣￣￣￣￣￣￣

やっぱり作者の体感しかツール使用の改善報告はないのか。
他に同じようにHDDの音が減ったとか転送が早くなったとかないの？

このツールは高速回線であればあるほど有用だろうな

とは思うものの
高速回線であるがゆえに多重ダウンロードが発生しやすく
作者自身が多重に関して芳しく無い発言をしてるので手を出しにくい俺様

キャッシュが破損することがあるみたいだし
>>405読んだらなんかシステムまで壊れたら怖い。

nyユーザーはSafenyで P2Pネットワークの害に近しいPort0を忘れずに弾きましょう。
shareはPort0は繋がらない仕組みになっているので、なるべくShareのお使いをお勧め致します



SafeNyを使ってPort0危険IPうp0を排除するスレ30
http://tmp5.2ch.net/test/read.cgi/download/1129864206/

>>412
＞システムまで壊れたら怖い。
は？

>>414
まぁ理解出来ない人は使わない方がいいって事だよ
そうつらく当たるな

>>407
Winnyにはキャッシュが破損した場合に備えた仕組みがあるので、
キャッシュが破損しても、破損した箇所を他のノードが持っていれば、
それほどの影響はないと思います。

心配ならば、十分にテストした上で、本番運用に使ってください。


というかですね、
心配するのはわかるけど、ただ心配だと書いても、何も解決しません。
心配しているような問題が起きるかどうか検証して報告してください。

>>410
改善しないという報告もないんですよね・・・。

報告がないと、
改良したのがどれくらい効いたのか、効かなかったのか、逆効果だったのか、
わかりません。

脳内シミュレートと実際は違うので、実際に効果があるものを作るには、
実際に使ってみてどうだったか、というデータが必要です。


>>411
多重ダウンロードについては、もうしばらく待ってください。
いくつか対策案を考えてはいるのですが、実装できていません。


>>412
少しでも危険の可能性を避けるために、
キャッシュ処理するディレクトリを限定する機能を付けたのですが・・・。

404に補足です

> アップロード中心の人はDisableOsBufferAndCache=0
この場合、ReadAheadModulo=1も付けることを推奨します。

もひとつ補足

HDDの残り容量がとても少ない状態では、
連続した空き領域が存在する確率が低くなるため、
このツールを使って、大きなサイズでまとめて書き込んでも、
それなりに断片化すると思います。

>>417
支持するレスがある割に実質良し悪しがわかるレスが無いんだよな。
まさかとは思うが実は使っているのは極々一部で
アンチも擁護も殆どが様子見だったりするんだろうか。
開発から随分たって機能もいろいろ試行錯誤しているのに
報告数は初期から一向に増えないのはどういうんだろう。

そういう俺も様子見だけどね。
モノがHDDの寿命だけに半年単位で様子見ないとダメか。

効果の度合いを定量的に表す基準がないことには報告なんてできるわけがない。
主観でいいならいくらでもいえるがね。

テストツールって自前のツールみたいだし
IDが変わってないから常駐してるね。

何が言いたいのか意味不明

スレに粘着して荒らしてるアンチは常駐してるようだがなｗｗｗ

保守乙

>作者氏
多重の問題は基礎がきっちりできてからでいいっすよ、それまで待ってます

>>421
＞主観でいいならいくらでもいえるがね。
だからそれすら無いって話をしてるんだが。
まぁ作者のようにガリガリ言ってる寿命が近そうなHDDをnyに使ってる人物が
このツールに目をつけてくれる可能性はあまり高くはないがね。

とりあえず>>421の主観でいいから良しでも悪しでもいくらか語ってくれんか。
変化なしはもとよりスレの状況がそう語っているので無駄レスではあるが。

検証データ報告がほとんど無いのがネックだな。
ユーザーはほとんどいないのか。

>>427
多重できないと使い物にならんし
そりゃテスト用ってのはわかってるんだが・・・

多重ダウンロードだと効果がないというだけで使えないわけではあるまい。

いつものことだが、テストしない言い訳をする奴は理由を変えていつまでもテストしないな。
うだうだ言ってないで、自分なりに考えて試して報告してから不満を書いたほうが建設的だろう。
今までの流れを見ると、あれこれうるさく注文をつけたり要望を書くだけだと、ことごとく却下で、
テストして報告したうえで書いた要望は、そこそこ実現されてるよな。
クレクレ君は相手にしないという方針なんじゃないか?

じゃあおまえが報告しろよ。
+IreKCZh0で。

>>429
効果もはっきりせず良く動くか悪く動くかも判らないツールを入れて
試行錯誤するのが建設的とは思えない。

どんなツールを入れても復元可能なスキルや環境を作っておくというのは
効果的なクライシスマネジメント（危機管理）の一つであるが、
危機管理というならそんな怪しいソフトをまず入れないのが一番いい。

無論入れるも入れないもユーザーの自由であるからテストするもしないも
報告するもしないもユーザーの自由だ。
ツールを入れた上で起こった不具合が自由な選択による結果なら
入れたユーザーの自己責任であるのと同じにね。

>>431を一言でまとめると

このスレの主旨には賛同できない。

>>432
それは間違い。
俺だってnyの過剰なHDD食いつぶしを抑止してくれるツールが欲しい。
が、現在◆aBeASKncAがI開発しているツールに関しては疑問が多いというだけのことだ。

ならば二人目の開発者になって二つ目のツールを作るのが最も建設的だろう。

来ないね。
このツールは当初の目的から逸れてないか？
nyのキャッシュ書き込みによる負荷からHDDを守るから
ファイルキャッシュとかバイパスとかSystem32とか
裾を拡げすぎてないか？
まあいろんな突込みがあるからかもしれんが。

ならばどう軌道修正すべきなのか具体的に提案するのが建設的だろう。

>>435
お前らは使わないんじゃなくて使えないんだろ？
OSキャッシュのバイパスするかしないかは選択出来るし
キャッシュするファイルはフォルダと拡張子を指定する
事で限定すればいいこと
ファイルキャッシュって意味分かってる？それがHDDの
負荷を抑える具体的な方法

分からん奴は使わなくて良いよ

>>437
やけにけんか腰だな。
作者の言いたい事は出来るが実際はどうなのかってことでここに書き込んでるだろ。

>>438
あれ？
>このツールは当初の目的から逸れてないか？
この部分はもういいの？

次の話題にいく？

>>439
今朝の人じゃないよね。
MzDZyJ+S0で検証結果報告頼む。
使用者だから当然すぐ出せるよな、

・反論できないと違う話題に行く
・自分の要求が必ず通ると思い込んでいる
・相手の都合を考えない

>MzDZyJ+S0で検証結果報告頼む。
>使用者だから当然すぐ出せるよな、

使用したこと無いんじゃ検証に時間がかかるの
知らなくてもしょうがないか

で、君の無知については華麗にスルーですか？

あと追加

検証結果報告って作者が示した手順のものを指している？そうだとして
それを示されてもそれで実証って君は思っている？
されに私が出したところで捏造とか言われるのがオチな気がする

>>438
>作者の言いたい事は出来るが
>作者の言いたい事は理解出来るが、ね。
>>441
今までのログも取ってないのか。
>>70形式のログあるでしょう。
見事に逃亡。

すぐ出せると思ってるということは分かってないのだな。

自分の代わりに検証して結果を報告してほしいなら、もっとマシな頼み方をしろよ。
実際はどうなのか知りたいのはお前だろ。まずは人に頼まず自分で調べて知れよ。

444は>>440宛

>>442
自分で暴露。素直じゃないね>>70を見習え。

>>70の形式のログを取って、それをどうしろというのだ。

そんな文字の羅列見てもわかんねーからグラフ化しろよ
どう効果があるのか全然わかんねーよ
作者もそれくらいのことしろ

>>446
> >>442
> 自分で暴露。素直じゃないね>>70を見習え。

ゴメン。全く意味が分からない。

このツールに好意的なんだったらログくらい持ってると思っただけよ。
検証データが少なすぎる。
CPUは何Ghzでメモリーは何MB、HDDは何Gで、何MBのファイルを
何分DLしたとかのデータは全く無い。
「ああこれなら使ってみよう」と俺個人としては今の所思わないね。

>>448
何をどのようにグラフ化すべきなのか具体的に書くのが建設的だろう。
数字を見てもわからないなら、数字をグラフで描いてもわからないだろうな。

>>451
俺は素人だから何を話してるのかさっぱりわからんよ。
でもグラフ化したらちょっとはわかりやすくなるだろって話してるの。
グラフ化なんて解析の基本だろ。

>>39-41みたいなやつだろ。
これも分かりにくいといえばそうだが。

>>450
ログはデフォルトでは無効になっていて出力されないぞ。
有効にすると膨大な量が出力されるが、それを全部コピペしろというのか。
分かってなさすぎる。

>>452
さっぱりわからないならすっこんでろよ。
グラフにしたらわかりやすいというのなら自分でエクセルに数字を打ち込んでグラフ書けよ。

>>454
>>70なんか僅か数秒だ。
まあログ記録するだけでHDD、メモリ間で負荷がかかりそうだが。

>>453
ログの話だろ?

検証データが少なすぎると文句を言ってないで、お前が率先して検証してデータを提供しろよ。
自分は何もせずに他人には検証データを出せと言うのは、ずいぶん身勝手だな。

＞４５７
なんでお前はそんなに偉そうなの？作者？
テスターにテストして貰いたかったら、誰にでもわかるように丁寧に説明して下手にでろよ
だからテスターが集まらないんだろ

>>456
ログのどこを数秒分切り出せというのだ?それにどんな意味があるんだ?

ieyCK5az0さんへ
結果の出たソフトを使いたいだけなら変に意見とか
書かないほうが良いよ
Winny自体ユーザーが使いながら報告をして作者が
色々調整した結果が今のネットワークを作っている
わけだから

なんかあったら困るからね。それ以外理由は無い
悪いがVMとか入れてないんでね
大勢の人が使ってデータみてそれからだろう。
>>460
それじゃいつまでたってもユーザーは増えないぞ。
まあ好意的に受け取って検討はしてみる。

>>458
作者じゃねえ。お前らの他力本願な態度がムカついてるだけだ。
何もしないで文句を言うだけの奴は邪魔なだけだ。黙って指咥えてROMってろ。

>>461
全員が大勢の報告を待っていたらどうなるかはガキでもわかるだろ、馬鹿。

>>461
大勢の報告を見たいなら、お前の書き込みは逆効果だぞ。やっぱり馬鹿?

これ以上言ってもスレを無駄に消費するだけだから、俺は引くぜ。

それじゃあ身内で細々とやっていくしかないか。
どっかの町工場みたいだな。
魅力ある会社に見せようと思うならいいイメージをアピールするのが普通だろう。
それをするのは社長と従業員。口コミで広めるのは客だ。

>>463-465
報告が無い＝全員が様子見ならそのツールは大勢に取って不必要ってことだよ。
馬鹿でもわかることだ。

つかレス3つも使ってなんでこいつこんなに必死なんだ？
作者以外、報告の有る無しに必死になる理由がある奴なんていないと思うが。

よく見たら4レス連投か。
本当に必死なんだな。

仕方がない、これからは根拠も無く効果が
あったかのように書き込む
「サクラレス」
を書き込むしかないな

ieyCK5az0さんも一緒にどう？

>>466
お前が広報担当になればいいだろ。

>>467
作者よりもツールの完成を期待してる人のほうが熱心だろ。
過去ログみれ。
作者は報告がなければ開発やめるが痛くも痒くもないというような話をしてるぞ。

まぁ俺は馬鹿供を罵倒するために、このスレに来ているわけだが。

>>469
そういうレスが増えれば逆にそれを根拠あるものにしようとする動きも出るだろう。
細かい設定・PC環境を聞いて検証したりね。
スレというか作者の意向として一番望ましくないのは「何も気付かない（変化がない）から報告しない」
という状況だと思われ。

>>470
＞作者は報告がなければ開発やめるが痛くも痒くもないというような話をしてるぞ。
だとしたら熱心なのはお前だけということになるがｗ
馬鹿な奴ほど良く踊るのは>>465みたいな撤退宣言する厨房共通の特徴だな。

断っておくが俺を含めた様子見組はこのツールの完成を待ってはいても
得体の知れないツールに積極的に協力したいと思ってはいない。

どうしても完成してほしいのに動作報告をしないのならそいつは「馬鹿」だとは思うがね。

保守乙

荒らしもスレの賑わひ

いいですね。殺伐としてます。

■■■■■■■■■■■■■■■■
■　　　　　　　　　　　　　　　　　　　　 ■　　違う板にコピペすると、四角の枠の中に
■　　　　　　　　　　　　　　　　　　　　 ■　　メッセージとURLが現れる不思議な絵。
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　（その仕組みがリンク先に書いてある）
■　　　　　　　　　　　　　　　　　　　　 ■
■　　　　　　　　　　　　　　　　　　　　 ■　　この原理を応用すると、まったく新しい
■　　　　　　　　　　　　　　　　　　　　 ■　　コピペが作れる予感。
■■■■■■■■■■■■■■■■

( ´ー｀)y━･~~~　もう、しょうがないなぁ、お前らはぁ

たった半日見ないだけでこんなに新着レスが

みんな保守したくてしょうがないみたい

下手な議論保守は、完結しない限り作者さんが丁寧レスつけちゃうから
開発スピードに多少支障出そうなもんだけどなｗ

このスレは
「砂場で遊んでる幼稚園児を見守る大人」
な視点で見てくれた方がイイと思うんだが、性格上無理っぽいかのう

いくつかポイントだけコメントします。


検証を↓の2つに分けて考えてください。
・ヘッドの移動量の多さがHDDの寿命を短くしているという仮定
・WinnyとOSの間に入ってバッファリングすればヘッドの移動量が減るという仮定
この2つをごたまぜにして話をすると、わかりにくくなります。

前者については、HDDメーカーの資料や発言から、
おそらくそうであろうとは想像できますが、
我々が検証するのは、現実的に難しすぎると思います。

後者については、StatHddActivityによって、ある程度の傾向は掴めます。
他によりよいヘッドの移動量を評価する方法があれば、提案してください。

多重ダウンロードについては、解決方法はわかっているのですが、
バッファリング処理を作り直すことになるので、もう少し時間がかかります。

多重アップロードについては、
現状、OSのキャッシュをバイパスするのと背反になってしまうのだけど、
これを緩和する方法についてはアイデアがあり、近々実験してみます。


検証報告が少ないのは仕方ないと思います。
報告が無いときは自分で実験しているのですが、
何も考えずに漫然と数字を取っても、
実験データとしては、あまり役に立たないので、
それなりに手間がかかるのです。

いつも乙

hosy

保守がわりに、ちょっとした話を。

時間あたりのヘッド移動量は、Winnyよりも
ウィルス対策ソフトや、2chブラウザのほうが、
多かったりします。

具体的にはどれくらいなのかは、
各人、StatHddActivityで見てみてください。

いちおう念のため・・・

このツールを、ウィルス対策ソフトに使うのは、やめておいたほうがいいです。
2chブラウザについては、ほとんど効果が出ないと思われます。

OpenJaneで使ったことあるけど表示がおかしくなるだけだったわさ

ファイル情報公開ツールだって気付いてないな。

2chブラウザって・・・
どんだけ更新しまくってるんだよ

>>488
どこのスレへの誤爆ですか?

>>489
デフラグしない & お気に入りから削除しないで使い続けると、
鯖ﾏﾃﾞｵﾂｶｲの取得や、
OpenJaneの[お気に入り→[板として開く]
をしたときに、激しくディスクアクセスしますよ。

ファイル情報公開ツールだって気付いてないな。

>>491
足が付くリスク考えたらnyで直接配布するし
もっと手軽に使えるモノに仕込んだ方が効率
がいい

保守乙

>488 >491
(HDD内部の)ファイル情報(をWinnyに)公開ツールだって気付いてないな。

お前頭いいな

その書き方だと公開の後に(する)がたりねーだろと。
それに本当なら根拠出してみ。今の状態だと批判要望板のアホどもと大差ねーぞｗ

493だとちょっと誤解が生じるな

(ny用キャッシュ)ファイル情報(をWinnyに)公開(する)ツールだって気付いてないな。

こんな感じか。

>>1はポート0かも。

保守乙

IDが変わるまで書き込まない予感。

ツールも大切だけど、HDDはどこ製がいいんだろ？
激しいディスクアクセスに強いのはどのメーカー？
今はHGST製にキャッシュ置いてるけど、Seagate製に置いた方がいいだろうか？
そんとも２４時間運用前提のMaxlineとか高いやつ買った方がいいのかな？

サーバー向けのSCSIHDDは
SATAや一般向けのより耐久性が高いとか何とか聞いたことがあるような気がしなくもない

どっかのメーカーに容量少ないけど、他のに比べて倍近くシークタイムが短いのがあったな。
GByte単価は２５０円くらいだったが。

ほー

>>500
NECのブレードとかＮＸサーバのは市販品だよ。ファームは特注品に書き換えてるけどね。
メーカーは確かＷＤだったと思う。

> 多重アップロードについては、
> 現状、OSのキャッシュをバイパスするのと背反になってしまうのだけど、
> これを緩和する方法についてはアイデアがあり、近々実験してみます。

実験してみたら、ダメだった・・・orz

別の方法を考えるか、
OSのキャッシュに頼るのを一切やめるか、
それとも・・・

しゅー

・・・ハード的に解決させることにします。
Seagateの5年保証をご利用下さい。

















なんて書くと荒らしになっちゃう？ごめんちゃい

>506
壊れてからではキャッシュ保護という部分でこのツールに劣る対策だな
更新の多い大量のキャッシュを常時バックアップして解決するなら
そっちのHDDもほぼ同時にあぼーんしやすかろう

と、マジレスしてみる

個人的にはキャッシュはいつ逝ってもいいようにバックアップはしてるが
キャッシュHDDとダウンHDDがほぼ同時あぼーんってことはないだろ
そんな事言ったらこのツールの延命効果を否定することになるがな

送料無駄、RMA期間中停止、手続き面倒、おみくじ保証、Seagate嫌い
このへんがマジレス

>508
キャッシュと変換済みファイルを同一視してないか？

自分の好みのファイルだけがキャッシュに溜まるなら話は別だけど
キャッシュはクラスタである程度ジャンルは偏るとは言え様々なファイルが溜まる

どんなファイルにどんな重要度が有るかは個人判断だけど
nyネットワークにとっては、捏造でもない限り全てが大切な資産だから
それがまとめてあぼーんするのを防げない

というレスね >507 は。

んで、RAIDでミラーリングしてて続けざまに逝ったって話もたまに聞くし
キャッシュドライブを丸コピー(同期)するようなバックアップは微妙かなと。

　

なる
自分は無視リストで大体好みのキャッシュだけにしてるもんでね

SCSI-RAIDはどうかな
サーバーには向いてそうだけど高価すぎる。

ほしゅ

hosyu

ホシュ

hosh

保守連投ｳｻﾞ

UP0で多重ダウンなしで地引するには、これで十分ですよ。

>>1はポト0なんだよ。

>>1には酉ついてないから作者ではない予感。

光の速さでアップしまくってるけどバッチリ効いてる。
文句を言ってるのは、試してもいないか設定できない真性厨くらいだろ。

保守ですが何かーーーー！？

何が効いてるのかわからん。

>>520
何が効いてるんだ？
ばっちりとまで言うその効果を書き出してくれ。

>>522
効いているかどうかは、StatHddActivityでチェックしてください。
結果の読み方がわからなければ、スレにコピペしてください。見ますので。

StatHddActivityはHDDの挙動を知るためのものだろ。
ツールがしていることじゃなくツールで何が良くなるのかが知りたいんだが。

やれやれ

ツールを使い始めてから彼女が出来ました
ツールを使い始めてから１０�`痩せました
ツールを使い始めてから７千万のお金が手に入りました

これでいいのか？

ツールを使い始めてちょっとHDDが静かになった気がします。
ツールを使い始めて今までキャッシュ保持のためnypを使ってたけど、使う頻度が減りました。

StatHddActivityはかませ
本体はファイル情報公開。

>>525
それを調べるのも、このスレの目的の1つだと思います。

私一人でできることは限られていますので、
興味のある人が、各人のやり方で、
Winnyで使うHDDの寿命を延ばす方法を、
探求しましょうよ。

　　　　∧＿∧
　　　　（´・ω・）　　
　　　／ 　　　　＼
＿＿| |　　　　　| |＿
||＼　￣￣￣￣　　 ＼
||＼＼. 　　　　　　　　　＼
||.　.＼＼　　　　　　　　　　＼　　　 　∧＿∧.
.　　　 ＼＼　　　　　　　　　　 ＼| 　 （　　　）　ｷﾞｬﾊﾊわかったからパン買って来い
.　　　　　＼＼　　　　　　　　　　＼ /　　　 ヽ.
.　　　　　 　＼＼　　　　　　　　　／ .|　　　|　|
.　　　　　　　　＼∧＿∧　　　(⌒＼|_＿./ ./
　　　　　　　　　 （ 　　　　）オレおにぎり３個な∧＿∧
.　　　　　　　　　_/　　　ヽ　　　　　　　　　 ＼|　 （　　　）　金はお前が出せよ
.　　　　　　　　　|　　　　　ヽ　　　　　　　　　　＼ /　　　 ヽ、
.　　　　　　　　　|　　　　|ヽ、二⌒)　　　　 　　／ .|　　　|　|

じゃあ俺は、から揚げ君の黄色

保守乙

>>530
それはスレの目的じゃなくてツール作者であるお前の目的だろ。
本当に調べるのがスレの目的なら保守レスでスレが埋まるわけがない。
自分のカラ回りをもう少し自覚しろよ。

前向きに考えましょう。

スレの目的に対して時間を割ける人が少ない、ということだと思います。
本当に調べるのは非常に困難なことです。

年単位のスパンでの実験が必要です。
有意な傾向を掴むためには、かなりの数のサンプルが必要です。
どだい一人では無理だし、ある程度の人が集まっても、おそらく無理でしょう。

しかし、何もしなければ、何も始まりません。

ですから、とりあえず、
HDDのヘッドの移動量を減らせば寿命が延びる
という仮定で、それを実験できるようにツールを作っているのです。


ネガティブな発言や、お客さん気分の発言は、
2chならではのよくある情景ということで、
あまりそれに影響されず、
ポジティブかつ実践的にいきましょう。





といいつつ、今週もバージョンupできず・・・orz

また荒れそうな悪寒

WinmxはHDDに優しいの？

とりあえず、本日160GBのハードが逝きました。
10年間のコレクションが無くなった。
nyのせいではないけどね。

i-RAMにキャッシュ貯めてる人いる？
回転してないしi-RAMなら守る必要もないのかな？

>>539
ヒント(?)：バッテリーがなくなるとデーターが消える

>>540
もひとつヒント：電源切ってもマザーボードに通電していればデータは保持されている

最終ヒント：iRamの最大容量は4GB

Ramって使いどころがよくわからんな・・

i-RAM最大容量の4GBを多いと見るか、少ないと見るか…
内臓バッテリーを使って、約16時間位は内容は保持されるみたいだけど。

内臓バッテリーか


生体部品？

　　　　∧＿∧
　　　　（´・ω・）　　
　　　／ 　　　　＼
＿＿| |　　　　　| |＿
||＼　￣￣￣￣　　 ＼
||＼＼. 　　　　　　　　　＼
||.　.＼＼　　　　　　　　　　＼　　　 　∧＿∧.
.　　　 ＼＼　　　　　　　　　　 ＼| 　 （　　　）　ｷﾞｬﾊﾊわかったからパン買って来い
.　　　　　＼＼　　　　　　　　　　＼ /　　　 ヽ.
.　　　　　 　＼＼　　　　　　　　　／ .|　　　|　|
.　　　　　　　　＼∧＿∧　　　(⌒＼|_＿./ ./
　　　　　　　　　 （ 　　　　）オレおにぎり３個な∧＿∧
.　　　　　　　　　_/　　　ヽ　　　　　　　　　 ＼|　 （　　　）　金はお前が出せよ
.　　　　　　　　　|　　　　　ヽ　　　　　　　　　　＼ /　　　 ヽ、
.　　　　　　　　　|　　　　|ヽ、二⌒)　　　　 　　／ .|　　　|　|

>>1はOSを知らない予感。

またお前か。

保守乙

>>544
キャッシュにしてもダウソフォルダにしてもぜんぜん足りない。

>>544
>内臓バッテリーを使って、約16時間位は内容は保持されるみたいだけど。
だからそりゃ停電の場合だアホ。>>541を100回くらい音読してみろ。

日本語が読めるならだが。

>>529
いまどきfwも入れてないんですか？

OS:WinXP HOME SP2
CPU:ATHRON64 3500+
HDD:Seagate ST3160827AS (検証の為、DownCacheOS兼用)

DisableOsBufferAndCache=1
EnableActivityLogging=1
CacheSizePerEachFile=2

使用
�@計測開始から0日00時間20分07秒 (1,207秒)
ドライブ0
�A総転送量 5,464,653 セクタ(2,797,902,336 バイト)
�B総ヘッド移動量 649,632,141,339 セクタ
�C総応答時間 484,044,209 nsec
�D総IOP数 49,492 個
�E連続した領域へのアクセス 19,923 回
�A÷�@=1秒あたりの転送量 4,527 セクタ(2,318,063バイト)
�B÷�@=1秒あたりのヘッド移動量 538,220,498 セクタ
�C÷�@=稼働率 0.0401 %
�D÷�@=1秒あたりのIOP数 41.00 個
�E÷�@=1秒あたりの連続した領域へのアクセス 16.51 回
�B÷�A=1セクタあたりのヘッド移動量 118,878 セクタ
�A÷�D=1IOPあたりの転送量 110.41 セクタ
�B÷�D=1IOPあたりのヘッド移動量 13,126,003 セクタ
�A÷�E=1連続アクセスあたりの転送量 274.29 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 32,607,144 セクタ
�D÷�E=1連続アクセスあたりのIOP数 2.48 個

不使用
�@計測開始から0日00時間21分11秒 (1,271秒)
ドライブ0
�A総転送量 1,379,202 セクタ(706,151,424 バイト)
�B総ヘッド移動量 309,657,724,953 セクタ
�C総応答時間 84,946,181 nsec
�D総IOP数 14,298 個
�E連続した領域へのアクセス 7,727 回
�A÷�@=1秒あたりの転送量 1,085 セクタ(555,587バイト)
�B÷�@=1秒あたりのヘッド移動量 243,633,143 セクタ
�C÷�@=稼働率 0.0067 %
�D÷�@=1秒あたりのIOP数 11.25 個
�E÷�@=1秒あたりの連続した領域へのアクセス 6.08 回
�B÷�A=1セクタあたりのヘッド移動量 224,519 セクタ
�A÷�D=1IOPあたりの転送量 96.46 セクタ
�B÷�D=1IOPあたりのヘッド移動量 21,657,415 セクタ
�A÷�E=1連続アクセスあたりの転送量 178.49 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 40,074,767 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.85 個

774 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2005/09/29(木) 15:57:31 ID:iZ6lI9Es0
すごくアヤシイソフトを発見

BT Engine 4.6
http://www.soft4kids.com/

要するにPCの設定をBitTorrent用に最適化して、
なおかつHDDへの負荷を抑えてくれるらしい。あらゆるタイプのBitTorrentクライアントに
対応していて、各クライアントを起動する前にBT Engineを起動させておくらしい。
実際にするのはポートの開放を動的に行うことと、接続数を50以上に引き上げること。
それから、各クライアントが機能的に内包している上限速度を最大にまで引き上げるらしい…。
また、HDDに書き込む前にメモリにため込む量を多くして書き込み頻度を減らして
HDDを保護する…とのこと。

あーああーーー

質問、ウィニーを開くとCPU率が１００％になるんだけどどうやったらなおる？

このスレのツール使っての話か？
使ってないならスレ違いだが

>>557
CPUが言うことを聞くまでハンマーで叩けばOK

保

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

1セクタあたりのヘッドの移動量は半分近くになっていますが、
総転送量が4倍になっているので、
Winnyからのファイルアクセスの量の違いがあったのか確認するために、
モニタの中段に表示される内容も併せて報告してください。

設定は>>553のまま

�@計測開始から0日00時間20分00秒 (1,200秒)

ドライブ0
�A総転送量 602,662 セクタ(308,562,944 バイト)
�B総ヘッド移動量 215,649,705,313 セクタ
�C総応答時間 21,882,446 nsec
�D総IOP数 9,625 個
�E連続した領域へのアクセス 5,985 回
�A÷�@=1秒あたりの転送量 502 セクタ(257,135バイト)
�B÷�@=1秒あたりのヘッド移動量 179,708,087 セクタ
�C÷�@=稼働率 0.0018 %
�D÷�@=1秒あたりのIOP数 8.02 個
�E÷�@=1秒あたりの連続した領域へのアクセス 4.99 回
�B÷�A=1セクタあたりのヘッド移動量 357,828 セクタ
�A÷�D=1IOPあたりの転送量 62.61 セクタ
�B÷�D=1IOPあたりのヘッド移動量 22,405,164 セクタ
�A÷�E=1連続アクセスあたりの転送量 100.70 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 36,031,696 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.61 個

収拾できなかったイベントの数 0個

ファイルアクセスの累計
Readキャッシュ： ヒット 2,531 回、ミス 315 回、ヒット率= 88.93 %
Writeキャッシュ： 遅延 4,466 回、フラッシュ 290 回、遅延率= 93.90 %
ReadFile呼び出し回数： アプリから 2,866 回、OSへ 598 回、Ratio= 20.87 %
ReadFileバイト数： アプリから 86,531,500 バイト、OSへ 223,461,485 バイト、Ratio= 258.24 %
WriteFile呼び出し回数： アプリから 4,558 回、OSへ 486 回、Ratio= 10.66 %
WriteFileバイト数： アプリから 245,153,936 バイト、OSへ 243,987,425 バイト、Ratio= 99.52 %

未使用
DisableOsBufferAndCache=0（念のため
DisableCache=1
�@計測開始から0日00時間20分00秒 (1,200秒)

ドライブ0
�A総転送量 834,910 セクタ(427,473,920 バイト)
�B総ヘッド移動量 509,321,620,867 セクタ
�C総応答時間 50,114,284 nsec
�D総IOP数 13,310 個
�E連続した領域へのアクセス 10,134 回
�A÷�@=1秒あたりの転送量 695 セクタ(356,228バイト)
�B÷�@=1秒あたりのヘッド移動量 424,434,684 セクタ
�C÷�@=稼働率 0.0042 %
�D÷�@=1秒あたりのIOP数 11.09 個
�E÷�@=1秒あたりの連続した領域へのアクセス 8.45 回
�B÷�A=1セクタあたりのヘッド移動量 610,031 セクタ
�A÷�D=1IOPあたりの転送量 62.73 セクタ
�B÷�D=1IOPあたりのヘッド移動量 38,266,087 セクタ
�A÷�E=1連続アクセスあたりの転送量 82.39 セクタ
�B÷�E=1連続アクセスあたりのヘッド移動量 50,258,695 セクタ
�D÷�E=1連続アクセスあたりのIOP数 1.31 個

収拾できなかったイベントの数 0個

ファイルアクセスの累計
Readキャッシュ： ヒット 0 回、ミス 0 回、ヒット率= 0.00 %
Writeキャッシュ： 遅延 0 回、フラッシュ 0 回、遅延率= 0.00 %
ReadFile呼び出し回数： アプリから 4,530 回、OSへ 4,530 回、Ratio= 100.00 %
ReadFileバイト数： アプリから 136,387,652 バイト、OSへ 136,387,652 バイト、Ratio= 100.00 %
WriteFile呼び出し回数： アプリから 5,163 回、OSへ 5,163 回、Ratio= 100.00 %
WriteFileバイト数： アプリから 288,652,662 バイト、OSへ 288,652,662 バイト、Ratio= 100.00 %

>>562-563
ありがとうございます。

ヘッドの移動量をアプリからの読み書き量で割って、
1バイトあたりのヘッドの移動量を計算すると、

ON : 650セクタ
OFF : 1,198セクタ

ということで、効いているようですね。


しかし1つ、気になる点があります。

>>562では、OSへのReadFileとWriteFileのバイト数を足すと467MBなのですが、
StatHddActivityは308MBと少ないです。
OSのキャッシュをバイパスすれば、
StatHddActivityは467MBよりも若干大きくなるはずです。

ということは・・・バグかも・・・。

うへっ(；´д｀)

ほっっしゅ

ほー

winny用にハードディスクを一台つかうばあい
そっちにwinnyのプログラム本体も入れたほうがいいの？
プログラム自体は別にきにせんでもいいんかな

微々たるもんだろ

キャッシュ用HDメーカーはどこがオヌヌメ？

SATA系の性能で言えばSeagateがいいらしい。

保守

ho

>>564の件ですが、
他の方の環境でも、同様の現象が発生していますか?

ほしゅ。

最近NYしてないなぁ…

http://www.watch.impress.co.jp/akiba/hotline/20051119/etc_nl35.html

プログラミング未経験者が
ファイル交換ソフトやこのスレの感じのツールを作るには、どの言語を勉強すれば良いですか？
あと、お勧めの本を教えていただけるとうれしいです。

「Borland c++」で参考書を探しても見つからないので、おとなしくM$の物を買うしかないのかなと思ったり。。。
よろしくお願いします。

初心者にはDelphiが良いらしいです。
一度も使ったことがないので、良いらしい、としか言えないのですが。

プログラミング言語は、何か1つだけに絞るのではなく、
作るものによって使い分けると思っておいたほうがいいです。

何かのソフトを作るには、大雑把に、
・プログラムの作り方
・プログラミング言語の文法
・OSのAPIの使い方、ライブラリやフレームワークの使い方
・その「何か」を作るために必要な専門知識
の4つが必要になります。

プログラムの作り方は、言語によりません。どの言語でも勉強できます。
プログラミング言語の文法は、さほど難しくありません。いくつもの言語を習得するのが普通です。
OSのAPI、ライブラリやフレームワークの使い方は、それらのマニュアルを読めばわかります。

がんばってください。

　　　　∧＿∧
　　　　（´・ω・）　　
　　　／ 　　　　＼
＿＿| |　　　　　| |＿
||＼　￣￣￣￣　　 ＼
||＼＼. 　　　　　　　　　＼
||.　.＼＼　　　　　　　　　　＼　　　 　∧＿∧.
.　　　 ＼＼　　　　　　　　　　 ＼| 　 （　　　）　ｷﾞｬﾊﾊわかったからパン買って来い
.　　　　　＼＼　　　　　　　　　　＼ /　　　 ヽ.
.　　　　　 　＼＼　　　　　　　　　／ .|　　　|　|
.　　　　　　　　＼∧＿∧　　　(⌒＼|_＿./ ./
　　　　　　　　　 （ 　　　　）オレおにぎり３個な∧＿∧
.　　　　　　　　　_/　　　ヽ　　　　　　　　　 ＼|　 （　　　）　金はお前が出せよ
.　　　　　　　　　|　　　　　ヽ　　　　　　　　　　＼ /　　　 ヽ、
.　　　　　　　　　|　　　　|ヽ、二⌒)　　　　 　　／ .|　　　|　|

じゃあ俺は、から揚げ君の黄色

じゃあ俺赤な

　　　　　　　　　　ｨﾆ三≡ヽ　　　　　　　　　 　／ ￣　　￣ ＼
　　　　　　　　　/jj7　　＼ﾐt　　　　　　　　　 /、　　　　　　 　　 ヽ　はぁ？黙ってろデブ
　　　　　　　　彡jj_ｒ==i_ｒ=tiミ　　　　　　　 　|・ |―-、　　　　　　 |
　　　　　 　 　彡l.　￣・・￣ ﾐ　　　　　　　　ｑ -´　二 ヽ　　　　　 |
　　　　　　　　　_lt　　'=t 　/__　　　　　　　　ノ＿　ー　 |　　　　　|
　　　　 　_,　-t"lt__　　　　j l　＾ﾞ''ｰ ､　　　　　＼.￣｀　 |　 　 　　/
　　　　／ 　　　　ヽ￣　丿7　　　　　＼　　　　　O＝＝＝＝＝ |
　　　/　　　　　　　`-‐''ﾞ　　　　　　　　 ヽ　　　/　　　　　　 　　 |

>>579=582

保守乙

>>581=>>583

保守