2011年11月の日記です

目次

16日 tcc
17日 バックアップとデフラグ
24日 デフラグ考
25日 しつこくデフラグ話


tcc  2011-11-16 11:36:09  コンピュータ

▲目次へ ⇒この記事のURL

その昔、Turbo Pascal というプログラム言語があった。


…この言い方はちょっと違うか。

Pascal というコンピューター言語があって、その処理系の製品として、Turbo Pascal があった。


Pascal というのは、もともと教育用に考えられた言語だ。

といっても、わかりやすくなっているけど非力、というようなことはなくて、非常に強力。


祖先は ALGOL で、C と同じ。だから、プログラムの組み方も C と似ている。

違うのは、C はハードウェアを直接叩けて、システムクラッシュさせるのも自由気ままにできるのに対し、Pascal はハードウェアをできるだけ隠蔽するように作られているので、システムクラッシュが起こりにくいこと。


隠蔽する、というのは手間がかかることなので、パフォーマンスは C が上。

プログラムを組む上でも、Pascal は「比較的厳密な」文法を求められるのでバグが出にくい反面、いちいち入力が面倒くさかった。

趣味のプログラマーにとってはバグなんて多少出てもいいし、厳密に書かないと動かないのは面倒くさいので嫌われた。


そんなわけで C 言語が幅を利かせるようになり、「類似言語」であった Pascal は下火になるのだが、Pascal 自体が非常に強力な言語であった、という事実は変わらない。



強力さのひとつに、言語設計のうまさがある。

プログラムは、必ずボトムアップで書かなくてはならない。

わかりやすく言い換えると、関数は定義してからでないと使えない。


「とりあえず関数の呼び出しを書いといて、あとで関数の実体を書く」は、原則として許されない。


これによって、関数が呼び出されるときには、すでに関数の定義が終わっている。

同様に、変数も使われる前に定義されている。


C言語では、どこで関数が定義されているかわからないので、コンパイル時に少なくとも2回はソースを読まなくてはならない。

1回目で定義を全部把握して、2回目で実際のコンパイルを行う。


でも、Pascal の設計では、1度ソースを読めばコンパイルが完了できる。



で、冒頭の Turbo Pascal。

「Turbo」と名づけただけあって、コンパイルが速かった。


…「速い」なんてもんじゃない。コンパイルしていることに気づかなかった。

なにせ、Turbo Pascal には専用のエディタがついていて、エディタの上で F5 キーを押すと、プログラムを実行できるのだ。

BASIC のような、インタプリタ言語の感覚でプログラムを組むことができた。


これはつまり、エディット中なのでメモリ上に入っているソースをそのままコンパイラに渡し、コンパイラは1パスでコンパイルを行い、生成後のバイナリはメモリに載せたまま実行していた、ということだ。

ディスクアクセスがないので、非常に速い。



Turbo Pascal を作った Borland 社は、C 言語のほうが人気が出たために Turbo C も作った。

でも、こちらはいまいち。当時のほかの C 言語処理系よりも高速にコンパイルができたが、C 言語の仕組み上ファイルを多数読み込まなくてはならず、コンパイルも1パスではできず、「インタプリタ感覚」とはいかなかった。



大学のとき、アルバイトしていたゲーム会社で、グラフィックデータの整理を任されたんで、Turbo C を借りて2~3日でツールを作って、大量のデータ整理が簡単にできるようにしたっけ。


バイトの仕事として雑用を任せたら、汎用のツールを作ってしまったので驚かれて…社長から、大学辞めて働かないかと誘われました。

腕を認められたわけでうれしかったけど、大学やめる気はなかったので、翌月にバイトやめて逃げ出してしまいました。


今ではそれなりに有名な会社だけど、社長元気かな。





と、ここまでは長すぎる前フリ。


Turbo C Compiler のコマンド名は tcc だったけど、今回の話のテーマは、同じ tcc というコマンド名を持つ、Tiny C Compiler


2004 年には最初のバージョンがでているようなので(もっとも、2002 年には otcc という名前で前身となるプログラムがある)、ここで取り上げるのも「いまさら」なのだろう。


僕は3年位前に tcc の存在は知っていたのだが、Tiny と名前についているくらいなので、「コンパイラの作り方の教科書に出てくるような、C 言語のサブセット」だと思っていた。


実際、otcc はサブセットだったらしいのだが、tcc は ISO の規格にのっとった、フルセットの C 言語になっている。



そして、tcc がすごいのは、Turbo C 並にコンパイルスピードが速いこと。


ファイルを多数開くのは C の特性上仕方がないが…1ファイルで完結する短いプログラムであれば、TurboPascal並と言って差し支えないだろう。


この速さを活かして、ソースをコンパイルして、バイナリをファイルに吐き出さないでメモリ上においたまま実行、ということができる。

つまるところ、C 言語をインタプリタ言語のような気楽さで使えるのだ。


もっとも、生成されるソースコードの品質は低い。

速度を活かして開発して、出来上がったら GCC などで最適化したバイナリを作る、というのが正しい使い方なのだろう。



というわけで、早速インストールしてみる。

Unix (僕の場合、Linux の CentOS 5.5)にインストールするには、ソースを展開して、


./configure

make

make install


で終わり。

この場合、GCC でコンパイルされる。


せっかくなので、コンパイル時間を計ってみる。


time make


とすればよい。


make するたびに、make clean して元の状態に戻し、3回計って平均を取ってみた。


real 0m19.858

user 0m18.955

sys 0m0.689


重要なのは、user の値。0分18秒955。

出来上がったバイナリサイズは、331769 byte。



さて、次に、出来上がった tcc で tcc 自身をコンパイルしてみる。


./configure -cc=tcc


あとは同じでよい。同様に3回やってみて平均。


real 0m0.395

user 0m0.318

sys 0m0.047


速い。59倍速。こんなに速すぎると測定誤差もあるだろうから、何倍、に意味はなさそうだけど。

出来上がったバイナリサイズは、410056 byte。


バイナリサイズは2割り増しだ。

gcc と違って最適化がされていない(もしくは甘い)ので、コンパクトさで2割違う、ということだ。



続いて、tcc でコンパイルした tcc で、tcc をコンパイル。

これで、tcc が生成したバイナリの速度品質がわかる。


real 0m0.777

user 0m0.649

sys 0m0.052


遅い。先ほどの倍以上の時間がかかっている。

gcc と違って最適化がされていないので、速度で2倍違う、ということだ。


出来上がったバイナリサイズは、411324 byte。

…あれ? tcc コンパイル、という点で同じなのに、さっきと違う。


よく見たら、tcc をコンパイルすると、tcc が使用するライブラリも一緒に生成されていた。

つまり、最初に tcc でコンパイルをした際、使用されたライブラリは gcc でコンパイルされたもので、これが最終的なバイナリにも含まれていた、ということ。


2回目の今回、ライブラリも tcc でコンパイルされたものとなったので、これが本当の「tcc でコンパイルされた」サイズ。



念のため、もう一度 tcc でコンパイル。


real 0m0.763

user 0m0.635

sys 0m0.075


速度はほとんど変わらず、誤差範囲。

出来上がったバイナリのサイズも先ほどと同じで、念のため diff したが、完全に同じものだった。




というわけで、結論。


tcc のソースをコンパイルする、という限定的な条件の試験だが、以下の結果が得られた。

tcc の生成バイナリは、gcc の生成バイナリよりも、コンパクトさで2割、動作速度で2倍程度劣る。

しかし、tcc によるコンパイル自体は、gcc よりも 20倍以上速い。





余談だけど、tcc 作った人は、FFmpeg とか、QEMU とか、A PC emulator in Javascript とか作った人と同一人物。


FFmpeg といわれてもわからなくても、携帯動画変換君や MEncoder 、VLC Player など、数え切れないほどの「動画関連ソフト」が、内部に FFmpeg を持っている、と説明すれば、すごいソフトであることが理解されるでしょう。


また、QEMU も、Xen や kvm など、Linux に組み込まれた「仮想化技術」のコアになっています。


A PC emulator in Javascript は、その名のとおり、QEMU を Javascript で実装してみた、という実験です。

リンク先に進むとわかりますが、Linux が起動し、tcc でソースをコンパイルできる環境が整います。


これ、「そんな感じに見えるフェイク」ではなくて、本当に動作する Linux なんですね。

chrome とか、最近のブラウザ使えば、ベースマシンの CPU 速度が遅くても、それなりの速度で動作します。


あと、2009 年時点での、円周率の計算桁数で世界記録保持者でした。2兆7千億桁。

先日、日本人が10兆桁計算して、現在はこれがトップですが。



なんか…すごいなぁ。「面白がって」プログラムを作っている感じが、すごくする。

そして、その面白がりが非常に有用で、世界を変えるほどの力を持っている。


本当のハッカーって、こういうことなんだろうな。



後日追記 11.11.18


本文中に書いた「大学時代にバイトしたゲーム会社」ですが、それなりの規模になって某人気ゲームシリーズなどを作っていたのですが、5年ほど前に廃業しているようです。


ネットで調べて知りました。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

スーパーファミコンの発売日(1990)【日記 13/11/21】

ニクラウス・ヴィルト 誕生日(1934)【日記 16/02/15】

別年同日の日記

01年 11/16

01年 11/15

09年 食育フェスタ

12年 こんにゃく

13年 宮本茂 誕生日(1952)

14年 雑誌の発行日

15年 デイビッド・パターソン 誕生日(1947)

17年 ST-V 開発環境


申し訳ありませんが、現在意見投稿をできない状態にしています

バックアップとデフラグ  2011-11-17 15:54:52  コンピュータ

▲目次へ ⇒この記事のURL

夏の電力逼迫状態を抜けたときに、毎日の PC 運用を元に戻さなくては、と書いた

具体的には、メインマシンのバックアップを定期的に取ること。


以前は、深夜に自動起動して、ディスク丸ごとバックアップを取っていた。

でも、震災後は電力の無駄遣いを少しでも減らそうと、これを停止していた。


仕事で使っているマシンなのに、バックアップしないことにも問題がある。



以前のマシンは、7年前の XP マシンだった。

動作が重いため、バックアップだけでなく、深夜にデフラグも行っていた。


使っていたソフトは、Paragon Backup & Recovery と、MyDefrag

共に、無料だが評判の良いソフトだ。今度もこのソフトを入れるつもりでいた。



10月下旬の話。

まずは、Paragon を導入。バックアップを取る。

バックアップを取って安心したところで、各種デフラグソフトや、無駄なファイルをクリーンアップするソフトを試してみる。



…あれあれ? インストール&アンインストールを繰り返すうちに、なにかおかしくなったらしい。

システムの休止状態が利かなくなった。

(Windows 7 のデスクトップの休止が出ない問題ではない。休止はあるが、使えない。

 もっというと、コマンドラインで休止状態に入ろうとすると、dll が読み込めなかった、というエラーになる)


システムの復元を試してもだめ。

DELL マシンにプリインストールされている、「出荷状態に戻す」ツールを使う。

これは、データファイルは保護したまま、OS を初期化してくれる優れものツール…だったはずだが、戻らず。


まぁ、大丈夫。

こんなときのために、システムを丸ごとバックアップしているのだ。


あわてず騒がず、Paragon で Recover モードを使用。


…起動ディスクに対してリカバーはできません、といわれる。まぁ、それもそうだろう。

USB 起動メモリを作成して、そこから起動。


…NAS に入れてある、バックアップデータが見えない。

Paragon は NAS へのバックアップに対応しているが、Recover には対応していないらしい。


…NAS のバックアップを取ってある USB ディスクを接続。

今度はバックアップファイルが見れた。しかし、なぜか内蔵ハードディスクが見えない。

見えない先に対してリカバーはかけられない。


結局、リカバー断念。

Windows7 のクリーンインストール。




というわけで、Paragon は自分の中での信用を大きく落とした。

念のため書いておくが、NAS を使わなければ問題ないと思われる。

でも、それは面倒くさいから、僕はこの際 Paragon を使わないことにする。


クリーンインストールからリカバーしてみたら、データさえあれば案外なんでもなかった。

以前は、仕事柄変なソフトをいっぱい使っていたのだ。だから、インストールが面倒だった。


変なソフトってのは、携帯電話向けの開発ツール。

ところが、今は携帯電話の性能が上がり、事実上 PC と同じになってしまったため、専用ツールはほぼ不要。


だったら、必要なデータだけあればよい。

しかも、自分の場合重要データは Linux マシン上や、NAS 上においてあるものが多いから、本当に少しのファイルをバックアップしてあればよい。



というわけで、BunBackup を導入。

以前から名前は聞いていたが、「わずかなファイルを確実にバックアップしておきたい」という用途には最適のツール。


設定は多少やっかい。オプションが多すぎて、作者もそれを気にして「無用なオプションの隠蔽」を心がけているのだが、結果として機能はあるのに隠蔽されて見つからなかったり、余計な混乱を招く。


設定さえ終了すれば、非常に軽快な動作で安心感がある。


SandyBridge の Core i3 マシンで使っていますが、バックアップ中も作業をそのまま続けられます。まったく問題なし。




クリーンインストール直後なので、Defrag は必要ない。

でも、「転ばぬ先の杖」で探してみた。


というか、クリーンインストール前にいろいろ試していたのだな。


MyDefrag は、非常にきっちりデフラグしてくれるので以前は重宝していたが、いかんせん遅い。

遅いから作業中に使いたくなくて、深夜に使っていた。でも、これは電気の無駄だろう。


というわけで、SmartDefrag を使用してみた。

このソフト、評価真っ二つ。


ソフト紹介ページなんかの評価は、「動作が軽い」として各種の賞を受賞していたりする。

確かに軽い。デフラグがあっという間に終わるし、バックグラウンドで動作させても気にならない。


一方、デフラグ好きの人は、動作の軽さは評価ポイントにならない。

SmartDefrag は、デフラグの効果がほとんど出ない、というので評価が悪い。



しばらく使ってみて理由がわかった。

SmartDefrag のアルゴリズムは、「1日に50のデフラグが起きるなら、100個だけ解決しよう」というような考え方で作られている。


常駐していて、ほっとけば勝手にバックグラウンドでデフラグする。

でも、ある程度デフラグしたら、それでおしまい。徹底的にきれいにしようとはしない。


だって、常駐していて頻繁にデフラグするのだから、あとでまたきれいにすればいいじゃん。


「完全最適化」オプションでデフラグをかけても、同じような考え方。

あまり時間をかけないように、適当なところで切り上げる。


「完全最適化」は、ある程度デフラグをかけてあるディスクで、使用頻度の高いファイルを高速なエリアに少し移動する程度、という考え方。


でも、それでいい。

バックグラウンドでの動作が気にならない程度に軽いのであれば、時間をかけて少しづつきれいにして、ある程度きれいになったらその状態を維持する、という方法で問題はない。


ちなみに、家にある非常に古い XP マシンにも入れてみたが、そのマシンでもバックグラウンドで動いてもそれほど問題がないほど軽い。

5年程度使ったマシンなので、1度の「完全最適化」ではデフラグ効果はあまり出なかったけど、そのうちきれいになるだろう。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

デフラグ考【日記 11/11/24】

別年同日の日記

02年 友人宅へ

13年 1週間の記録

15年 ハーマン・ホレリス 命日(1929)

15年 ハムスター死去

19年 イベント終わりました


申し訳ありませんが、現在意見投稿をできない状態にしています

デフラグ考  2011-11-24 11:33:47  コンピュータ

▲目次へ ⇒この記事のURL

先日デフラグツールを選定した話を書いたので、デフラグについて書いておこう。


デフラグについて、するべきだ、という意見と、するべきでない、という意見の2つが、ネット上で流布している。


どちらの意見がすぐれているか、ということはさておき、まずは前提となるデフラグから書いておこう。




ファイルは、ハードディスク上に記録されている。

この記録は、OS が適切に管理してくれている。


昔のコンピューターは、この「適切さ」に難があった。

たとえば、ファイルは必ず「連続したエリアにおかれなくてはならない」という OS があったのを、僕は知っている。

この場合、扱っているファイルが大きくなってくると、別の専用ツールを使って「ファイル位置を移動して、空き領域を確保する」必要があった。



今の OS は、そんな面倒なことはない。

ファイルが大きくなってきて、ほかのファイルとぶつかりそうになると、離れた場所でも構わないので空き領域を見つけて続きを書き込む。

飛び飛びにファイルが記述されることになるが、OS はその位置を把握しているので、ユーザーが気にする必要はない。



ただ、ひとつだけ難点がある。

ハードディスクは、「物理的に」動作しているのである。

連続した場所に書かれた情報は、連続して読むことができる。しかし、離れた場所にある場合は、探しに行く必要がある。

この、探しに行く時間というのは、ほんのわずかである。しかし、コンピューターの電子的な動作からすると、非常に長い時間なのだ。この時間を無駄にすることになる。


この、「非連続にファイルが記録される」ことを、「ファイルの断片化(フラグメンテーション)」と呼ぶ。


これを解消するのが、デフラグである。

(「デ」は、除去する、元に戻す、などの意味の接頭語。バグ取りをデバグ、というのと同じ)



話をまとめよう。


昔のコンピューターでは、ファイルの容量が増加すると、定期的に専用ツールで空き領域を確保する必要があった。

今のコンピューターではそんな面倒はないのだが、無駄を減らしたければデフラグツールを使って、デフラグをする。

「しなくてもいい」ことはありがたいが、気にする人にとっては、結局昔と変わっていないという、ただそれだけのことである。




先に書いたように、ファイルが断片化したからといって、アクセスにかかる時間の増加はわずかである。

普通に使っていて、あまり気にする必要はない。


でも、デフラグには別の効用もある。

その効用を説明する前に、ハードディスクの「記録方法」の話をしておこう。




古いハードディスクは、「角速度一定」という方法で記録されていた。

ディスクを放射状に区切り、記録のための区画とする方法だ。

これだと、外周は区画が大きくなり、内周は区画が小さくなる。


塗られている磁性体の密度は外周も内周も同じなので、内周の記録密度が全体の設計に影響を及ぼす。

外周には記録密度に余裕があっても、その余裕を捨てていたのだ。



古い話だが、Old Macintosh の 3.5inch ディスクは「線速度一定」だった。

これは、外周を読むときは遅く、内周を読むときは速くディスクを回すことで、磁性体に対するヘッドの速度を一定にする方式である。

ヘッドから、一定の速度で信号を読み書きすると、読み書きの区画は放射状には配置されなくなる。

しかし、記録密度としてはどの場所でも一定となり、無駄は生じない。


この方式、フォーマットしたりするとディスクの速度が明らかに変わっていくのが音でわかって面白かったのだが、ハードディスクほどの高回転になると、「回転速度が安定する」のを待つ必要があり、無駄が多いので採用されなった。

(ちなみに、CD や DVD はこの方式だ。速度が遅くてよいメディアでは有効な方式である)



現代のハードディスクでは、記録密度一定方式がとられている。

回転数は変えないが、外周と内周で、ヘッドからの読み書きのスピードを変えるのだ。


記録されたメディアだけを見れば、線速度一定と変わらないように見える。

しかし、回転数は常に一定なので、回転の安定を待つ必要はなくなり、速度を上げられる。


この場合のデメリットは、内周と外周で読み書き速度が明らかに異なることだ。

内周のアクセスは、外周に比べて3倍も遅いことになる。



ここで、ふたたび話は「デフラグの効用」にもどる。

現代的には、デフラグとは「断片化の解消」ではなく、むしろ「頻繁に使われるデータを外周に集める」作業となっている。

もともと、多くの OS でディスクは外周から使っているため、特に初期状態ではほとんどのファイルが外周に集まっていることになるが、しばらく使ってからだと「最近作ったファイルほど内周に」入っている状態になる。


これを外周に出すことができれば、ディスクアクセス速度が体感できるほどあがることになる。

(先に書いた3倍は、読み書き速度のみ。実際には読み書き前のシーク速度の問題もあるし、ソフトウェア的なオーバーヘッドもある。でも、1.5倍速になれば体感できるほどの速度と考えてよい)






デフラグしたほうが良い、とする人々は、明らかに体感速度が上がることを最大の理由とする。

また、測定方法で大きな誤差はあるものの、速度は定量的に測定できるため、科学的なデータも伴う。




一方、デフラグしないほうが良い、とする人々の意見も、無視はできない。

デフラグによる最大のデメリットは、ディスクに対して明らかな負荷をかけることだ。



多くのデフラグソフトで、デフラグの「程度」を選んでデフラグを行うことができる。

単にデフラグを行うだけ、から、よく使うファイルを外周に集める、という作業まで。


デフラグという作業は、結構「場当たり的」なものである。

A というファイルをデフラグするために、後ろにある B というファイルの一部を移動した結果、今度は B にフラグメント(断片化)が生じるかもしれない。

A も B も C も…すべてのファイルが、同時に最短の手数でデフラグできれば良いのだが、そのような計算は複雑すぎて現実的ではない。


これに、さらに「よく使うものを外周に集める」なんて条件をつけると、計算の複雑さは破滅的なことになる。

結果として、一般的なデフラグ作業は、場当たり的に作業を繰り返し、無駄が生じても時間をかけることで全体の作業を終わらせている。


特に、長年使い続け、1度もデフラグをかけていないディスクに対して、「最大効果の」デフラグをかけた場合、ディスクを動かし続ける時間は非常に長くなる。場合によっては1日かかっても終わらない。




ハードディスクは、読み書きがないときは回転速度を落としていることが普通である。

これは、回転することで周囲の空気を巻き込んで渦を作り、空気の摩擦(と圧縮)で熱を持ってしまうためである。


理想を言えば回転を完全にとめてしまえば良いのだが、そうすると次にアクセスが発生したときに回転が安定するまで待つ時間が長くなるため、よほどのことがない限り、適当に速度を落として待機している。


逆に、アクセスし続けると、熱を発生し続けることになる。

そして、磁気記録媒体にとって、一番の敵は「熱」なのだ。

キュリー点を越えると磁性体は完全に磁性を失うが、そこまで行かなくても熱によって磁性は「減衰」するためである。



デフラグによって長時間ディスクが回され、それによって発生した熱によって、ディスクが破壊される、というのは現実味のあるシナリオだ。

これが、デフラグはしないほうがよい、とする人々の最大の論拠だ。


こちらは、可能性を指摘するだけで科学的根拠がない。というか、あげようがない。

実際、ハードディスクが「壊れる」というのであれば故障率を出さなくてはならないが、数千台を使うような実験は実際問題として難しい。



google は、「ハードディスクの故障率と温度は関連性がない」というレポートを出しているが、これは十分に空冷された状況での温度が前提である。

メンテナンスが不十分で、空気流入口にホコリが詰まったような古い PC で、ハードディスクをフル稼働すれば前提となる温度を簡単に超えてしまい、google ですらも「故障しやすい」と認めている温度に突入する。


科学的論拠がないのは弱いところだが、まったくの言いがかりでもない、というところか。






「するべきでない」派の人には、機械を動かせば当然金属疲労を起こして壊れる、という主張をする人もいる。

でも、これはあまり問題でないというか、言いがかりに思える。


ハードディスクの故障のほぼすべては、データが読み出せなくなる、というものだからだ。

この理由は二つで、磁気が弱まってしまったか、物理的にディスクに傷がついたかだ。


金属疲労でヘッドを動かすアームが折れる、というようなトラブルはまず起こらない。


磁気が弱まる理由は、先に挙げた熱もあるが、「記録してから時間がたった」というものも多い。

単に時間がたっただけで、ディスクは(というか記録は)壊れるものなのだ。



「するべき」派の人には、デフラグすることで再記録が行われ、記録が長持ちするようになる、という効用を上げる人もいる。

でも、じつはハードディスクは「読み出した際に、記録が弱まっていれば自動的に書き直す」機能を持っている。


だから、デフラグしたからといって記録が長持ちするようになるわけではないし、そもそも長期間ほったらかしのデータは、断片化を起こすわけもないので、デフラグ時にもほったらかしだったりする。



…などなど、デフラグを「するべき」「するべきでない」の双方に、ほかにもいろいろな主張があるが、怪しいものが多い。





さて、デフラグはするべきか、否か。


自分の答えは、もちろん「するべき」である。だから、先に書いた日記で、デフラグソフトの選定顛末を書いたのだ。


デフラグを「するべき」派と、「するべきでない」派の論争は、ちょっと両極端すぎるように思える。



デフラグというのは、一種のソートアルゴリズムだ。


ソートアルゴリズムはよく研究されているが、どんなアルゴリズムを使用しても、最大の効率を上げるのは「データがすでにソートされている場合」であることがわかっている。

なにもすることがないのだから、当然だ。


デフラグもソートアルゴリズムなのだから、「すでにデフラグされていれば、最大効率」である。

次に効率がよいのは、「ほとんど」デフラグが終わっている場合だ。



つまり、マシンが古くなって、動作が遅くなってきたからデフラグを行おう、では遅すぎる。

そのときには、デフラグをしなくてはならないファイルがあまりにも多すぎて、ハードディスクに大きな負荷をかけることになってしまう。

その負荷の大きさゆえに故障した、という例を持って「デフラグはしないほうがよい」というのは、極端すぎる意見だ。



でも、実は「デフラグをするべき」という人々の中にも、「デフラグ中の並び替え動作を見ているのがすき」という人たちがいる。


こういう人たちは、時々しかデフラグしない。だって、頻繁にやると、すぐにデフラグが終わってしまってつまらないから。

半年に一回とか、一年に一回とか、断片化を十分溜め込んでから、一気にきれいにする。


これだと、デフラグが好きだといっても、やっぱりディスクに負荷がかかる。

まぁ、気持ちはわかるし趣味なのでとやかく言うことではないのだけれど。


(まったくの余談だが、そういう人たちを満足させる、「わざとディスクを断片化させる」ツールまで存在する。

 実際には、デフラグツールを評価する前に、十分に断片化状態を作り出すために作られたツールなのだけどね。)





僕が使うことにした、Smart Defrag 2 では、バックグラウンドで毎日勝手にデフラグを行う。

1回あたりの所要時間は、3分程度。しかも、バックグラウンドで動作しているのが気づかない程度の低負荷で実行している。


この程度の負荷でディスクが熱を持って壊れる、とは思わない。

もしこれで壊れるのなら、普段使いでも壊れるだろう。


週に一度、最適化を行って外周によく使うデータを集めるようにしてある。

これも、かかる時間は10分以内だ。



Smart Defrag ではなく、MyDefrag でも、実行モードとして「Daily Defrag」「Weekly Defrag」「Monthly Defrag」などを用意している。

デフラグ後の状態としては、MyDefrag のほうが評判がよいので、こちらを使うのもよいと思う。


ただし、デフラグ中の動作は、SmartDefrag よりも重いし、時間も長くかかる。

さらにいえば、自動実行させる設定も面倒だ。



いずれにせよ、デフラグツールを作成する側としては、デフラグとは「毎日でも行うもの」であることを前提に考えているのだろう。




最後になるが、断片化している状態、については、どのデフラグツールも見解が一致している。

1つのファイルが分断して記録されていれば、それは誰が見ても「断片化」なのだ。


しかし、断片化「していない状態」については、見解が分かれるようだ。



たとえば、MyDefrag では、頻繁に更新されるデータファイルの後ろは、若干の「空き」があるのが正しい状態だ。

こうしておけば、ファイルが更新されても、デフラグを起こさないから。


でも、できるだけ多くのファイルを外周に詰め込む、という考えを持つと、わずかな「空き」は罪悪である。

ファイルが連続して入っていないということは、これも「断片化」の一種なのだ。


そのため、MyDefrag がきれいに詰め込んだ状態を別のソフトで見ると「デフラグが必要」といわれてしまったりする。



ここら辺になると、宗教論争。

宗教なのだから、自分が信じたデフラグソフト1種類だけを使って、ほかは寄せ付けない、浮気しない、という態度が必要。


もっとも盲信していると、よりよいソフトが出た時に気づかないことになってしまうので、時々世間を知るのはよいように思う。

僕は、以前は MyDefrag を使っていたけど、Windows7 再インストールを機に Smart Defrag2 に乗り換えました。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

古くて非力なマシンをLinuxBeanで再生してみた【日記 15/10/23】

Programming Tips

しつこくデフラグ話【日記 11/11/25】

別年同日の日記

01年 11/23

02年 年賀状印刷ソフト

05年 件のニュースで…

15年 巧妙な確率

19年 保険金おりた

20年 ゲーム&ウォッチ買った

22年 プリンタ不調の顛末


申し訳ありませんが、現在意見投稿をできない状態にしています

しつこくデフラグ話  2011-11-25 10:51:13  コンピュータ

▲目次へ ⇒この記事のURL

別に誰に向かって書いているわけでもないんだけどさ。


2ch なんかのデフラグ関係の話題を読んでいると、デフラグ「すべき」派も「すべきでない」派も、ちゃんと理解しないで言っている節が感じられるもので、ついつい書きたくなってしまう。



Linux にはデフラグが必要ない、という人がいるが、そんなことはない。

デフラグツールなんてなくても、全ファイルを別のディスクにコピーすれば同じこと、という人がいるが、そんなことはない。


現代的な意味において、デフラグは「断片化の解消」よりも、「より高速な外周に、よく使うデータを集める作業」だということは、前回の日記に書いた。




Linux の ext3 は、ファイルの断片化を起こしにくい構造をとっている。これは事実。

でも、それは「ファイルの間に十分な隙間を開ける」ことで行われている。

もし断片化がおきそうなら、より大きな隙間を探してファイルを移動するので、ディスク容量に余裕があるうちは断片化は起こらない。


結果として、外周部分でもデータはスカスカ。使う頻度も特に考慮されない。

ext3 がデフラグを起こしにくい、ということをもって「Windows の NTFS は設計が悪い」という人もいるが、断片化を問題とするか、速度の速い外周を活かそうとするかの思想の違いであって、善し悪しではない。



NTFS では、外周を有効に使う代わりに、断片化を起こしやすい。

そこで、OS自体にデフラグを効率的に行うための仕組みを設けている。


だから、システムを起動して作業をしながらでも、バックグラウンドでデフラグができる。

実はこれはすごいことで、DOS 時代の(Windows98までの時代の)FAT では、システムを停止しないとデフラグできなかった。


おかげで、Windows にはシステム標準でもデフラグがついているし、市販ソフトも、フリーソフトもたくさんある。


一方、Linux にはこのような仕組みはない。

外周は有効に使えないし、断片化が起こってしまった際に解消する仕組みもない。


システムを起動したまま、どころか、停止したとしてもデフラグするためのツールは準備されていない。

ext3 の上位互換である ext4 には、デフラグのための仕組みが備えられた。でも、デフラグツールは開発中で、まだ提供されていない。

(開発途中版を使うことはできるけど、大事なファイルシステムに、バグがあるかもしれないデフラグツールを使いたい人はいるだろうか?)



なので、Linux ユーザーがいう「デフラグの必要がない」は、やりたくてもできないだけ。

外周を十分に使えないから、NTFS よりも遅い。


もっとも、NTFS を長年デフラグなしで使うと、断片化によって極端に性能劣化する。

ext3 ではそのようなことは起こりにくい。(起こりえない、ではない)




で、Linux ユーザーの窮余の策としては「ファイルを全部別ディスクにコピー」だ。

これでデフラグと同じ効果がある、とする。


Windows ユーザーでも、デフラグするとハードディスクの寿命が縮む、と信じている人は同じことを言う。


でも、この方法は、断片化解消にはなるけど、よく使うファイルを外周に再配置することにはならない。

最初に書いたように、現代的な意味でのデフラグの肝は、外周を使う再配置にある。


だから、ディスク丸ごとコピーではデフラグの代わりにならない。


ちなみに、ディスクを丸ごとコピーすれば、ディスクは動作し続けて熱を持つ。

デフラグがハードディスクに悪い、というのであれば、丸ごとコピーも同じようにハードディスクに悪い。

(もっとも、デフラグよりもアクセス時間は短いはずだ。その意味ではハードディスクへの悪影響を最低限に抑えられる。

 理由は、「空の領域に移す」という、究極的に広い作業領域が与えられている上、断片化の解消だけが目的で、再配置が行われないから。)




ちなみに、僕 Linux 使ってますよ。盲信者ではないだけで。




ところで、断片化していなければ読み込み中のシークが発生しない、というのは真実ではない。

不良セクタがあれば、それはハードディスク最内周に準備された「代替領域」に書き込まれるから。


不良セクタの存在は、ハードディスク内で解決されてしまうので、OS からは見えない。

「連続領域に並べた」と思っていても、実は断片化している、という状態になるし、この際「外周に配置した」つもりでも、実は内周に置かれていたりもする。


もっとも、通常のセクタと比較して、不良セクタの存在する割合は非常に低いので、「確率問題として」普通は無視する。



SSD に関しては、はっきり言って知らん。僕は SSD 使ってないので。


XP では、SSD を HDD とみなして動作していたので、デフラグしないと性能劣化した、という。

(SSD の扱えるデータブロックよりも、一般的な HDD の扱うデータブロック(セクタ)のほうが小さい。

 このため、SSD の1ブロックに、HDD の数ブロックを同居させることになる。

 ここで「断片化」がおきていると、1ファイルの書き換えに際して、関係ないファイルも一緒に処理しなくてはならなくなり、結果的に速度が低下する。)


Windows7 では、SSD はちゃんと SSD と認識して動作する。

XP で見られた「HDD のまねをするため」の無駄はカットされ、SSD の性能を十分に引き出す。


デフラグ、もはや過去のものだ。

デフラグとは、HDD に対して必要なテクノロジーであって、SSD の性能を十分に引き出せるのであれば、不要だ。



つまり、3回にもわたってデフラグ話書いたけど、僕が貧乏人でいまだに HDD メインで使っているから、と考えてください。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

古くて非力なマシンをLinuxBeanで再生してみた【日記 15/10/23】

Programming Tips

別年同日の日記

01年 11/24

02年 オムライスとカレー

07年 保育園イベントいろいろ

10年 ディズニーランド公式ホテル

13年 ピエール・ベジェの命日(1999)

16年 マジカル頭脳パワー!!

21年 グノーシア


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -