【デフラグ】 Contig - 暇つぶし2ch

【デフラグ】 Contig ..

183:名無しさん＠お腹いっぱい。
06/04/07 22:03:03 CVardCyc0
03/27にも来てるよ

184:名無しさん＠お腹いっぱい。
06/04/07 23:01:00 Rb1d9xop0
>>183
さっき落としたら２４日だったから、２７日版には
何か不具合があったのか？

185:名無しさん＠お腹いっぱい。
06/04/07 23:05:04 CVardCyc0
>>184
＞Last Updated: March 27, 2006 v1.53
いま、どう見てもこう↑なってるよ

ちなみに、うちで持ってる本体(V1.53)
CRC32　5bfc2f89
MD5　23623fb3b2fc31f0b00d21b58899e25e
SHA-1　dc7e045516e4565296c7ce8e3b98555e5b288c24

186:名無しさん＠お腹いっぱい。
06/04/07 23:41:38 Rb1d9xop0
>>185
Contig.exe 69,632 2006-03-24 12:33:48

187:名無しさん＠お腹いっぱい。
06/04/09 15:55:26 4rSDhWux0
BUZZSAW and DIRMSがｖ2.1になってるね

188:名無しさん＠お腹いっぱい。
06/04/09 17:29:13 7PJQO8x40
>>187
DirMS-CL Download は The page cannot be found だ・・・
DirMS-S Download は落とせるけど DirMS-S.msi になっちゃった・・・

189:名無しさん＠お腹いっぱい。
06/04/10 20:11:01 iUQ6gtir0
三つとも全部落とせたよ
久しぶりにdirmsのページ見たけどBuzzsaw無料になったのかな？>>64に書いてある通りって事でOKかな。

190:路伯 ◆a.0e5YxqBY
06/04/11 18:53:30 9IiSCPii0
Buzzsawはもともと個人用なら無料じゃなかったか？

--

Buzzsaw-Sは使えるねぇ。サービスとして動いているのがいい。

191:路伯 ◆a.0e5YxqBY
06/04/14 20:20:56 L/oZO6rd0
保守

192:名無しさん＠お腹いっぱい。
06/04/18 19:50:11 iuOol1EgP
フォルダのでフラグって、XP標準のデフラグ
(Diskeeper のしょぼい奴)ではやってくれないですか？

193:名無しさん＠お腹いっぱい。
06/04/18 19:52:10 iuOol1EgP
そういや NTDefrag っていうソフト無かった？

194:名無しさん＠お腹いっぱい。
06/04/19 08:52:23 9gJmS+HD0
>>192
やってくれません。

>>193
NTDEFRAGならここ
URLﾘﾝｸ(pot-pourri.fltr.ucl.ac.be)
URLﾘﾝｸ(pot-pourri.fltr.ucl.ac.be)
※sysinternalの人が前作ってたもの。1M超あるのでcontigとは不連続か。

DefragNTならスレ内参照

195:名無しさん＠お腹いっぱい。
06/04/19 09:10:11 kQehjso+P
>>192
やってくれません。

ってことは、Contig の方がいいね。

196:名無しさん＠お腹いっぱい。
06/04/19 10:01:14 3+hVXTLB0
>>195
Contig も、フォルダデフラグはやってくれないと思う・・・

197:名無しさん＠お腹いっぱい。
06/04/19 11:09:09 kQehjso+P
>>6 を読んで期待した

198:名無しさん＠お腹いっぱい。
06/04/19 11:30:59 3+hVXTLB0
>>197
あら、知らなかった。
２０００も駄目だね。

199:路伯 ◆a.0e5YxqBY
06/04/19 12:32:02 sDqisEgk0
>>196

ContigをNT4で動かすと、フォルダのデフラグをやらないけれど、XP上ではフォルダの
デフラグをこなす。

ただ、「contig * -s」とやったときに確認したことがあるだけなので、「contig hogehoge」で
hogehogeフォルダをデフラグできるかどうかはわからない。

200:名無しさん＠お腹いっぱい。
06/04/19 15:15:37 xMXr6asFP
NTFSなら標準のデフラグでもやってくれるがな

201:名無しさん＠お腹いっぱい。
06/04/19 16:17:51 p/q32rBd0
>>200
だよね。

ちなみに、FAT のディレクトリがオンラインデフラグできないのは、
OS 側の仕様なので、どんなに優秀なデフラグでも無理。
同様に、MFT のオンラインデフラグは、XP なら可能、2000 以前は不可能。

202:路伯 ◆a.0e5YxqBY
06/04/19 18:48:29 sDqisEgk0
Contigの価値は、特定のファイルや、特定のファイルタイプだけを
デフラグでき、既に断片化が解消されているファイルを動かさないことにある。

ソフトをインストールした後に、まず、「contig \*.exe -s」「contig \*.dll -s」を実行してから、
「contig \* -s」とやるといいと思っている。

BuzzSaw-Sと併用するとしたら、

1) BuzzSawService.exeを止める
2) 新しくソフトをインストールする
3) contig \*.exe -s
4) contig \*.dll -s
5) contig \* -s
6) BuzzSawService.exeを再起動する

というのはどうだろうか？

203:名無しさん＠お腹いっぱい。
06/04/21 01:30:42 z+rt0JBH0
>>202
>ソフトをインストールした後に、まず、「contig \*.exe -s」「contig \*.dll -s」を実行してから、
>「contig \* -s」とやるといいと思っている。

このへんがよく分からないのでなんとも…

204:名無しさん＠お腹いっぱい。
06/04/21 02:05:50 z+rt0JBH0
DirMS-CL 2.1.1における主な変更点を分かったことだけ列挙

・フル機能で使うには30日毎の無料登録が必要　※制限内容不明
URLﾘﾝｸ(www.dirms.com)
URLﾘﾝｸ(www.dirms.com)

・ジャンクションを適切に処理
URLﾘﾝｸ(www.dirms.com)
・MFT,pagefile以外の全てをデフラグ可能
URLﾘﾝｸ(www.dirms.com)

・指定ファイルのデフラグ機能復活，ログ生成など，モードとオプション追加　※指定ファイルの先頭移動も？
URLﾘﾝｸ(www.dirms.com)

205:名無しさん＠お腹いっぱい。
06/04/22 16:41:07 jSHXYQCW0
新しいＤｉｒＭＳ、早速試してみました。
ＮＴＦＳドライブで、他のツールだと、どうしても、断片化しないままで
前の方に詰めてくれなかったのですが、デフォルトより一つパスを
増やして、いい感じで詰めてくれました。
現在、もう一つ増やして４パスで実行中。
これで、さっきより良い結果が出てくれれば・・・

206:名無しさん＠お腹いっぱい。
06/04/25 18:55:05 mcb1c3g40
Contigでデフラグした場合とPerfectDiskでデフラグした場合の比較（P.Dの機能で分析）

Contigでのデフラグ前
ボリュームの健全性
エンティティステータス断片化率(%)数過剰な断片化
ファイルの断片化良好215043793
ディレクトリの断片化警告143934100

エンティティステータスサイズ過剰な断片化
連続した最大空き容量良好21.31 GB
MFT の断片化良好94.0 MB0
Metadata警告66.5 MB84
ページファイルの断片化注意1.02 GB1

ファイル最適化の結果
ファイルタイプ数MB割合(%)
書換え頻度が低いファイル6644813229.9 MB23 %
書換え頻度が中のファイル18312054.0 MB4 %
書換え頻度が高いファイル238033990.8 MB7 %
ディレクトリ280524.3 MB0 %
ブート1336392.3 MB1 %
除外ファイル81602.6 MB3 %
MFT 予約領域以外の空き領域N/A28841.9 MB50 %
MFT 予約領域内の空き領域N/A7059.0 MB12 %
___________________________________________________
合計9623157194.8 MB100 %

207:名無しさん＠お腹いっぱい。
06/04/25 18:57:17 mcb1c3g40
Contigでデフラグ後

ボリュームの健全性
エンティティステータス断片化率(%)数過剰な断片化
ファイルの断片化良好074213
ディレクトリの断片化良好048

エンティティステータスサイズ過剰な断片化
連続した最大空き容量良好21.31 GB
MFT の断片化良好94.1 MB0
Metadata警告66.5 MB84
ページファイルの断片化注意1.02 GB1

ファイル最適化の結果
ファイルタイプ数MB割合(%)
書換え頻度が低いファイル6644813229.9 MB23 %
書換え頻度が中のファイル18332054.2 MB4 %
書換え頻度が高いファイル238393990.9 MB7 %
ディレクトリ280524.4 MB0 %
ブート1336392.5 MB1 %
除外ファイル81602.6 MB3 %
MFT 予約領域以外の空き領域N/A28841.3 MB50 %
MFT 予約領域内の空き領域N/A7058.9 MB12 %
___________________________________________________
合計9626957194.7 MB100 %

208:名無しさん＠お腹いっぱい。
06/04/25 19:15:32 mcb1c3g40
って、PerfectDiskが出力するファイルがリッチテキストドキュメントなの忘れてたorz
コピペじゃ崩れまくりで見にくいじゃねーかorz

面倒なのでファイルうｐ

URLﾘﾝｸ(www.uploda.org)
Passは設定してないよ

まずすぐ解るのが、Contigがメタデータを最適化してくれない事かな。
その他の断片化やファイルのつめ方、ブートファイルの扱いも全てPerfectDiskのが上ですね。
つーかシェアだし、Contigが詰めないのは仕様だけど。

209:名無しさん＠お腹いっぱい。
06/04/25 19:40:36 mcb1c3g40
うどん4人前を一人で食ったら死にそうな件。
なんか膨らんできてねーかこれorz

210:名無しさん＠お腹いっぱい。
06/04/25 19:42:50 f4Oc1VJQ0
そんなこと言われても

211:名無しさん＠お腹いっぱい。
06/04/25 21:02:06 WYUtOwmr0
腹の中デフラグすりゃいいじゃん

212:路伯 ◆a.0e5YxqBY
06/04/26 00:06:00 o2zS1UlH0
>>208

Contigの長所はまさにその「詰めない」ところ。

方向性が違うんだよ。

213:名無しさん＠お腹いっぱい。
06/04/26 00:15:47 jEeK/l5j0
>>212
それは承知しとりますです。
あとデフラグ中の軽さもですな

214:名無しさん＠お腹いっぱい。
06/04/26 01:01:15 1KScp/ch0
詰めなくてもいいから、一旦全てのファイルを連続にしてから、
途中の空き領域容量と、其処にピッタリ填まる、
其処より後ろのファイルを教えてくれないかなぁ・・・

215:名無しさん＠お腹いっぱい。
06/04/26 20:39:02 te12yu5I0
それそれ。>>214
闇雲に詰めるﾔﾂは堪らん。

あと、BOOTファイルの再配置も標準のRundll32 advapi32.dll,ProcessIdleTasksの方が
僅かながら良い結果が出てる。(当環境では)

で、今のところContig＋DiskeeperLiteが妥協点。
オフラインデフラグには仕方無くPD。

216:名無しさん＠お腹いっぱい。
06/04/26 22:01:27 1KScp/ch0
>>215
「Rundll32 advapi32.dll,ProcessIdleTasks」て何？
ちょっと実行を躊躇ってしまう。

217:名無しさん＠お腹いっぱい。
06/04/26 22:09:07 Fw86nXFA0
ぐぐれよ

218:名無しさん＠お腹いっぱい。
06/04/26 23:40:39 Wnq7HP8t0
ぐぐれば快適なディスク環境を返していただけるんですね？

219:路伯 ◆a.0e5YxqBY
06/04/30 22:45:57 vo/SUgBz0
保守

220:名無しさん＠お腹いっぱい。
06/05/02 00:06:35 Krf8f/VC0
contigっていいソフトだね
送るにショートカットを作っていい感じにデフラグしてる

221:名無しさん＠お腹いっぱい。
06/05/02 10:01:39 bJwmpgMM0
ディスクの先頭から順番に空き領域をスキャンし、
その部分に丁度収まるファイルをそれ以降の部分から全部見つけて
「どれを移動しますか？」って聞いてくれるソフトが欲しい。

222:名無しさん＠お腹いっぱい。
06/05/08 15:16:25 2QWHQkJ20
そして

223:名無しさん＠お腹いっぱい。
06/05/08 16:13:34 ZMn5MjR6O
電設へ

224:名無しさん＠お腹いっぱい。
06/05/08 16:28:40 Kks8D5MJ0
>>223
ちょｗｗｗｗｗ

225:名無しさん＠お腹いっぱい。
06/05/08 21:36:29 2QWHQkJ20
そうきたか。

226:名無しさん＠お腹いっぱい。
06/05/09 05:38:45 sp90g4bT0
部屋でタバコを吸う人と吸わない人では、hddの寿命が、倍ぐらい違うらしいね

227:名無しさん＠お腹いっぱい。
06/05/09 20:27:25 2CmATz2v0
仕方ないな。
HDDのためならタバコ吸ってやるか。

228:名無しさん＠お腹いっぱい。
06/05/09 21:03:43 TkIVJMVH0
>>226
タバコを吸う方がHDDが倍長生きするんだよな。
非喫煙者は無駄にHDDの寿命を縮めている。

229:名無しさん＠お腹いっぱい。
06/05/09 21:21:39 BqiSINsv0
喫煙環境でのボリュームとかスライド接点の短命化は異常

230:名無しさん＠お腹いっぱい。
06/05/09 21:46:21 AIcgeKXp0
タバコだのデフラグだのお前ら50歩鼻くそだっつーの

231:名無しさん＠お腹いっぱい。
06/05/09 22:10:29 iJvoiRTQ0

　　　　　 _ノ~　　　　　＼,r‐''￣~`ｰく　　＼
　　　　 _／￣~7　　　　　　　　　＞　　　　　ヽ､　　ヽ
　　,.-‐'　　　　l　 /~　　　　_,.-イ　　　｀ヾ　ｰ-､｀'' ￣ヽ
　/　　　　　　人fﾆ"~　__／　　 |￣　ﾞｰ-､　　ヾ.　　　）
　|　　,.r'"~￣`tn.jｰ‐r――‐'　　　　　ヽ　　　　　 /
　ヽ／ (　 /ノ　　｢ヾ'　　∧　　　　　　　　　＼　　　く
　/　　　ヾ.　　　/U ｀i　ﾉ　＼　　　　　　　　　ヽ　　,ｨﾊ
く　　　　　　　 /　　　| .|'　　ﾞi　､　　　　　　　　i　.f'ﾞ='
　＼　　　　　/　　　 _|/　　　 |　ﾄ､　＼　　　　ﾄﾊ　,!　　　　　　　
　　　`ｰ-､__/ー'Tﾌ~| l!　　　　＼ヽヽ.　＼　　ﾄヾ,ハ.　　　　　　　
　　　　　　.｣　 r'"'　!l |,_,_,,,_,__..　＼ﾞ､＼:､､ゞヽ,,;ﾞト i|　　　　　（
　　　　　 i'~ゝ､!　　,ｲﾉ''''''''''''''''`　ヽゝ　,ｨ‐r=ｯ　　ﾚ'ﾘ　　　）　　　　( 　　　　　
　　　　　ヽi r'j !　　" _,;;rr=ｪｯ､　　　　'~`ﾞ'ﾞ`｀　　:| i'　　　（　(　　　　）　　　　　
　　　　　　ﾞi ヽり,　　　 '~´`´´｀　　　::.　　　　　　 r'　　　　ヽヽ　　ﾉ　　　　
　　　　　　＼从　　　　　　　　　　　　　　　　　|　　　　　　）　）)
　　　　　　　　ﾞｰ'ﾍ　　　　　　　　_.　_.　　　　　　|　　　　　（,, （
　　　　　　　　　　ヽ　　　　　　　　_,,...-''＿＿＿|＿＿＿＿_）　　　　おまいら、たばこくらいで騒ぐなよ。　　　　　　　
　　　　　　　　　　 ,ハ.　　　　　　／ :;;;;;;;;;;;（　　　　　　　　　((;;）.
　　　　　　　　　ノ　　＼　　　　｀ﾞー￣￣￣￣/￣￣￣￣
　　　　　　　／　　　　　`ｧ:.._　　　　　　　ノ / / |　　ヽ
　　　　　　ﾉ　　　　　　＼:.ヾ‐-:::...-‐'"　/　|　|　　　　＼

232:名無しさん＠お腹いっぱい。
06/05/09 23:38:41 wdZoviXMO
今日のことわざ

50歩鼻糞を笑う

233:デフラグさん ◆mRgSYalFkQ
06/05/09 23:41:14 8s4JSCLe0

　 [ﾟдﾟ]　ﾃﾞﾌﾗｸﾞｶﾝﾘｮｳ
　/[＿]ｂ
　　|　|
05うこざとのわを今笑日鼻糞歩

234:名無しさん＠お腹いっぱい。
06/05/10 09:29:38 RSWoHrAt0
マジレスすると、レンズがデリケートな光学ドライブならともかく、
密閉されてる HDD の場合、タバコの煙はあんま関係ない気がする。

235:名無しさん＠お腹いっぱい。
06/05/10 09:33:09 L3wPpHIG0
密閉されてないよ
関係あるかどうかは知らないが

236:名無しさん＠お腹いっぱい。
06/05/10 10:01:42 oPZBC/0R0
煙草は、ＨＤよりも身体の方に悪いと思うが。

237:名無しさん＠お腹いっぱい。
06/05/10 14:49:59 oi40GUaw0
ドライブ見てみ
穴開いてるから
フィルター経由で空気の出入りがある

238:名無しさん＠お腹いっぱい。
06/05/10 16:41:10 NbA/DyK70
泉重千代の長生きの秘訣は毎日の喫煙

239:名無しさん＠お腹いっぱい。
06/05/10 23:04:48 ns3cVKf1O
あり得ねー

240:名無しさん＠お腹いっぱい。
06/05/16 10:16:03 YQyvcbOM0
結局，バージョンアップした contig , dirms , buzzsaw は特に使用感
に変化なしってこと？

241:名無しさん＠お腹いっぱい。
06/05/16 11:41:23 Q/8PLS6D0
>>240
dirms に関しては、オプションは増えたみたいだけど、
大して変わりはないね。

242:名無しさん＠お腹いっぱい。
06/05/19 22:50:35 mK3zVRkX0
そうか。遅くなったけど，ありがとう。

243:名無しさん＠お腹いっぱい。
06/05/20 00:26:09 ohjyYWt60
dirms-CLは、コマンドプロンプトからレジストレーション情報をコピーしてWebSiteのフォームに貼る時に、コマンドプロンプトの画面幅(80文字毎)の改行は消しておかないと、invalid codeになってしまうね。気をつけないと。

244:名無しさん＠お腹いっぱい。
06/05/20 22:58:34 ECG42ex+0
　

245:名無しさん＠お腹いっぱい。
06/05/20 23:56:58 TRyaDD+/0
>>208
亀だけど乙。
contigって意外とキチッと最適化してくれるんだね。
俺は時間が有る時たまにDiskeeperで、PC使用中とかは重くならないcontigって感じだ。

ところで今悩んでるんだが、Bootvisと相性の良いデフラグソフトって何だろう？
それとTuneXPのブートファイルデフラグ。
ブートファイルデフラグはブートファイルを先頭に持ってくるからPDは却下かな。
デフラグだけならcontigでも良いからまずとして、bootvisとTuneXpのっちを先に実行すればよいのか・・・？

っと、これ以上はスレ違いだな

246:路伯 ◆a.0e5YxqBY
06/05/21 16:26:33 ob4Dg+lF0
>>245

そんなあなたには、コマンドプロンプトから、

Rundll32 advapi32.dll,ProcessIdleTasks

これで、起動時の読み込み順にファイルが並ぶはず。

247:名無しさん＠お腹いっぱい。
06/05/21 16:32:13 b+FvxJI90
>>246
ｍｊｄ？
やってみる

248:名無しさん＠お腹いっぱい。
06/05/22 08:01:38 8ZiC6ORc0
よけいなお世話だけど，TuneXPは，使用後にMFT 予約領域が消失した
という報告もあるので，気をつけた方がいいよ。
URLﾘﾝｸ(denshizuno.at.webry.info)

249:名無しさん＠お腹いっぱい。
06/05/22 18:34:57 G+DZxVkU0
>>248
そこの人、セクタの割り当て順について激しく勘違いしてるな。
プラッタやヘッドが複数あろうが、シリンダ番号より先にヘッド番号が進むから、
外周部分が複数あるなんてことはない。
そもそも、複数の面で同一位置にあるトラックが円筒状になるのでシリンダというわけで。

今は外から見える CHS は仮想的なものだから内部的にどうなってるかは不明だけど、
わざわざシークタイム的に不利になる、面を先に使い切るようなことしてるとは思えん。

250:名無しさん＠お腹いっぱい。
06/05/22 19:05:45 xV/RkEU80
>>249
> 1. うちのマシンのCドライブには、ハードディスクの外周部分が複数ある。

久々に心の底から笑えるネタに出会った。

そのサイトの著者はどうやら1枚目のプラッタを使い切ってから2枚目以降を使うと思い込んでいるようですな。
だからすべての推測が間違った方向にいってしまっている。

MFT予約領域については、それはあくまで「予約」であり、予約領域の量は何かと変動するからね。
たとえばPerfectDiskのオフラインデフラグをかけても変化する。

もともとMFTが伸張された場合にそれがフラグメントを起こさないように開けてある領域だから、
ディスクにデータが埋まっていき、空き領域が減ってけば、予約領域は減らしていく方がいいという
判断なんだろうね。空き領域が減るということは、新たに書き込まれるデータが減るということで、
そのために予約しておく領域も少なくていい、と。

251:名無しさん＠お腹いっぱい。
06/05/22 19:07:04 +H0Lo4Dz0
必要なサイズぶん実際のMFTを確保したら予約領域なんか無くしてしまう方がいい

252:名無しさん＠お腹いっぱい。
06/05/22 19:10:56 xV/RkEU80
で、肝心のTuneXPについては…再配置機能は使わない方がいいと思うね。
そのサイトの著者も語っているように、デフラグソフトとの相性が悪い。

PerfectDiskにもブートに使用するファイルを先頭に連続して配置する機能があるが、
PerfectDiskの場合Windows本体のプリフェッチ機能と上手く共存させている。
しかしTuneXPの場合何も対策をしていないので、TuneXPをかけてもその後
デフラグするとまた配置が換わり、意味がなくなってしまう。

TuneXPの他の機能はいいと思うが、ファイルの配置機能は使うべきではない。

253:名無しさん＠お腹いっぱい。
06/05/22 19:58:54 lP97GC9J0
以前は、何としても全てのファイルを連続にして前に詰めてたけど、
最近は、連続にさえなってればいいや、って思う様になった。

254:名無しさん＠お腹いっぱい。
06/05/23 05:47:11 XA2opbUr0
>>245
> ところで今悩んでるんだが、Bootvisと相性の良いデフラグソフトって何だろう？
> それとTuneXPのブートファイルデフラグ。
> ブートファイルデフラグはブートファイルを先頭に持ってくるからPDは却下かな。

PDってPerfectDiskの事だと思うが、なぜPerfectDiskが却下なのか理解に苦しむ。
PerfectDiskはBootvisが作成した情報に従って、ブートに必要なファイルを先頭に配置する。

この機能があるのはPerfectDiskだけだ。Bootvisともっとも相性のいいソフトといえよう。
Bootvisをかけた後に、PerfectDiskで配置し直すという使い方になるけどね。

255:名無しさん＠お腹いっぱい。
06/05/23 22:05:36 dR6KbHpN0
>>249
ああ，言われてみると確かにおかしなことになってるね。その辺読んでなかったから気づか
なかった。ところで，CHSってLBAに変換してるケースも含めて今ではほとんど使われてない
のかと思ってたけど，そうでもないの？

256:名無しさん＠お腹いっぱい。
06/05/23 22:11:09 dR6KbHpN0
MFT予約領域については，データが増えたとしても積極的に減らすべきじゃないと思う。

まず，予約領域は，ディスクが最大容量に達した後はファイルの記録に消費されるので，事
前に減らす必要がなさそう。

それに，MFTは，小さなファイルについてはデータを直接格納し，その場合はMFT単独で肥大
するので，「ディスク内の空き領域が減ればMFT予約領域の必要性も比例的に減る」わけで
はない。さらに，ファイルが削除されてもMFTのサイズは小さくならないから，ディスクが
埋まってきていったん予約領域が減らされた後にファイルが削除された場合，ディスクに十
分な空きがあるのにMFTの予約領域はほとんどないという状況になってしまう。

なので，ディスクが埋まってきたとしても，予約領域を積極的に減らすとMFTの断片化を招
く可能性が増える。

と，思う。

257:名無しさん＠お腹いっぱい。
06/05/23 22:22:21 EGzjXPVa0
>>256
>>251

258:名無しさん＠お腹いっぱい。
06/05/23 22:43:38 SbeKGi1O0
皆ＮＴＦＳが好きだね。
私はＦＡＴ３２派。
９ｘのノートンＳＤでデフラグ出来るし。

259:名無しさん＠お腹いっぱい。
06/05/24 01:04:01 fG6yQZvH0
>>256
> まず，予約領域は，ディスクが最大容量に達した後はファイルの記録に消費されるので，事
> 前に減らす必要がなさそう。

いや、意外とその「消費の仕方」が下手で、Windows自体に任しておくと、ぐちゃぐちゃになるんだよ。

> するので，「ディスク内の空き領域が減ればMFT予約領域の必要性も比例的に減る」わけで
> はない。

だれも「比例して減る」などとはいってない。確率的には減るといっている。

> 埋まってきていったん予約領域が減らされた後にファイルが削除された場合，ディスクに十
> 分な空きがあるのにMFTの予約領域はほとんどないという状況になってしまう。

別にその時は削除されてもう使われてないMTFの領域を使えばいいわけで、何もわざわざ
予約領域から新たに確保する必要ないのだが？

> なので，ディスクが埋まってきたとしても，予約領域を積極的に減らすとMFTの断片化を招
> く可能性が増える。

だからぁ、バランスよく減らせばいいだけのこと。何度もいうけど、Windowsに任せておくと
食い散らかして汚くなるんだよ。まあデフラグすればいいだけなんだけどね。

またPerfectDiskはオフラインデフラグでMFTのデフラグもできるのだから、MFTのフラグメントは
あなたが考えるほど致命的ではない。

ま、MTFS予約領域まで動員しないとならない手前で使用容量は抑えておくのが賢明だとおもうけどね。

260:名無しさん＠お腹いっぱい。
06/05/24 04:01:13 xO+PSibQ0
>>254
> Bootvisをかけた後に、PerfectDiskで配置し直すという使い方になるけどね。
・・・・・。

相性がいいと思えるのは「標準デフラグ」「Diskeeper(Lite)」ぐらいしか知らないな。
ちなみに、「BootvisのOptimize System」≒「Rundll32 advapi32.dll,ProcessIdleTasks」なので
わざわざBootvisを使うまでも無いよ。

261:名無しさん＠お腹いっぱい。
06/05/24 05:47:17 fG6yQZvH0
>>260
> 相性がいいと思えるのは「標準デフラグ」「Diskeeper(Lite)」ぐらいしか知らないな。

いや、標準でフラグは相性悪いよ？Diskeeperも同じだけど。
空き領域のど真ん中にブート用ファイル群を配置するし、十分な連続領域が取れないと、
きちんと固まりとして配置しない。

PerfectDiskなら他のファイルをどかして、きちんとHDDの先頭部分に配置する。

> ちなみに、「BootvisのOptimize System」≒「Rundll32 advapi32.dll,ProcessIdleTasks」なので

もともとBootvisの話だから、それに沿って話しているだけのこと。
文脈を読めばこの程度のこと分かりそうなものだけどねぇ（笑

262:名無しさん＠お腹いっぱい。
06/05/24 05:54:51 fG6yQZvH0
んで、PerfectDiskが標準デフラグやDiskeeperに比べてPrefech関係で（まあそれに限らないが）
優れている点こそあれ、劣っている部分はないと思うよ？

あなたが相性がいいツールは標準でフラグとDiskeeperしか知らないというのは、PerfectDiskをよく知らないからだろう。
まあしっているなら「PerfectDiskのこういう点がダメだ」といってくれてかまわないけどね。

まあPerfectDiskにも当然文句はあるが、それはまた別な話。

263:名無しさん＠お腹いっぱい。
06/05/24 06:14:52 fG6yQZvH0
一応説明しておくと、PerfectDiskにはOSおよびアプリの高速起動用プリフェッチを
どうレイアウトするか選択できる。Windowsに任せることも出来るし、PerfectDiskが行うことも出来る。

Windowsに任せた場合は、PerfectDiskはプリフェッチ関係のファイルについて関知しない。
つまり標準デフラグが3日に1回行うのと同じになる。

PerfectDiskに任せるモードでは、レジストリを変更して標準デフラグが行う再配置を停止し、
PerfectDiskが起動したときだけプリフェッチデータに基づき再配置を行う。

このモードにはさらに二種類あり、OSのブート関係のファイルのみを再配置するか、
アプリ起動用のファイルも再配置するかを選択できる。

264:名無しさん＠お腹いっぱい。
06/05/24 06:21:18 fG6yQZvH0
で、俺は標準の動作、ブート関連のファイルだけいつの間にか（3日に1回)勝手にいじられるのは
どうかと思うから、PerfectDiskに任せている。これならPerfectDiskでデフラグするときだけ、他のファイルが
デフラグされる時に、同時にブート関連のファイルも適切に再配置される。

いつのまにか自動的に再配置されるよりずっといいと思うけどね。なにしろ標準の動作だと、
起動用のファイルをまとめてくれるのはいいが、それしか考えないから、起動用のファイルを抜き出した
跡があいてしまう。つまり空き領域の断片化の原因になる。

まあそこまで神経質にならなくてもいいという気はするが、断片化するよりはしない方がいいだろう。

265:名無しさん＠お腹いっぱい。
06/05/24 10:03:47 yejnjZSX0
>>259

> いや、意外とその「消費の仕方」が下手で、Windows自体に任しておくと、ぐちゃぐちゃ
> になるんだよ。

なるほど。これは，知らなかった。これって，ディスクに占めるデータの割合が同じ状態で
空き領域を消費する場合よりも，MFT予約領域を消費する場合の方が「ぐちゃぐちゃ」にな
るということですよね？そうでないと，予約領域を敢えて削減して空き領域を作るべき理由
にならないと思うのですが。とはいえ，私も予約領域を消費するまでディスクが埋まった場
合を想定する意味はあまり感じてませんが。

> だれも「比例して減る」などとはいってない。確率的には減るといっている。

「確率的」の意味がよく分からない。「おそらく減るだろう」という程の意味だとすると，
空き領域が減れば，同時にMFT予約領域も減っていくのだから，そのままで良いということ
にもなりませんか？書き込みによる減少に加えてさらに予約領域を敢えて削る理由として
は足りないと思うのです。

> 別にその時は削除されてもう使われてないMTFの領域を使えばいいわけで、何もわざわざ
> 予約領域から新たに確保する必要ないのだが？

これはまったくその通り。こちらの勘違いです。失礼しました。これは理由にならない。

ちなみにMFTの断片化が致命的とまでは思っていませんよ。どうも予約領域を削減する積極的
理由が見えてこないということです。

266:名無しさん＠お腹いっぱい。
06/05/24 10:09:57 yejnjZSX0
ここまでみて結局，「ぐちゃぐちゃ」の件以外，予約領域を削減する「積極的」理由がよく
わからないのですが，空いた領域の分だけ普段の（オンライン）デフラグが効率的にできる
可能性があるというあたりでしょうか。削減するデメリットは，小さなファイルの蓄積によ
ってMFTが肥大し予約領域を使い切る可能性があること。

ただ，確保すべきMFT領域のサイズがよく分からないので，あなたの言う予約領域削減にお
ける「バランス」がどこにあるのか見極めにくいと感じています。

すなわち，MFTに直接格納される小さなデータは通常のファイルに加え，ディレクトリ，ショ
ートカットなど様々あり，セキュリティ関係のアプリの更新やMSのパッチ等を考えると，
どうしても蓄積されて増えていくので，MFTの必要となるサイズ（の上限）が予想しにくい。
一方で，デフラグの効率性についてはcontig，dirmsを使えばそれほど空き領域を気にす
る必要はない。なので，とりあえずMFTゾーンの初期サイズは大きめにしておき，敢えて削
減する必要もないだろうと個人的には考えるのですが。

というわけで，削減すべき積極的理由など「バランス」をとる際の要素が他にあれば参考に
したいので聞かせてもらえませんか？まぁ，もちろん，これも個人の環境に激しく依存する
わけですけど。

267:名無しさん＠お腹いっぱい。
06/05/24 11:27:30 /SNmPTeh0
メカage

268:名無しさん＠お腹いっぱい。
06/05/24 12:17:17 aKHtLfng0
久々だな、おい

269:名無しさん＠お腹いっぱい。
06/05/24 14:44:04 IJOwFFy10
デフラグって年に２，３回で十分よね

270:名無しさん＠お腹いっぱい。
06/05/24 15:09:37 tfiFXN/d0
俺、毎日やってんだけど。

271:デフラグさん ◆mRgSYalFkQ
06/05/24 15:41:25 9dvbQiL00

　 [ ﾟдﾟ]y-一~~~~　ｻｲﾃｷｶﾉﾋﾂﾖｳﾊｱﾘﾏｾﾝ
　ﾉ[ ﾍﾍ
■■□■■□◇＿◇□□□

272:名無しさん＠お腹いっぱい。
06/05/24 19:26:00 fG6yQZvH0
>>265
> 空き領域を消費する場合よりも，MFT予約領域を消費する場合の方が「ぐちゃぐちゃ」にな

だからそう書いているつもりなんだけどね。俺の文章でそう取れない表現があったら教えてほしいね。

> 「確率的」の意味がよく分からない。「おそらく減るだろう」という程の意味だとすると，

「弱い相関関係がある」という意味だよ。

> 空き領域が減れば，同時にMFT予約領域も減っていくのだから，そのままで良いということ
> にもなりませんか？

なんか混乱してるようですな。空き領域が減れば、あらたに作られるファイルも減るはずで
今後新たに必要になるであろうMFTのサイズも減っていくということ。

最初の頃、新たに作られるファイルのサイズが分からないから多めにMFT用に領域を確保しておいたが、
HDDの大半が消費されれば、その領域は「確定」していくわけで、自ずと「不確定」さは減っていく。

たとえれば、HDDの残り領域が、HDDの容量あたりもっともMFTの使用量が多いサイズのファイルで
埋められるケースを想定してMFT用の領域を当初確保していたとする。HDDの容量を半分使い切った
段階で振り返ってみれば、そんな最悪のサイズのファイルは少数だった、と分かったとしよう。

となれば残りの半分が最悪のサイズのファイルで全部埋まったとしても、当初想定していた最悪の状態
(HDD全体が最悪のサイズのファイルで埋まる）ほどはMFTの領域は必要ないことが分かるわけだ。
ならばその分予約領域を縮めるという判断は悪い判断ではないだろう。

> ちなみにMFTの断片化が致命的とまでは思っていませんよ。どうも予約領域を削減する積極的
> 理由が見えてこないということです。

積極的な理由がなければ削るべきではない、と考えるのが「致命的と考えている」といってるんだけどね。
気軽に削るのは控えるべきと考えているわけだろう？

273:名無しさん＠お腹いっぱい。
06/05/24 19:47:15 fG6yQZvH0
>>266
> わからないのですが，空いた領域の分だけ普段の（オンライン）デフラグが効率的にできる
> 可能性があるというあたりでしょうか。

いや別にPerfectDiskは空き領域の大きさでそれほどデフラグの効率の良さは変わらない。
Diskeeperとかだと空き領域がないとすぐ音をあげるけどね。

不要なMFT予約領域を削るのは、Windowsに自動的に削らせるよりもファイルの配置が
マシだから。デフラグをしばらく書けない状態でもそこそこの配置が維持できる。
まあ毎日デフラグかけている人にとっては関係ない（笑

> 削減するデメリットは，小さなファイルの蓄積によ
> ってMFTが肥大し予約領域を使い切る可能性があること。

PerfectDiskとかがMFTを縮小する場合、そうなる確率がそれほど高くない程度の範囲で縮小してるんじゃないの？
いや実際に詳しく調べたことないけどさ。俺が長年使っていて見ていた限りでは縮小されたMFT予約領域では足りなくて、
再び増加させたというケースはなかったよ。もちろん想定外のことが起きることはあるだろうが、その時はオフラインデフラグを
かければいいわけで。

> ただ，確保すべきMFT領域のサイズがよく分からないので，あなたの言う予約領域削減にお
> ける「バランス」がどこにあるのか見極めにくいと感じています。

そりゃそうだろうねぇ。しかしそれをいうなら、最初に確保されているMFT予約領域のサイズにどれほど
正当性があると考えるのかね？あなたがツールによって縮小された予約領域に不安を覚える一方、
最初から設定されている予約領域のサイズに安心をを感じるのは単に「最初そうなっていた」という理由だけだよね。

どのみち「予想外」のことが起きる可能性はゼロではないわけだよ。

274:名無しさん＠お腹いっぱい。
06/05/24 19:48:40 fG6yQZvH0
> 一方で，デフラグの効率性についてはcontig，dirmsを使えばそれほど空き領域を気にす

上に書いたように、別にデフラグ動作の効率のために予約領域を縮めているわけじゃないって。
もしそうならそれこそ本末転倒でツールが馬鹿だろう。

> る必要はない。なので，とりあえずMFTゾーンの初期サイズは大きめにしておき，敢えて削
> 減する必要もないだろうと個人的には考えるのですが。

だから「大きめにしておいた方が安心」というのは「溢れたら大変」という感覚を持っているからだろ？
たとえばMFTをデフラグできないツールなら、確かにMFTが一度フラグメントしてしまうと取り返しが
つかないわけで、俺だって「心配」になる。しかしPerfectDiskとかはMFTをデフラグできるのだから、
それは「取り返しのつかない」事態ではない。ならば必要以上に「安全側」の選択をする必要はない。

逆に言えば標準のWindowsはMFTをデフラグする機能を持たないから、MFTがフラグメントを
起こさないようにかなり安全側に偏ってMFT予約領域を算出してるんじゃないのかなぁ。

> というわけで，削減すべき積極的理由など「バランス」をとる際の要素が他にあれば参考に

残念ながら、PerfectDiskがどういう戦略でMFT予約領域を縮小しているのかは調べたことがない。
しかしすでに述べたように、「MFT領域を多めに確保しておく」という方針の場合、HDDの大半が
まだ未使用な状態で想定する「多めのMFT領域」とすでに半分消費されている状態での
「多めの領域」は後者の方が当然小さい。その段階ではすでに半分はどういう性質のファイルが
書き込まれているのか確定しているから、最悪のサイズを想定する必要がなくなったのだからね。

だからその辺を鑑みて決定してるんじゃないのかなぁ、と漠然と思ってるんだけどね。
この際だからあなたが調べて教えてよ（笑

275:名無しさん＠お腹いっぱい。
06/05/24 19:55:37 fkgN9ma30
やべえ、ついていけねえ

276:名無しさん＠お腹いっぱい。
06/05/24 20:18:56 ec1TvvWY0
>>273
ホントＤＫは糞だよね。
ＰＤの場合、空き領域が殆どゼロでも、
何の問題もなく淡々とデフラグしてくれる。

277:名無しさん＠お腹いっぱい。
06/05/25 00:22:25 W/yE1dB50
Diskeeper=糞なのは常識

278:名無しさん＠お腹いっぱい。
06/05/25 11:04:47 v5IVrOj40
>>275
メカについていく必要は無い

279:名無しさん＠お腹いっぱい。
06/05/25 12:17:57 Xjw6ku/b0
>>272
> だからそう書いているつもりなんだけどね。俺の文章でそう取れない表現があったら教えてほしいね。

単純に不思議だったのです。より「ぐちゃぐちゃ」になることを実証するには相当数の環
境の異なるサンプルで実験する必要があり，不確定要素が非常に多く，かなり面倒だろう
と思ったので，私の理解が合っているのか確認したかったのです。

> なんか混乱してるようですな。空き領域が減れば、あらたに作られるファイルも減るはずで
> 今後新たに必要になるであろうMFTのサイズも減っていくということ。

意図が伝わらなかったようですね。私は，上記を前提に書いています。「今後新たに必要
になるであろうMFTのサイズも減っていく」が，それにつれて当然残りの予約領域も減っ
ていく。であれば，さらに削減する必要はないという結論も導けるのであり，いずれかの
結論のみを支持する根拠にはなり得ないということを言ったのです。

280:名無しさん＠お腹いっぱい。
06/05/25 12:24:16 Xjw6ku/b0
>>272
> たとえれば、HDDの残り領域が、HDDの容量あたりもっともMFTの使用量が多いサイズのファイルで
> 埋められるケースを想定してMFT用の領域を当初確保していたとする。HDDの容量を半分使い切った
> 段階で振り返ってみれば、そんな最悪のサイズのファイルは少数だった、と分かったとしよう。
>
> となれば残りの半分が最悪のサイズのファイルで全部埋まったとしても、当初想定していた最悪の状態
> (HDD全体が最悪のサイズのファイルで埋まる）ほどはMFTの領域は必要ないことが分かるわけだ。
> ならばその分予約領域を縮めるという判断は悪い判断ではないだろう。

文意が不明ですが，MFTに入力される各エントリーのサイズは常に1024bytesだとMSは説明
しています。異なる見解もあるようですが。そして通常，１つのファイルにつき１つのエ
ントリーが作られる。これは，ファイルサイズとは無関係です。

また，通常約750bytes以下の小さなファイルはMFT内部に直接格納され，外部の領域には
保存されません。したがって，可能性としては，HDDの空き領域がMFTのみで全部埋まるこ
ともあり得るのであり，どこまで空き領域が減っても予約領域をMFTが使い切る可能性は
消えません。そして，このような小さなファイルが最終的にどれほど蓄積されていくのか
予測がしにくいので，MFTの必要サイズを見極めるのが難しいと言っているのです。

> 積極的な理由がなければ削るべきではない、と考えるのが「致命的と考えている」といってるんだけどね。
> 気軽に削るのは控えるべきと考えているわけだろう？

あなたの語義解釈は分かりました。しかし，私は積極的理由があっても，自分にとって致
命的なことは実行しません。私にとって「致命的」という言葉は，「気軽に実行するのは控
えるべき」という言葉ほど軽くないということです。ご理解ください。

281:名無しさん＠お腹いっぱい。
06/05/25 12:30:06 Xjw6ku/b0
>>273についていうと，ここまで「安心感」や「可能性をゼロにする」といった話はして
いませんよ。どちらの選択がマシである可能性が高いか，また選択の際の考慮要素は何か
という話です。ちなみに，私はMFT予約領域のサイズを初期設定より大きくしていますよ。
XPの初期設定は用意されたオプションの中で最も小さい値となっており，より大きく変更
している人も結構いると思います。

また，>>274で，あなたはPerfect Diskの使用を前提に話を進めており，それはよいので
すが，私は違います。また，Perfect Diskの設計思想を調べるほどの動機も持ち合わせて
いません。前回お聞きしたのも，「バランス」を取れと言われたあなたに，あなた自身の
バランスの取り方について考えをお聞きしたのであって，Perfect Diskの設計思想をお聞
きしたわけではありません。もっとも，あなたの経験は参考になりますし，お答え頂いた
ことには感謝します。

なお，私は，予約領域の処理はDiskeeperのようにユーザーに委ねたほうが良いと思いま
す。Perfect Diskに予約領域を削られたことに不満を漏らすユーザーの書き込みも見まし
たし。

必要なMFTサイズの見極めについて言うと，可能性として空き領域すべてがMFTで埋まるこ
ともあり得る以上，HDDの空き領域が減ってきても，確実なのはMFT肥大の限界点（＝予約
領域＋MFT外部の空き領域）が下がることぐらいでしょう。

そして，HDDの使用領域がある程度増えた場合，ユーザーはHDDが埋まらないように場所を
取るファイルを削除するなどするでしょうが，MFTに直接格納されるような，ディレクト
リなどの前回挙げたものは，比較的退避させにくく，また増えていく性質のものもあり，
蓄積されやすいと考えています。そうすると，MFT外部の空き領域のサイズには大きな変
化がないが，MFTのサイズだけは肥大していくことになりかねない。

ですから，空き領域が減ってきてもMFTの必要十分なサイズはやはり見極めにくいと思うの
です。まぁ人によって違うでしょうが。

282:名無しさん＠お腹いっぱい。
06/05/25 12:35:47 Xjw6ku/b0
結局，ここまでのところ，予約領域を削る積極的理由，言い換えれば，損失回避または利
益享受という意味での「メリット」は特にめぼしいものが挙がっていないように思います。

「ぐちゃぐちゃ」の件は，あなたの言うとおり，そこに至ること自体賢明とは言えず，考慮
の必要が薄いし，そうなった時点で自分で予約領域を削れば容易に対処できます（XPの場合）。
また，デフラグの効率性に大差はないことについてもほぼ共通認識が得られました。

一方，デメリットは，予約領域を使い切るおそれがあること。これは不確定要素が多く,
私は上記の通り空き領域が減っても不確定性はそう変わらないと感じています。あなたは
違うようですが。また，MFTを処理するデフラグメンタを用いないユーザーにとってこの
デメリットは心配の種になるが，そうでない人にとってはそうではないというのはあなた
の言われたとおり。

そうすると，MFTを処理するデフラグメンタを用いない私にとって，予約領域削減は，メ
リットが感じられず，一方で不確定要素があるとはいえデメリットがあリ得るということ
になります。とすれば，実行しないという選択は私にとって至極当然の判断です。これは
デメリットが「致命的」か否かという以前の問題です。繰り返しますが，私にはメリット
がなく，デメリットがあり得る。だからやらないということです。もちろん，あなたの場
合は違うでしょう。

だいぶ長くなりました。大体互いの状況，考慮要素，その評価基準，価値観等の理解が得
られたかと思います。結局，これらの違いにより下される結論も異なるという当然といえ
ば当然の結論に至ったようです。スレの本旨から外れた話を長文で書き込むのもどうかと
思うのでそろそろお開きにしたいのですが，あなたはどうでしょうか。

というか，これ以上長文書くのが面倒ですし。

283:名無しさん＠お腹いっぱい。
06/05/25 13:03:35 znm1VJgE0
「面倒ですし。」迄読んだ。

284:名無しさん＠お腹いっぱい。
06/05/25 14:49:38 Xjw6ku/b0
>>281の訂正
4行目　×　「XPの場合」　→　○　「NT4 sp4以降の場合」

>>282の訂正
4行目　×　「XPの場合」　→　○　「NT4 sp4以降の場合」

失礼。

>>283
普通にありがとう，とマジレス。

285:名無しさん＠お腹いっぱい。
06/05/25 18:59:35 4hDf3vY20
>>279
> 単純に不思議だったのです。より「ぐちゃぐちゃ」になることを実証するには相当数の環
> 境の異なるサンプルで実験する必要があり，不確定要素が非常に多く，かなり面倒だろう

長年、容量不足のサーバーをだましだまし管理してれば分かるよ（笑

> 意図が伝わらなかったようですね。私は，上記を前提に書いています。「今後新たに必要
> になるであろうMFTのサイズも減っていく」が，それにつれて当然残りの予約領域も減っ
> ていく。であれば，さらに削減する必要はないという結論も導けるのであり，いずれかの
> 結論のみを支持する根拠にはなり得ないということを言ったのです。

あなたホントーに頭悪すぎ。マジで理解できないわけ？「マジで理解できません」というなら、
あと一度だけ説明してあげるが。

286:名無しさん＠お腹いっぱい。
06/05/25 19:16:20 4hDf3vY20
>>280
> 文意が不明ですが，MFTに入力される各エントリーのサイズは常に1024bytesだとMSは説明

うーん、そうだね、あなたは根本的に何が問題か理解できないらしい。

極端な話、すべてショートカットだけで埋められたHDDがあると考えればいい。その状態だと
HDDの容量あたりのMFTの占める割合は100%だよね。

もちろん普通のHDDはデータの占める割合の方が遙かに大きい。たとえば1%ぐらいだとしよう。
しかしMFTがフラグメントする危険性を考えて、5%ぐらいを想定して初期のMFTの予約領域の
サイズを決定したとする。つまり「少し多め」にしたわけだ。

100GBのHDDで5%というと5GBとなる。フォーマット直後のMFT予約領域がこのサイズだ。
で、そのHDDにいろんなファイルを詰め込んで半分まで使用した状態になったとする。
容量あたりのMFTの使用状況は予想通り1%だったとしよう。つまり50GBすでに使用されているから
MFTは0.5GBが使用されている。

この時点で残り50GBについてもう一度どれだけのMFT予約領域が必要かを考える。
多めの見積もり5%だとすると、50GBの5%だから2.5GBだ。

しかしこの時点では初期化時に100GBの5%である5GBのMFT予約領域を確保している。
そしてこの時点での使用されているMFTは50GBの1%である0.5GBであり、今後50GBの
5%である2.5GBがまるまる使用されたとしても0.5GB+2.5GB=3GBしか必要ないことになる。

つまり最初に確保した5GBのMFTは不要で、3GBに縮小してもいいということになる。

ゆ～あんだすたん～？（笑

287:名無しさん＠お腹いっぱい。
06/05/25 19:17:41 4hDf3vY20
> 予測がしにくいので，MFTの必要サイズを見極めるのが難しいと言っているのです。

だからぁ、それは初期化時に確保した予約領域のサイズだって同じ事だといってるだろうに。
それを「最初に決めた」という理由で何かすごい根拠のある値だと思っている点があなたの間違いな分け。

> あなたの語義解釈は分かりました。しかし，私は積極的理由があっても，自分にとって致
> 命的なことは実行しません。私にとって「致命的」という言葉は，「気軽に実行するのは控
> えるべき」という言葉ほど軽くないということです。ご理解ください。

トートロジーですな。何を基準にどういう根拠で「気軽に実行するのは控えるべき」なのかという
観点が欠如している。気軽に実行すると”なぜ”ダメなのかを検討し根拠を明らかにするのが
技術的な見解といえる。あなたのは「特に理由はないがなんとなくこわい」といっているのと同じだ（笑

そういう人を説得しようとは思わないよ。説得できるものでもない。感覚的な感情で判断する人は、
実際に自分でやってみて慣れるとか、感覚的に自分で納得するしかないだろうからね。

288:名無しさん＠お腹いっぱい。
06/05/25 19:20:12 O/4e3ZhU0
このくだらないやりとりが自演に見えてきたヤツ→(1)

289:名無しさん＠お腹いっぱい。
06/05/25 19:26:19 v5IVrOj40
　.

290:名無しさん＠お腹いっぱい。
06/05/25 19:42:46 lUAyb1DV0
(2)

291:名無しさん＠お腹いっぱい。
06/05/25 19:51:24 znm1VJgE0
何を揉めているのかサッパリ分からない・・・＿|￣|○

292:名無しさん＠お腹いっぱい。
06/05/25 19:55:24 lUAyb1DV0
必殺「トートロジー」攻撃だもん

293:名無しさん＠お腹いっぱい。
06/05/25 19:56:41 uozZ4uskP
>>291
メカを理解したら人間として負け

294:名無しさん＠お腹いっぱい。
06/05/25 19:58:44 4hDf3vY20
>>281
> いませんよ。どちらの選択がマシである可能性が高いか，また選択の際の考慮要素は何か
> という話です。

それは結構なんだけど、いつになったらあなたの選択である「MFT予約領域のサイズは
気軽に変えるべきではない」という選択の「考慮要素」の説明をしてくれるのかね？

ここまでの話ではあなたは「最初からそうなっていたから、変えるべきではない」としか言ってないよね？
最初に決めたMFT予約領域のサイズに相応の根拠があり、その根拠を覆すだけの理由がないから
変えるべきではない、と主張するならいいが、最初に決めたMFT予約領域のサイズにも
たいした根拠はないわけだよ。あなたが自分で言っているようにどれだけMFTが必要になるかなど予測できない。

だから「変更する」場合にも変更する理由は特にいらない。

ちなみに，私はMFT予約領域のサイズを初期設定より大きくしていますよ。

だから「なぜ」しているのかね？MFTが万が一にもフラグメントするといやだからだろう？
MFTをデフラグできるツールを使っている人間には、MFTがフラグメントする状態はあなたが思うほど
嫌な状態ではないって事。

> XPの初期設定は用意されたオプションの中で最も小さい値となっており，より大きく変更
> している人も結構いると思います。

「そうしている人がたくさんいる」からそうするのが正しいって？（笑
それならPerfectDiskを使っている人は世界中にたくさんいるから、MFT予約領域を自動的に
縮小するのが正しいことにもなるね。

あなたは、自分で思うほど論理的な思考ができる人間ではないようだよ？

295:名無しさん＠お腹いっぱい。
06/05/25 20:00:33 4hDf3vY20
> また，>>274で，あなたはPerfect Diskの使用を前提に話を進めており，それはよいので
> すが，私は違います。

それはあなたの勝手だ。おれはMFTをデフラグ出来るツールを使っているなら～だ、と言っているだけで、
使っていない人は別なスタイルがあるだろう。そもそもデフラグをすること自体、HDDを痛めると言って
いやがる人もいるわけで、俺から見れば薄弱な根拠にとらわれて損をしている人だとは思うが、
当面そういう人達を説得できる材料もない。

まあ素人さんが根拠なく漠然と不安を感じるのはある意味仕方のないことだとは思うけどね。
何にでも「いままでとは違う」ことに拒絶反応を起こす人はいるし、それがプラスに働くことも少なくないから、
よけい始末に負えない。

> いません。前回お聞きしたのも，「バランス」を取れと言われたあなたに，あなた自身の
> バランスの取り方について考えをお聞きしたのであって，

上で説明したように、「初期」に割り当てられているMFTのサイズがHDDの容量あたり「多め」であれば、
ある程度HDDが消費された状態なら、同じ「多め」の割合で残りの空き容量に対してMFTの量を
見積もっても、そのサイズは一般的に小さくなるはずで、それに見合う量に縮小するのがバランスが
とれた状態、ということだよ。

たとえば登山で頂上に着くまでの時間を見積もることを考えればいい。出発した直後は
途中でいろいろなアクシデントがあるかも知れないから、所要時間はかなり余裕をもって見積もるはず。
最悪でも○○時には頂上に着けるだろう、と。たとえば13時に到着できると思ってもプラスマイナス1時間ぐらいの
誤差を見込んで、最悪でも14時には着ける、と予測をし、それを見込んで登山の開始時刻を逆算するだろう。

次ページ