■□NTFSでしょう？いまどきFATですか？□■
情報の海であっぷあっぷ ニュースレターのご案内より
http://www.microsoft.com/japan/technet/security/secnews/columns/column061025.mspx
2 ちゃんねる
言わずと知れた巨大掲示板です。
さまざまな板がありますが、Windows 利用者におすすめしたいのは、
Windows 板の「Microsoft Updateしたときにageるスレ」(現在は 27) と 「Windows Update失敗したらageるスレ」 (現在は 12)です。
毎月第 2 火曜日の深夜から、ヒトバシラー精神旺盛な猛者達がインストール報告をしてくれます。
修正プログラムに何か不具合があれば、何かそれらしい書き込みがなされる事が多いです。
ただし、報告者のローカル環境が原因の場合も少なくないので注意しましょう。
これも Windows 板の「■□NTFSですな？いまだにFATですか？□■」においては、
MS06-049 修正プログラムによる NTFS 圧縮したファイルの不具合に関して、
世界で最も詳細な分析と対応がなされたことは特記しておいてよいでしょう。2 ちゃんねる、あなどりがたし。
企業によっては 2 ちゃんねるへのアクセスを禁止しているところもあるでしょうが、
少なくとも特定の板については閲覧を許可しても損はしないと、個人的には思います。 FAT32はNTFSよりもエラーの数は少ないぞ。だからこそFAT32！
まぁエラー検出出来ないだけだろうが。 今日のNTFS
外付けUSB-HDD160GB
「ファイル構造が壊れていて読み込めません」
C:\>chkdsk f: /F
ファイル システムの種類は NTFS です。
ボリューム ラベルは Maxtor160 です。
CHKDSK はファイルを検査しています (ステージ 1/3)...
ファイルの検査を完了しました。
CHKDSK はインデックスを検査しています (ステージ 2/3)...
インデックスの検査を完了しました。
CHKDSK はセキュリティ記述子を検査しています (ステージ 3/3)...
セキュリティ記述子の検査を完了しました。
ログ ファイルの不良クラスタを置換しています。
1 個の不良クラスタを不良クラスタ ファイルに追加します。
ボリューム ビットマップ エラーを修復します。
ファイル システムを修正しました。 ちなみに、何度も CHKDSK ｆ： /F /R をやってある。
また、書き込みは、Firefilecopyでverifyを掛けながらやっていた。
FLUSHに時間が掛かったから妙だなと思って、再起動したら、
「ファイル構造が壊れていて読み込めません」
多分、本体のデータは書けたからＯＫを返してきたんだと思う。
同じディスクにジャーナルを書いて、それがこけたら、あやうく全損とか間抜け。
一連のシーケンスでちゃんと不良クラスタの対処をするのならまだしも。 >>8
何がいいたいのかさっぱり分からん。まずはHDD全体が壊れたのか、特定のファイルだけなのか。 ああ、手っ取り早く言うと、危うくデータ全滅だったが、手順を踏んで、
最終的にCHKDSK（>>8)が、全部のデータを救った。
余談を少々。
USBコネクタを挿したあと、HDDがカシャンカシャンと果てしなくやり始め、
マイコンピュータが延々と懐中電灯に照らされたときには、全滅を覚悟した。
CHKDSKが効いた後も、つないだＰＣはスローダウンし、挙動も怪しいので
ネットワーク越しに100GB以上のデータを別のPCでコピーした。 何が言いたいのかが抜けていた。
ＮＴＦＳは思わぬ原因でボリューム全部のデータが吹き飛びます。
今回は、ジャーナルを書いたところが不良クラスタだったのが原因です。
書き込み時のベリファイがＯＫでも安心できません。 >>12
ジャーナリングにしろ他の技法にしろ、ストレージがデータの正当性を保証して
くれるという前提の下にファイルシステムが壊れないようにする技術なわけで、
不良セクタ処理がハードの手に余る（＝ストレージ破損）な時点でもうジャーナル
には対処できない。それは何度 chkdsk をやろうが、何度 verify をやろうが同じ事。
まあ、今のうちにRAIDでも組んでディスク破損に備えよというお告げなのでは。 せっかくのお告げだが、よく考えてみて欲しい。
一つのファイルの管理の失敗のためにボリューム全体のデータを失いかけた
のであるから、RAID（1や5や0+1や…）を組んでも、事情は変わらない。
というより、むしろ危険に晒すデータ量が増大する。
CHKDSKに /F /R を付けると、STEP4でファイルの調査、STEP5で空き領域の
調査をするのだが、それで不良セクタが発見できないとなると．．．
HDDメーカーのWebでToolを漁ってみるか。
ディスク検査プログラムをご存知の方は教えてください。 >>14
君、>>13が言ってること微塵も理解してないだろ >>15 心配無用。君が話についてこれているかの方が心配。 横からだが14がそんなに理解しているなら
>HDDメーカーのWebでToolを漁ってみるか。
>ディスク検査プログラムをご存知の方は教えてください。
この位は普通に知っていると思うのよ。
俺も>>15と同じ意見だな。 > 君が話についてこれているかの方が心配
何言ってんだこいつw >>12
> ＮＴＦＳは思わぬ原因でボリューム全部のデータが吹き飛びます。
吹き飛んでないじゃん。ウソを書くな、と。
> 今回は、ジャーナルを書いたところが不良クラスタだったのが原因です。
ジャーナリングファイルってのはそれ自体が予備みたいなもんだから、壊れたところでたいしたことない。
停電とか何らかの原因でファイルの書き込みが中途半端に終わった時に、復旧するためのデータだからね。
だいたい
>>12
> 書き込み時のベリファイがＯＫでも安心できません。
今時書き込みでベリファイするHDDやファイルシステムはないだろう。
HDD側にライトバッファをもっていてファイルシステムはそこに書き込み完了した時点で、
「ファイルは正常に書けた」と考える。HDD側がそれをバッファからメディアに書くのは
もはや自己責任としかいいようがない。書けなければそれはもうあきらめるしかない(笑
HDD側は代替えセクタ処理とかで対処仕様とするはずだけど、代替えセクタも残ってなければそれでアウト。
やあ、２chらしい展開だね。まとめで失礼。
>>17 14のレスだけ読んだら釣られてしまったね。
>>20 君が21で書いているように代替セクタが残っていなかったらアウト(全損)
そういう事態がジャーナルごときで起こるのだから間抜けな仕様だ。
>>11の余談のような状況を大した事無いと言えるか？
>>21 だから、わざわざベリファイ機能付きのコピーツールを使った。
もちろん、ライトバッファをフラッシュしてから読みに行く仕様。
部分的にしか読まない／理解できない人の脊椎反射レスは勘弁してくれ それと、話に乗ってくれるのは嬉しいのだが、
こんなケースに遭遇するのは、
１億人に１人いるかいないかのトホホな奴だと思う >>22
代替セクタが無くなった時点でそのディスクは破損ディスクだから。
それがどんな形の破損だろうと、破損したディスク上に正常なデータを
残しておけると思う方がおかしい。 無知の横槍で申し訳ないんだけど、
不良セクタが見つかった場合って、そのセクタを無視して(データが書き込まれている
ように見せかけて)他のセクタに書き込むような処理をコントローラ or ドライバがやって
くれることはないんだっけ？
取りあえず>>23の馬鹿ッぷりを修正するのは困難という
ことが解った。 うん。それはいいからさ。
かしこい皆様のおちからで、>>25の疑問に答えてあげてくれないかな。
それと、>>13のRAIDに対する盲信も、わかりやすく、解消してあげて頂戴な。 >>22
> もちろん、ライトバッファをフラッシュしてから読みに行く仕様。
そのライトバッファはOSのライトバッファだろう？
HDD側のライトバッファまでフラッシュを指示するのはアプリレベルではできない。
>>22
> >>20 君が21で書いているように代替セクタが残っていなかったらアウト(全損)
何度もいうけど20で書いてるようにジャーナルファイルは壊れても致命的ではない。
実際復旧できたんだろ？ウソを書くな、と。実際に復旧できなかったならともかく。
> そういう事態がジャーナルごときで起こるのだから間抜けな仕様だ。
じゃあどうなればいいのさ？例え書き込みをいちいち確認したところで(そんなことをしたら
HDDのパフォーマンスは10分の1ぐらいになりそうだが)、HDDは壊れるわけだよ？
つまり著しくパフォーマンスを低下させて安全を優先したところで、HDDが壊れればデータは失われる。
そこそこのパフォーマンスとそこそこの信頼性でバランスを取るのが正しい。
それがいやならRAIDを使うことですな。あなたはRAIDというものをよく分かってないらしいが。
> >>11の余談のような状況を大した事無いと言えるか？
何度もいうけどデータは結局普及できたんだろう？chkdskは単に破損したジャーナリングファイルを
消去しただけだと思うよ。ジャーナリングファイルというのは基本的に不要なんだから。
その後スローダウンしたというのは知らん。デフラグでもかけたらいいんじゃないの？
しかしUSBやIEEE接続のHDDは俺は信頼を置かないがね。
それはXPのバッファフラッシュ機構に問題があってクラッシュしやすいから。
これを語ると長くなりすぎるからここでは語らないが、ハード板とかではよく知られた話。
あまり信頼しないで普通に使うか、重要な用途に使うなら書き込みバッファをOFFにして使うべき。
>>29
> それと、>>13のRAIDに対する盲信も、わかりやすく、解消してあげて頂戴な。
別に盲進じゃないと思うけどね。RAIDにすれば基本的に壊れない(RAID0は別ね)。
まあ複数台のHDDが同時に壊れれば別だが。
どうも>>22あたりはRAIDのことを分かっていないんだろう。
だいたいRAIDにすると書き込むデータが増えるから壊れやすいとかいってる時点で
RAIDのことがよく分かってない証拠。 馬鹿はスルー。どうしてこんなに簡単なことがあなたたちには出来ないんですか？ >>37
馬鹿の考えることは常人には難しすぎなんだよ 前スレでもう不要なスレじゃないかと言われたが
一気に盛り上がったな。 不良クラスタと不良セクタの区別付いてないっぽいな。 >>34
代替セクタは潰れたセクタへの読み書き要求を、専用の別領域への読み書きに置き換えること。
>>25の質問してる内容とは全然違うだろう。日本語くらいちゃんと読め。 >>40
> 不良クラスタと不良セクタの区別付いてないっぽいな。
中途半端な知識を持ってるヤツは無知な人間よりたちが悪いねぇ。 >>41
> 代替セクタは潰れたセクタへの読み書き要求を、専用の別領域への読み書きに置き換えること。
だからそういってるだろうに。
> >>25の質問してる内容とは全然違うだろう。日本語くらいちゃんと読め。
いや同じだね。
そもそもね、わざわざ>>25は「コントローラ or ドライバ」というのだからファイルシステムではない、と
いいたいのだろう。ファイルシステムが行うのが不良クラスタの処理であり、HDDが行うのが
代替えセクタの処理。>>25はおそらくHDD側で行われる代替えセクタのことを、知識が十分でないので
コントローラ or ドライバがやると勘違いしているわけで、いっていること自体は代替えセクタの話なわけだよ。
一方不良クラスタの処理というのは書き込みバッファを持っているHDDの場合、ほとんど有効に働かない。
大昔のカキコもバッファのないHDDではある程度機能したけどね。いまはchkdsk時ぐらいしか機能しない。
なぜって？HDDが「書けてない」のにOSに「書けた」と報告してくるからだよ。OSはHDDのライトバッファに
書き込み終わった時点でHDDにきちんと書きもめたと思いこむ。それが本当にHDDのメディアに書き込めたかの
確認などしない。HDDは自分の都合でライトバッファの内容をメディアに書き込むから、OSから見れば
いつ本当に書けたかなど分からないし、忘れた頃に「そういえばあのデータ書けましたよ」などと報告されても
いまさらどうしようもないからね。
ベリファイもHDDのライトバッファやキャッシュに対して行われるから、実際にメディアから読み直している保証はない。
もちろんHDDに低レベルのコマンドを送ればライトバッファをフラッシュするとか無効にすることはできるよ。
しかしそれは通常のアプリからは出来ない。そういうHDDにそういうコマンドを発行すれば一時的にせよ
HDDのパフォーマンスが大幅に落ちるから、OSはそういうことを一介のアプリには許さない。
OS上ではいろんなアプリが同時に動いているし、OSそのものもスワップファイルとかで使用しているわけで、
普通のアプリの都合でそれらのパフォーマンスを大幅に落とされてはたまらないからね。
まあなんというか>>22ってのは頭の中がMS-DOSの時代なんだよね(笑
憶測だらけの丁寧な長文や、非生産的な一行レスを、深夜、早朝の時間帯に
頂いておりながら、いささか恐縮ですが、>>37の助言に従います。
>>13 下記URLの「アクティブリペア」の項の一読を。また自作PC板の
RAIDカードスレの過去ログで「原因不明」を検索してみてください。
ttp://www.iodata.jp/prod/network/fileserver/2006/hdlm-gwin/
（注：一部記述に曖昧な個所があります）
HDDが「ちゃんと壊れて」、差替え−(長時間の)リビルドで済めば幸せです。
過去に経験したデータセンターでの事故と復旧作業を考えると、
個人でRAIDを組むのは御免です。
>>25 上記URLの一読、また「HDDパトロール」でぐぐってください。
トホホと自覚している方へ：
不良セクタがデータ記録部分ではないとき、CHKDSK /Fは思わぬ損害を
もたらします。その確率は低いですが、今回は表示されたエラーの意味を
斟酌して、週末までCHKDSK以外の方法を試していました。
ベリファイについてはツール作者に迷惑をかけない様、黙します。
もう、おしまい。はらへった。 次スレ
■□NTFSですか？もうWinFSですよね？□■
そんなことより今日のupdateにkernelの修正来てるぞ だからどうした。
ntfs.sysやfastfat.sysの修正が来てるぞならwktkだが。 >>42
>>8に対して言ってんだけど？
ジャーナリングファイルで不良クラスタが見つかったってのが、いつの間にやら不良セクタになってるし。
>>45
要するにRAID6使えばいいじゃんてことだろ？
ttp://www.atmarkit.co.jp/fsys/keyword/019raid6/019raid6.html
>ベリファイについてはツール作者に迷惑をかけない様、黙します。
既に書いてるぞ。 >>44
>しかしそれは通常のアプリからは出来ない。
ATA_PASS_THROUGHがあるから、できる・できないで言えばできるでしょう。
やらんけど。 100MBぐらいゴミデータ書いてキャッシュを押し流すとか >>45
> HDDが「ちゃんと壊れて」、差替え−(長時間の)リビルドで済めば幸せです。
なんというか要するにRAIDというものを分かっておらず当然使ったこともない人間が断片的な知識で
何かよく分からない勘違いを重ねてるって理解でOK？(笑
> >>25 上記URLの一読、また「HDDパトロール」でぐぐってください。
何をどう勘違いしてるのかさっぱり推測できないので、何もいえないが、代替えセクタ処理というのは
HDD単体の機能として持ってるわけだよ？知ってた？
> 不良セクタがデータ記録部分ではないとき、CHKDSK /Fは思わぬ損害を
そりゃねぇ。そんなのは今更いうまでもないこと。HDDは壊れるものだ。誰も「壊れない」などといっていない。
たとえば火事や地震でHDDが跡形もなくなってもRAIDを使えばデータが復旧できるなんて魔法みたいなことがあるわけないよねぇ。
あなたは結局何を期待してて、何が「期待通りでない」から「不満」なわけ？(苦笑
> 斟酌して、週末までCHKDSK以外の方法を試していました。
よく分からないなぁ。ファイルが壊れたらchkdskってのは基本だと思うよ。
もちろんchkdskで回復できないことはある。しかしそれは他の方法でも回復できない。
> ベリファイについてはツール作者に迷惑をかけない様、黙します。
何度もいうけれど、ベリファイというのはそういうもの。最近のHDDとOSにおいてはね。
本当に書き込んだデータを物理的にメディアから読み込み直しているかは保証されない。
OSがそれを許さないんだからしょうがないじゃん(笑
ベリファイをしようがなにをしようが、ファイルが壊れること可能性はゼロにはならないのだから、
大幅にパフォーマンスを落としてまで「本当に書き込めたか」は保証しないのが今風の流れなわけ。
>>50
> >>8に対して言ってんだけど？
俺はおまえの親じゃないんだから、そんなの分かるわけないだろ？レス番号もつけずに。何いってるのやら(笑
> ジャーナリングファイルで不良クラスタが見つかったってのが、いつの間にやら不良セクタになってるし。
今思ったんだが>>22はジャーナリングファイルとメタデータをごっちゃにしてるんだろうな。
>>51
> ATA_PASS_THROUGHがあるから、できる・できないで言えばできるでしょう。
デバイスに直接命令を出すには管理者権限が必要なわけで、一般アプリがやってはいけない。
というかそれをやると普通のユーザーはそのアプリを動かせない。
まあXPの場合はパワーユーザーで使っていることが多いから、たまたま出来るというだけ。
デバイスの直接命令出せたらファイルのアクセス権とかのセキュリティがめちゃくちゃになるだろうに。
>>55
まじめに作りこむならそういう部分はサービスやドライバにして作るでしょ。
知識はそこそこあるんだけど頭かたくね？ >>56
俺はアプリの話をしてるんだが？頭悪くね？
>>57
やっぱり頭がかたいね。
一部機能をドライバ・サービスで実装してもアプリはアプリですよ。
ユーザモードのみ、1プロセス限定なんて縛りがあるとでも思っているの？
頭がかたいと言うよりは、元気、初々しい、無邪気、浅い狭い てなもんかな。春だ。 >>60
Vista(32bit)のntfs.sysはずいぶんとまたデブだな。
NTFS周りってなんか変わってるんだっけ？ >>58
ホントアホだね。
俺が「アプリで」といってるのになんで、「サービスを使えばできる」とわけのわからないことを言い出すのかなぁ。
もしかして「そういうアプリはどうやっても作れない」と言ってると思ってるの？
それじゃドライバを叩くUIなんか存在しなくて、全部設定ファイルをテキストエディタで開いて、
変更したらリブートってなっちゃうじゃん。もうアホかと。
だいたさぁ、他のアプリが動いてるんだから(おまけにOSのスワップもだ)、あるアプリの都合でそのHDDの
ライトバッファを無効にするとかしたら、他のアプリに迷惑じゃん。で、そういうことをどうしてもやりたい場合のために
コントロールパネルのデバイスマネージャに、無効にする機能がついているわけで、何をいっているのやら。
たとえば同じようなことをするアプリが2つインストールされて両方同時に起動したらまともに動くのやら。
たぶんそのソフトは、動き始める時にライトバッファを無効にして、動作し終わったらまたライトバッファを
元通り有効に戻すはずだよね。Aというアプリが無効にしてる最中、Ｂというアプリが動き、さらに無効にして、
Aのアプリが先に処理を終了したら、たぶんAはＢのことなんかお構いなしに、ライトバッファを有効に戻すだろう。
Ｂは自分では「無効にしてる」と思いこんだまま動くわけだ。
ったくなんというかこういう自分のことしか考えないアホが他のアプリに迷惑をかけて
知らん顔しているようなソフトを作るんだろうねぇ(苦笑
要するに、こういうことはそのHDDに対して排他的に占有権を確保した上で行うべき処理なわけ。
で、そういう処理を一介のアプリがすることはできないってこと。
少なくともＣドライブにそんなことをするアプリがあったら、俺は使わないね。 >>60
なんかNTFSってバグだらけじゃん。なんなんだよ。
やっぱりメカだったか。
適切じゃない例を持ち出し無駄な長文を書いて誤魔化す芸風は
相変わらずだ。まったく進歩がないな。
>>62
おそらくTxF >>66
> 何が言いたいのか理解できん
自分勝手なアプリははた迷惑で、そういうアプリをリスクも考えずに作る作者はアホってこと。
>>67
十分適切だと思うけどね。ただのファイルコピーのためのツール(アプリ)の話なのに
システムサービスをインストールしてそれを叩けば書き込みバッファの無効かも不可能じゃない、
とか言い出す時点で、そっちの方が適切ではないわけだよ。
俺はそれがどれほど適切でないことかを示しているだけ。
俺) 「○○は不可能」
アホ) 「いや、○○は××すれば可能」
俺) 「××するのは非現実的。たとえて言えば犬のノミを殺すために犬を焼却炉に放り込めば可能というようなもの」
アホ） 「焼却炉に放り込むなんて話は適切ではない」
こんな感じ？（苦笑
>>68
FFCってFireFileCopy？
まあアレはねぇ。がんばって作ったツールだとは思うけど、俺はさして使う気にはなれないけどね。
Win9xはともかくＸＰ等ならキャッシュはそこそこ適切に働く。もちろん「もっと賢ければ」とは思うものの、
わざわざファイルコピーのためのツールを使うほどではない。
だいたいFireFileCopyってのは同一の物理ドライブの複数のパーティション間でのコピーでは
僅かながら有益だけれど、異なる物理ドライブ間のコピーならほとんど優位性はない。 ついで
http://www.k3.dion.ne.jp/~kitt/pc/sw/ffc/help/faq.htm
> この設定は Webや雑誌で「高速化」と称して、間違って紹介されています。
> (アプリケーション起動用に4MBのメモリを云々とか、メモリモデルをLargeに云々という言い方で説明している場合もあります)
4MB云々ってのは間違いじゃないのだが意味するところを誤解して紹介しているサイトが多いんだよね。
> デスクトップ用途ではあえて「システムキャッシュ」にするメリットはなく、かえって思わぬトラブルを招くだけです。
まあこれは同意ですな。Largeにしてもアプリの起動が遅くなるだけだ（苦笑
> またレジストリのIoPageLockLimit設定も誤って紹介されていることが多いです。
> この設定はWin2000 SP1以降は無視されることが知られています。
いや無視はされない。現にこれの設定を妙にいじると問題が生じることがある。
特定の状況でATIのグラフィックドライバがエラーを出す。まあこの場合はIoPageLockLimit自体が
悪いのではなくて、これを大きくしたことで間接的に他のテーブルが足りなくなるのだが。
まあこの値を大きくすればファイルの読み書きのバッファが大きくなると言うような単純なものではないので、
いじらない方が無難という意味では同意だけどね。
> こういった「高速化」「チューンアップ」を紹介している雑誌やWeb、そういう設定を行うソフトは五万とありますが、
> 実測値まで出しているのを見たことがありません。情報だけが独り歩きしている状態といえますので、要注意です。
まあ気持ちは分かる（笑
ＸＰの場合、いわゆる「都市伝説」的なチューニングが蔓延してるからねぇ（苦笑
あと、上の方でちょっとにおわせたが、USBおよびIEEE接続のHDDはXPの場合、大量に連続して
書き込みを行うと問題が生じやすい。XPのファイルシステムはOS側の書き込みバッファにデータを
書き込んだ時点で「完了」と見なすが、USBとかの場合転送速度がIDEなどと比べると遅いし、
しばしば転送時にエラーを起こす。
たとえばUSBデバイスの中にはUSBのバスリセットコマンドを不用意に発行するものがある。
そしてUSBハブの中にはこのコマンドの処理が適切ではないものが若干あり、他のUSBデバイス
がバスリセットを発行するとUSB接続のHDDへのデータ転送が中断してしまい、
結果的に書き込みエラーとなることがある。そうでなくてもリトライが行われるので時間がかかる。
一方ファイルシステム側はOSの書き込みバッファに書き込まれたデータは一定時間で
書き出しが完了することを前提としているから、何らかの原因でもたついていると「HDD書き込みエラー」
というような恐ろしいエラーメッセージを出す。
さらにいえば過去にUSBやIEEE関連で書き込みが2重に行われるバグがＸＰには存在した。
まあ同じデータが二回書かれるだけだからそれが直ちにファイル破壊につながるわけではないが、
結果的に書き込みデータが増えるので上記のようなタイムアウトが生じやすくなる。
なのでUSB接続のHDDではデバイスマネージャで書き込みキャッシュを使わない設定で使うのが無難。
そうすればエラーのリスクは減る。逆にFireFileCopyの用にわざと連続して書き込みを行うツールでは
この問題が生じやすい。ツールが悪いわけではないけれど、結果的にはそういうツールを使うと
問題が生じる確率が増えるということ。
>>69
> ただのファイルコピーのためのツール
また、そんな前提を勝手に持ち出しましたか。病院に池。
>>71
> いや無視はされない。現にこれの設定を妙にいじると問題が生じることがある。
> 特定の状況でATIのグラフィックドライバがエラーを出す。
それはLargeSystemCacheの話です。IoPageLockLimitは現在使われていない。
> ＸＰの場合、いわゆる「都市伝説」的なチューニングが蔓延してるからねぇ（苦笑
典型的な、「お前が言うな。」君です。
>>70
巨大ファイルのコピーをExplorerとかでやると、キャッシュ食い潰して
スラッシング状態に陥るから、UIのレスポンスとか極端に落ちる。
FireFileCopyやFastCopyはOS側のキャッシュを使わずにI/Oしてるから
「コピーしてる間はPC触らないから重くなってもいいよ」と言うのでない
限り、使うメリットは十分あるはずだけどね。
ちなみにStreamRipperでMP3ストリームを延々HDDに書いててもやはり
どんどんキャッシュを食い潰すので、CreateFile()の
FILE_FLAG_NO_BUFFERINGを使ったI/Oライブラリを使うように修正して
使ってる。多分FireFileCopyやFastCopyも同じ事をしてると思う。 >>73
> また、そんな前提を勝手に持ち出しましたか。病院に池。
勝手も何も最初からそういう話なんだよ。そもそも俺のしている話にレスをしてきたんだろ？
俺がなんの話をしているかどうかは俺が一番よく知ってるに決まってるだろう(笑
> それはLargeSystemCacheの話です。IoPageLockLimitは現在使われていない。
確かにそう書いてあるページがヒットするけどね〜。それは本質じゃない。
ATIのドライバが不具合を起こすのはPTE(Windowsのページ管理エントリ)が不足するため。
キャッシュも大量にページ管理エントリを消費するからLargeSystemCahceを0にしても
改善するだろうが、もともとはRadeonのドライバ自体が消費するからなわけで、
ドライバが使用するメモリを制限すれば(というかIoPageLockLimitを増やさなければ)
全体のエントリの不足も起きない。
あと繰り返しになるがIoPageLockLimitは使われている。ネットのあちこちでレジストリアクセスを
モニターするツールregmonを使ってもIoPageLockLimitが出てこないから、参照されていないんだ、
という主張があるけれど、regmon自体がドライバなのだから、IoPageLockLimitはregmonを
起動する以前に読み込まれていなければならない。簡単に言えばregmonではIoPageLockLimitを
モニターできない。
>>74
> スラッシング状態に陥るから、UIのレスポンスとか極端に落ちる。
それはファイルコピーのパフォーマンスとは別な問題。
いろいろごっちゃいにして都合のいい結論だけ強調してはいけない。
UIが遅くなるというのは否定しないが、それはチープなメモリでＸＰを
動かしているからだと思うよ？XPのメモリ管理はWin9xの頃よりも遙かに賢くなっていて、
際限なくファイルキャッシュにありったけの物理メモリをつぎ込むようなことはしない。
アプリによって頻繁に使用されているメモリはその状態でもメモリに置かれたままになっているはず。
もちろん優先度の問題だから、ＸＰがこのアプリのメモリは追い出してでもキャッシュを増やした方が
いいなと判断すれば追い出されるものもあるだろうが、そりゃ少ないメモリで動かしてるんだから
当たり前じゃん(笑
俺は2GB乗せてるけど大量のファイルをコピーしても遅くならないよ？(笑
1GBの頃でもパフォーマンス低下は感じなかったと思う。512MB以下だと微妙かもしれない。
> ちなみにStreamRipperでMP3ストリームを延々HDDに書いててもやはり
> どんどんキャッシュを食い潰すので、CreateFile()の
勘違いしている人が多いけどキャッシュが使用されることそれ自体は悪いことではないんだよ？
余ってるメモリなら使わなきゃ損なんだから。問題はアプリとかで有益に使用されている
メモリまで犠牲にしてキャッシュにメモリを割り当てるか否か。ＸＰはそのアプリがそれまで
どれぐらいCPUを使用してきたか等の統計情報からそのアプリの使用しているメモリを
メインメモリから追い出すか否かを決める。メモリが十分にあればユーザーが今現在
使用中のアプリのメモリがメインメモリから追い出されることはそうそうないと思うけどね。
あっやっぱIoPageLockLimitは使われているんだね。んー奥が深い。 >>77
長文乙。
メカ以外の誰がメカの脳内限定の話をできるんだい？
文章を書く際には相手に伝わらなければ意味がないんだけどな。
引きこもりのニートに言っても無駄だろうけどね。
ところでregmonでは完全な監視ができないってそれがどうしたの？
ETWやカーネルデバッガ使えばいいだけです。それで見つからない
んですから。
メカはさっさとIoPageLockLimitを使っている証拠を出してください。
値を呼んでいる関数名でもいいですし、memory managerの
どの初期化フェーズかでもいいです。 長文が続いてるんでずっと読み飛してたんだが、まだ続きそうですか？
今から読み直す価値はありますか？
というか何の話しをしてるんですか？
マジレス希望。
内心自分の書いていることに確信がないもの同士がお互いの腹の内を
さぐりあいながら切り抜けようとしている状態です。 >>82
いかにも2chにありそうな状態ですねぇ。
とすると>>83は煽ってるフリして情報を引き出そうとしているわけですか？ >>84
はいはい。お子様はしょうがないですね。
お前たちが情報を持っていない事なんてこっちはわかっているんですけどね。
Memory Managerのレジストリパラメータはnt!CmControlVectorという変数に格納されている。
ただしboot時のみ。
この内容を見たければカーネルデバッガでboot時にとめてメモリの内容を見ればいい。
全部手作業で見るのは面倒だから、
.for (r $t0=nt!CmControlVector;poi(@$t0)!=0;r $t0=@$t0+14){du poi(@$t0);du poi(@$t0+4);.echo}
とスクリプトを使えば一覧がでる。
当然、LargeSystemCacheは存在するがIoPageLockLimitは存在しない。 >>85
お前たちってことは俺も含まれてるってことですか。妄想がすぎるのも2ch特有ですね。
自分は>>81なんで何の話をしてるのやらさっぱり分りません。 >>86
俺は情報を引き出す必要がない。
下種の勘ぐりはやめろって事だ。 >>87
そうですか。自分は>>80以前は読んでないので>>82-83から推測しただけですが
そんな喧嘩腰になるような話をしていたんですか。
それとも、それが貴方の性格ですか。
>>88
馬鹿馬鹿しい。喧嘩腰と受け取るのはあなたの自由です。どうぞご自由に。
こちらは、あなたがろくに読まずに推測で他人を非難したにもかかわらず開き
直る救いようのない人間だと判断するまでです。
>>90
私は非難はしてませんよ。
>>82で
> お互いの腹の内をさぐりあいながら
と書いてあるのを信用しただけです。
>>85
> お子様
これに私が含まれるなら
> 推測で他人を非難した
これは貴方のことでしょう。 >>91
>>84が下種の勘ぐりだと言っているのです。わからないならわからないままでいいです。
これ以上はあなたの相手をする気がありませんから。
とりあえずあなたが私の事をどう思おうと自由ですが、これ以上粘着しないでください。
粘着するなとかもう相手にしませんという奴が
再び書き込む率が100%だと言う点について… >>21
> 今時書き込みでベリファイするHDDやファイルシステムはないだろう。
あるでしょ。
自分はMaxtorの6Y120L0を、ベリファイする設定にして、使ってるよ。
書き込み速度が遅くなるよ。
さらにWindowsのディスクのプロパティでライトバックキャッシュを切ったら、
それはもう悲しくなるくらい遅くなったよ。 >>44
> もちろんHDDに低レベルのコマンドを送ればライトバッファをフラッシュするとか無効にすることはできるよ。
> しかしそれは通常のアプリからは出来ない。そういうHDDにそういうコマンドを発行すれば一時的にせよ
> HDDのパフォーマンスが大幅に落ちるから、OSはそういうことを一介のアプリには許さない。
> OS上ではいろんなアプリが同時に動いているし、OSそのものもスワップファイルとかで使用しているわけで、
> 普通のアプリの都合でそれらのパフォーマンスを大幅に落とされてはたまらないからね。
Windowsの場合、管理者の権限のあるプロセスなら、ドライブにコマンドを送れると思う。
そういうことは、やらないほうがいい、というのは言うまでもないが。
そんなことをしなくても、Windowsは2000以降なら、
ドライブのプロパティで遅延書き込みをやめることができる。
そのプロパティの内容に従って、OSがドライブに適切なコマンドを発行する。
かなり昔に、WindowsNT4.0がドライブに送っているコマンドをモニタしたことがあるけど、
遅延書き込みを禁止するフラグを立てた書き込みコマンドが時々発行されていたので、
ファイルシステムで重要なものについては、書き込みに成功したことを確認しているのだと思う。 >>63
> あるアプリの都合でそのHDDのライトバッファを無効にするとかしたら、他のアプリに迷惑じゃん。
Windows2000 ServerからのActive Directoryのサービスは、
サービスの起動時に、↑のような操作をしてくれやがりますが、何か。
OS標準装備のサービスといっても、しょせんは1アプリなわけですが。 >>78
> 問題はアプリとかで有益に使用されている
> メモリまで犠牲にしてキャッシュにメモリを割り当てるか否か。
そういう説明が多くされているけれども、
メモリを1GB単位で積むようになった今では、
キャッシュの中でのメモリの取り合い合戦が問題になってる。
>>96を読み返したら誤解がありそうなので、補足。
> かなり昔に、WindowsNT4.0がドライブに送っているコマンドをモニタしたことがあるけど、
の話は、その前の段落に対しての補足ではなく、また別の話なので。 >>78
>それはファイルコピーのパフォーマンスとは別な問題。
I/Oのパフォーマンスとは別問題だと言うなら分かるけど、ファイルコピーの
パフォーマンスという大きな括りで言うなら全然別ではない。
>XPのメモリ管理はWin9xの頃よりも遙かに賢くなっていて、
>際限なくファイルキャッシュにありったけの物理メモリをつぎ込むようなことはしない。
いや、際限なく使いますがｗ
Explorerでファイルコピーしながらタスクマネージャー見てれば、空きメモリ
がどんどん減って残り数MBまで行くのが見れるでしょ。
>アプリによって頻繁に使用されているメモリはその状態でもメモリに置かれたままになっているはず。
XP以前は簡単に追い出されますがなｗ
>俺は2GB乗せてるけど大量のファイルをコピーしても遅くならないよ？(笑
うちも2GBだけど、4〜6GBくらいあるVirtualPCのイメージをExplorer使って
コピーなんかしたらイチコロだよ。こういう物理メモリに乗り切らないサイズ、
乗る場合でもキャッシュ内容を食い潰して欲しくない場合はFireFileCopyや
FastCopy、あるいはそれと同じ仕組みのI/O制御が必要になる。XP以前は。
>キャッシュが使用されることそれ自体は悪いことではないんだよ？
それは確かに。ただ載せる/載せないの判断を適切にやらないとひどい事に
なる。まぁOSからすればどれを載せていいのか、どれを載せちゃいけない
のかその場で判断するのは難しいので、SuperFetchでは統計取って判断
するようにしたわけだ。
>そのアプリがそれまでどれぐらいCPUを使用してきたか等の統計情報から
XP以前はそんなのやってない。XPに付いてるのはPrefetchだが、あれは
EXEのロード時間を短縮する仕組みでキャッシュ制御とは違う。
http://www.atmarkit.co.jp/fwin2k/xp_feature/016xpperftes02/xpperftes02_02.html 
