winsxs その３ [その他]
シリーズ第三弾？です（笑）
今回は、winsxsのハードリンクって効率的なの？
な、話題ですが、あまり検証してないので鵜呑みにはしないでください
どうにもあたしゃよーわからんのんですが、バックアップとりたいとか、互換性を維持したいとかいうのであれば、絶えずその実ファイルにアクセスさせる方が効率的なんでねーの？
Windows的には・・・と思うのです
Windows的には・・と言ったのは意味があって、そもそもWindowsのシステムファイルの管理って、レジストリでやってるわけじゃないですか、だったら、レジストリの値を変更する方が効率がいいんじゃないか？ってこと
バックアップはバックアップらしく名前変えて保存しなおせばいいんじゃない？
32bitと64bitでアクセスする先が違うのならば、それは寧ろレジストリが吸収すべき課題なんでねーの？
素人考えですが・・・
どうにも、winsxsは開発者側の（マイクロソフトの開発者）都合ばっかりが押し込められて、ユーザが割にあわんことを強要されているようにしか思えないのね
※開発者側の立場にたてば、
winsxsの管理手法は、開発上でのバージョン管理が楽になるし、
バグがあって元に戻したい時はリンクを変えるだけですみ、
Windowsの使いにくいレジストリという名前のデータベースをちまちまさわらなくて済むし、
そのバグが原因でレジストリを破壊しシステムが停止するという最悪の事態を回避できー
おかげで開発効率がややUP？
な良いことずくめ・・・に思える
それから、winsxsのハードリンクって絶えず８万弱のファイルがリンクされてるのだがー
NTFSはデフォルトではディスク上の最小単位は4KB（たとえ１バイトのファイルだったとしても、ディスク上最低4KBは必要って意味）
※所謂クラスタサイズ、もしくはアロケーションユニットサイズがデフォルトで４KBって意味です。ハードリンクつったって実態は１ファイルだから、最低4KBは消費するよね？？
すると、 こういう計算が成り立ちます
8万×４KB÷1024＝312.5MB
あー、マイクロソフトがwinsxsの実態は３～４００MB程度ですって言ってるけど、この事が言いたかったのかー、等と思ったさー
つまり、ハードリンクみたいな余計な事をしたせいで、３～４００MBディスクを余計に消費してるってこと
これ、結構でかいよね？＾＾；；
てか、８万ファイルってなんじゃそりゃって感じ。。。
いくらFATより効率的になったNTFSだからって、８万ファイルにアクセスするI/O処理にかかる時間は洒落にならんぜよ
XPに比較して、Vistaや7が重たいのって、このあたりに理由がありそうな気がするんだよなー、個人的所感ですが。。。
あと、某なんたらサーチ4.0が遅いのってwinsxsのせいだったら笑っちゃうね
続いて、最近更に色々やって、Cドライブの容量、２０GBまで空きを確保しました
あの後なにやったんだっけな？＾＾；
あー、そうだ、下位バージョンが残っちゃう、Javaを全部一端アンインストールして、最新バージョンをだけをインストールしなおした
それから、Cドライブ以外でも動作するアプリはアンインストールして、他のドライブにお引っ越し
OS付属のデフラグツールは、実は無用の長物ってことが分かったので、
PerfectDiskを試しました
思いの外結果が良好だったので、５ライセンス購入しました
等々やって、容量確保したのだわ＾＾；
※これらの作業結果、復元ポイントが多数作成されたので、ディスクの空き容量は一度２GBを切りました、、、
が、復元ポイントを削除、PerfectDiskを使ってデフラグすることでなんと２１GBまで空き容量が増えたののさー
でもね、一度でもMicrosoftUPDATEをやると一気に１０GB減るの。なんでやねん
しかし・・何やってんだ、オレは（汗）
何故にOSごときの為に毎日こんなアホな作業せなあかんねん
蛇足：
えっと、まだ未確認情報なのですが、Vista、Windows7はディスクの残容量が０バイトとなった場合、そのパーティションを２度と認識しなくなるらしいです
つまりwinsxsとかのせいでCドライブの残容量が０になった瞬間OSは落ちて二度と起動しませんし回復もできなくなる・・らしいと・・・
これまた未確認情報ですが、WindowsXPならば０バイトでも認識するらしいです（winsxsを使ってないから？？）
うわー、本当ならまるで時限爆弾じゃん（笑）＜もう笑うしか・・・
ディスカバリーチャンネルの怪しい伝説に検証を依頼してみようか？＜を（爆）
注意） 蛇足以降の文章について当方では2009年11月7日現在確証を得てません
間違ってたらごめんなさい
また、もしこれ読んで試した結果生じた損害などについて当方は何も補償などできませんし、ご相談にのることもできません
試したいなら自己責任でやってね＾＾；
あくせす解析
ブログ村
あるかな
こんにちは。
検索でたまたま見つけたので、ちょっと突っ込みさせてもらいます～。
> 絶えずその実ファイルにアクセスさせる方が効率的なんでねーの？
ハードリンクというのは実ファイルと全く同じ物です。
いわゆる普通のファイルは「ハードリンクの数が1のファイル」なんですよ。
> 32bitと64bitでアクセスする先が違うのならば、それは寧ろレジストリが吸収すべき課題なんでねーの？
これはwinsxsとは直接関係ない話ですね。
（SysWOW64と混同してる？）
> ハードリンクつったって実態は１ファイルだから、最低4KBは消費するよね？？
しません。
普通のファイルだって0バイトなら、消費しない。
さらに、NTFSは小さなファイルの場合はデータをMFTに格納することができるから、
1バイトのファイルが必ず4KB占有するというのももはや成り立たなくなってます。
> いくらFATより効率的になったNTFSだからって、
> ８万ファイルにアクセスするI/O処理にかかる時間は洒落にならんぜよ
一度に必要なのは8万ファイルのうちの一部でしょうから、
その心配はないでしょう。
by Neruneru (2010-02-09 20:23)
Neruneruさん、細かいご指摘ありがとうございます
＞（SysWOW64と混同してる？）
あえて、混同して”意見”を主張してます
だって、MACは32bitと64bitの共存がうまくいってるのに（ハードがサポートしてんだから当然）
Windowsってば、ハードのサポートを無視して、大昔16bitから32bitに移行したWindows95と全く同じテクノロジーを使ってるんですもの
せっかくのAMD64がこれでは全く生かされてません
＞普通のファイルだって0バイトなら、消費しない。
エクスプローラーでみると０バイトじゃないですよね
だから、OSは０バイトと認識してないと思われます
（これは推測）
実際、ハードリンクと全体のディスク消費量をみたとき、どう計算したって、ハードリンク分だけ二重計上されているのだから、これはMSは仕様だって言い張る前に素直にバグと認めて修正すべき事だと思います
＞一度に必要なのは8万ファイルのうちの一部でしょうから、
インデックス（NTFSレベル）やジャーナリングを行っているわけですから、アイオーには相当負荷がかかっていると思います
実際、Windowsの性能的な欠点って、CPUマターじゃなくて、アイオーマターですよね
サーバーとかで何度も計測して、Windowsはアイオーが弱いことは経験則として知ってるので、この見解は変わりません
つまるところ、なんつーか、MSって技術力弱いと思うのです
SQLサーバーにしても、性能がでなかったら、おまえの使い方が悪いよばわりですよ（サポートに何十万って払って得た回答がそれです：某大手企業のシステムで）
日本人を人間と思ってないMS社の姿勢そのものに最近疑問を抱いてます
by うっちー (2010-02-09 23:01)
技術の話は結構好きだけど、
Microsoftの姿勢とかにはあまり興味はなかったりします。ごめんなさいね。
（でも批判はするべき所に対してはちゃんとする方がいいとは思うよ～。
そのサポートは確かにひどいし＾＾；）
>>（SysWOW64と混同してる？）
> あえて、混同して”意見”を主張してます
> だって、MACは32bitと64bitの共存がうまくいってるのに（ハードがサポートしてんだから当然）
> Windowsってば、ハードのサポートを無視して、大昔16bitから32bitに移行したWindows95と全く同じテクノロジーを使ってるんですもの
批判対象は32ビット/64ビットドライバの互換性かな？
Windows95と全く同じテクノロジーのところは、
もうちょっと具体的な話がないとどれのことかよく分からないです。
（サンクのことかと思ったけど、サンクに近いことしてるのはどちらかというとMac OS Xのほうだった。）
私がしっている限りでは、16bit/32bitの時よりも、
WOW64での32bit/64bit間の壁は大きいです。
16bit/32bitの時は、
32ビットコードから16ビットDLLを呼び出したりその逆ができていました。
しかし、32bit/64bitでは64ビットコードから32ビットDLLを呼び出したりはできません。
ドライバ周りについても16bit→32bitの時と違って、
従来の32ビットドライバは使えなくなっています。
> せっかくのAMD64がこれでは全く生かされてません
64bit/32bitプログラムの混在を考慮したAMD64を利用するための仕組みがWOW64なのですが、
生きてないとは例えばどの点かな？
なお、Macで32ビットドライバが使えるのは、
デフォルトではカーネルを32ビットで動かしているからです。
64bitカーネルのパフォーマンスと引き替えに、互換性を取る選択をしたようですね。
（64bitカーネルに切り替えることもできるので、
64ビットドライバが普及するにつれて、徐々に置き換わると思います。）
> インデックス（NTFSレベル）やジャーナリングを行っているわけですから、
> アイオーには相当負荷がかかっていると思います
Windows Searchとかの話ではなく、
ファイルシステムレベルの話ですよね。
ジャーナリングに関しては、ファイル数に比例して
IO負荷が増える事は無いです。
インデックスは影響がないとは言い切れないですが、
あったとしても軽微でしょう。
あと、8万ファイルというのは、
パフォーマンスへのインパクトを与えるには数が少ない気がします
（私は数100万ファイルくらい
システムドライブに保存していたことがありますが、
特に遅くなったとは感じなかったです。）
>> 普通のファイルだって0バイトなら、消費しない。
> エクスプローラーでみると０バイトじゃないですよね
> だから、OSは０バイトと認識してないと思われます
普通の0バイトのファイルはエクスプローラで見ても0バイトですよ？
（ファイル名などがMFTに格納されるから実際は少し消費するというご指摘なら
その通りなのですが、そういう意味じゃないですよね。）
ハードリンクが0バイトでないと言うことかな？もしそうであれば、それは当然です。
前回のコメントで言ったとおり、ハードリンクは
普通のファイルと同じ物なのでファイルサイズも普通のファイルと同じように確認できます。
> 実際、ハードリンクと全体のディスク消費量をみたとき、
> どう計算したって、ハードリンク分だけ二重計上されているのだから、
エクスプローラで複数ファイルを選択して表示したプロパティのファイルサイズは
ハードリンクなど識別せずファイルサイズの和を表示しているだけなので
ディスク消費量と直接の関係はないです。
（前回言ったとおり、ハードリンクというのは
実ファイルと全く同じ物なので基本的に区別できないし、エクスプローラも区別しない。）
例えば、NTFSの2GBボリュームに
1GBのファイル1個が格納されているとします。
この1GBのファイルに対してハードリンクを
例えば10くらい張ってもボリュームの使用容量はあふれたりはしません。
このとき「ボリュームのプロパティ」を見れば使用領域には
1GBより少し多い値が表示されるでしょう。
対して、「ボリューム内の全ファイルを選択して表示したプロパティ」では
合計サイズは単純な合算である10GBと表示されるでしょう。
（これは実際に試してます。ハードリンク作るのはそう難しくないので試して見るといいよ～。）
余談ですが、エクスプローラはディレクトリにマウントしたボリューム内のファイルも合計サイズに含めるため、
マウントボリュームを含んでいる場合も、
ボリュームの使用容量と、ボリューム下ファイルの合計サイズが大きく食い違う現象が起こります。
他にも、アクセス権のないファイル・ディレクトリのファイルサイズは取得出来ないために、
ディスクを消費しているファイルを確認できないこともあります。
（"System Volume Information"はデフォルトでアクセス権がない上に、
システムの復元データが入っているので、見えないディスク消費の原因になっていることが多いです。）
> CPUマターじゃなくて、アイオーマターですよね
プロセッサよりIOがボトルネックになりやすいというのは私も感じますね。
> サーバーとかで何度も計測して、Windowsはアイオーが弱いことは経験則として知ってるので、
個人的には、Windowsはディスクキャッシュの扱いが下手な気がしてます。
あと、Windowsって同じ処理を複数回実行すると、
同じ処理なのにたまに処理時間が大きく伸びるという
嫌な挙動を示したりしますね＾＾；
Linuxは割と安定した処理時間になるのですが。
以上、参考になれば幸いですm(_ _)m
by Neruneru (2010-02-19 02:38)
Neruneruさん、コメントありがとです
色々参考になる情報、勉強になりました
by うっちー (2010-02-20 07:23)