FLAGS

MENU

NOTICE

2008年7月22日火曜日

リナックスはデフラグ不要? (mixi05-u459989-200807220238)

ミクシ内で書かれた旧おかあつ日記を紹介します。
リナックスはデフラグ不要?
2008年07月22日02:38
http://www.whylinuxisbetter.net/items/defragment/index.php?lang=

今、ファイルフォーマットについて調べているんだけど、そんななかこんな聞き捨てならない話を見つけた。 リナックスを使っていたらデフラグは必要ない? んなわけあるか!

この説明によると、Windowsは、ディスク上の空き領域を、先頭から片っ端使っていくと言うような事が書いてある。 だけどそんなことないと思う。 いくら Windows がバカだといったって、ある程度、空き領域を選んで使っているように見える。 それに Linuxがいくら高性能で、空き領域をきちんと追跡している...っていったって、どんなに正確に追跡しても原理的にフラグメンテーションは必ず起こる。

実際、フラグメンテーションが起こって問題になったケースも聞いたことがある。

それとも、何か僕のまだ知らない何かの方法を使っているんだろうか ... ?



これとかも、すげぇって思えないんだよな...
http://www.whylinuxisbetter.net/items/spatial_desktop/index.php?lang=

これはマックとかにも思うことだけど、実用上の問題として、具体的な性能以上に求められる事がある。 それは互換性だ。 今はハードウェア的に凄く高性能になってきたから、まぁこのビデオにあるくらいの動作は朝飯前だと思う。

しかし、互換性さえ考えなければ、という但し書きがつく。

たかが子供だまし、デスクトップを立体的にグルグルまわしたいがために、どれくらいの使い込んだソフトを捨てて、築き上げてきたデータの資産を捨てる必要があるのだろうか。

彼らは理想主義者すぎる。 たしかに僕も理想主義過ぎるところはあるけど、互換性は重要視している。


一応日本語の翻訳もあった。 あるけど、酷すぎる。 まるで 僕の某マイミクのM君が書いたような翻訳だ。 ワカランよ。 その文体じゃ。 伝わるものも伝わらない。 きちんとコミュニケーションが取れる人が翻訳したとは到底思えない。



コメント一覧
あび   2008年07月23日 21:30
ext2やext3は、FATに比べるとフラグメンテーションを起こしにくいと大学の頃にゼミで教わった。

こういった認識が一般的なので、余計にデフラグツールの開発に取り組む人たちが少ないんじゃ
ないかな。

フラグメンテーションの発生比率が低くて運用上問題にならないと言ってもゼロではないだろう
から、ある特定の使用状況では、ext2やext3でもデフラグは必要になるかもしれないと考えた
方が良さそうだよね。

デフラグ専用のツールが無かったら、ファイルシステムを再構築してバックアップしておいた
tar.gzとかを展開するとかそういう対応しかないのかな・・・・。

う~ん、わからんち。
おかあつ   2008年07月23日 23:02
そのことを教えてくれたのは他でもないM君なんだけどね。 qmail って 送られてくるメールを ディレクトリでハッシュして保存しているらしいんだけど、大規模なメーリングリストなんかを長期間運用していると、ディレクトリエントリがフラグメンテーションを起こすらしくて、恐ろしくスループットが落ちるんだそうだ。

M君は他にも色々な貴重な知識をたくさん持っている人だけど、文章力・コミュニケーション力がゼロ以下でお話にならないので、他の人に説明できないんだよね。

でも、まぁ思ったんだけど、linux もある意味宗教化しているよね ... 。
ねこ☆ミ。   2008年07月24日 00:02
昔、Window NT 3.51が出た頃にFATと比べてNTFSは断片化が起きにくいので
デフラグが不要ですとか、宣伝していた気がする。。。w
おかあつ   2008年07月24日 00:06
そうなんだ...(^^;;
ねこ☆ミ。   2008年07月24日 00:06
リンク先を読みました、、、むむむむ。。。
おかあつ   2008年07月24日 00:19
http://www.itworld.com/nls_unixfrag040929

どっかで、Linuxがフラグメンテーションを起こさないっていう話をする時、ブロックのフラグメンテーションとそれ以外のフラグメンテーションが混同されているので、混乱を引き起こしているっていう話をしているのを聞いたことがあるんだけど、上記の記事によると、なんかディスク内部をシリンダ・クラスタ・セクタ以外に、シリンダグループというカテゴリがあるというようなことが書いてあった。

関連するデータ... 要するに同一のファイルであればできる限り同じシリンダグループに書き込むらしい。 これによってシークタイムを節約できると言うような事が書いてある。

しかし、それでも、フラグメンテーションが起こりづらくなるだけで、使用状況によっては、やっぱり起こるはずだと思う。 特に細かいファイルを作ったり消したりすることが多くなると、今後どのようなファイルの確保が要求されるのかを予知できないディスクとしては、どうしてもフラグメンテーションが起こってしまうはずだ。

(それってよく考えてみたら、まさに qmail のディスクの使い方そのものじゃん)

また、ここには、フラグメンテーション率の調べ方からデフラグのやり方まで書いてあった。

ほらみろ。 やっぱりフラグメンテーション起こるじゃん。

それに、多分だけどNTFSもそれぐらいのことはやっているんではないかと思う。 でなきゃ、もっと速くフラグメンテーション率が上がってもおかしくないと思う。

ねこ☆ミ。   2008年07月24日 00:35
すごい地震だったなぁ。青森は大丈夫かなぁ。

ググりましたが、
断片化が起きないって信じている人が多くて、
技術的なページにたどりつけませんでしたw
ねこ☆ミ。   2008年07月24日 01:12
http://www.atmarkit.co.jp/flinux/rensai/fs03/fs03b.html

こんな動作?

だめだ、一読では理解できない。。。

もう寝ようw
おかあつ   2008年07月24日 01:21
長くて大きい揺れで酔いそうだった...
最初yahooで茨城って表示されてたけど、今見たら青森に変わってた...
大きかったんだね。

カーゴカルトサイエンスっていう言葉があるけど、妄信することなく背後にある理由をきちんと見据えていくって、簡単なようですごく難しい事だよね。


P.S.
カーゴカルトサイエンスっていう言葉自体に結構異論反論がついているっていうことを知らなかった...

http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%BC%E3%82%B4%E3%82%AB%E3%83%AB%E3%83%88
http://www006.upp.so-net.ne.jp/candoli/cargo_index.htm

カーゴカルトサイエンスは西洋の偏見だ、っていう意見で、これはさすがの英語版 wiki にものっていなかった。 恐らく知られていないんだろう。 誰か英訳して載せてくれないかな
おかあつ   2008年07月24日 01:24
http://www.atmarkit.co.jp/flinux/rensai/fs03/fs03b.html

あぁ~~~~~~ (’O’) エクステントってそういう意味だったのか!

これはいい記事だ!
おかあつ   2008年07月24日 01:35
... って一瞬思ったけど、結構はしょりすぎてて、何が言いたいのかわかんないな... ブロック方式 → エクステント方式 っていう順で説明してその違いが説明されているけど、ブロック方式がどんなものなのか詳しい説明がないし、説明のない未知のものに対して違いを説明されても、ワケがわかんない。 ブロック方式って一言に言ったって、星の数ほど実装形式があるわけで、これじゃわからないよね。

しかしながら、エクステント方式という重要なキーワードを得られたので、英語で検索してみる事にしよう。
おかあつ   2008年07月24日 01:38
http://en.wikipedia.org/wiki/Extent_%28file_systems%29


ウヒヒヒヒ たくさんあったよ! 見つけちゃったよ!

そうそう、エクステントって言われてすぐ思い出したのは、オラクルのエクステントサイズのことだったんだけど、ただ単にファイルを拡張する時のサイズのことだと思ってた。 こういう理論的な背後があったんだ

ねこ☆ミ。   2008年07月24日 01:42
ちょっと書いて消したw。

一読してイメージは分かって、
具体的な動作が理解できなかったのだけど、
この文章からは、特定できないのか、、、

明日は、じゃなかった、今日は長いので、お先に寝ます。
おかあつ   2008年07月24日 01:46
http://en.wikipedia.org/wiki/Unrolled_linked_list

エクステントって結局どこにも詳しい説明が書いてなかった。 でも、ふと思ったんだけど、アンロールドリンクトリストというのがあって、ひょっとしたらこれと似た概念なのかもしれないなって思った。

いずれにしても、エクステントっていうのが、何かの製品に組み込まれた独自のアイデアというわけではなくて、コンピューターサイエンスの1つの知識として確立しているものだということは、間違いがなさそうだ。

おやすみなさい(^-^)O
ねこ☆ミ。   2008年07月24日 01:52
An extent is a contiguous area of storage in a computer file system, reserved for a file.

これって、オラクルのテーブルスペースなんかのextentと同じだよなぁ。。。
これをextent sizeを大きくしておけば、断片化が減るけれども、ディスクの無駄が大きくなる。

おかあつ   2008年07月24日 01:55
http://en.wikipedia.org/wiki/File_fragmentation#Techniques_for_mitigating_fragmentation

ここを見る限り、発想としては、unrolled linked list とこの extent とは似たような発想によるものみたいだ。

ねこ☆ミ。   2008年07月24日 01:55
でも、fatだって、クラスタ単位に管理しているし、、、
これってextent sizeと何がちがうのか、、、

http://ja.wikipedia.org/wiki/File_Allocation_Table

眠い時に考えない方がいい。
お先におやすみなさいです。
おかあつ   2008年07月24日 01:58
>これって、オラクルのテーブルスペースなんかのextentと同じだよなぁ。。。

いや、同じってより、そのものなんじゃないかなぁ ...

そのへんどうでしょう。 >> あび氏。

ところで、このコメント欄の一番上におわすおかたは、オラの道のプロの方なので、何でも聞いて大丈夫です。 ... 理論上は。

おかあつ   2008年07月24日 02:00
> でも、fatだって、クラスタ単位に管理しているし、、、
> これってextent sizeと何がちがうのか、、、

僕、ブロックのアルゴリズムって言われるとすぐに思いつくのがFATなのね。
でも、さっきのITMの記事って その感覚で読んでいると、矛盾してくるんだよね... 。

多分だけど、僕の感覚では、ファイルを作る時、ある程度まとまったクラスタを予約しちゃうことをエクステントを作る、ってよんでいるんじゃないかと思う。 わからないけど。
おかあつ   2008年07月24日 02:02
http://en.wikipedia.org/wiki/File_fragmentation#Techniques_for_mitigating_fragmentation

上でもあげたけど、ここで、ファイルシステム上での extent の作り方が説明されてる。
おかあつ   2008年07月24日 02:04
辞書には書いてないけど、このwikiに出てくる 以下の単語って、

proactive 事前対応
retroactive 事後対応

かな。 これって結構便利な言い方じゃないだろうか。
ねこ☆ミ。   2008年07月24日 02:05
fatとextentのちがいは、、、

fat   ファイル内の物理的なリンク情報をデータに埋め込む。
extent  ファイル内の物理的なリンク情報をメタ情報として別に管理する。

書いてみてぜんぜん違う気がする。

おやすみなさい。

あびさん、こんばんは。よろしくです~。

おかあつ   2008年07月24日 02:06
The (now defunct) Commodore Amiga
「今は亡きコモドールアミーガ」

この表現、泣けてくる。
おかあつ   2008年07月24日 02:08
ここでよく、メタデータとファイルの対比が出てくるけど、最近のファイルシステムってひょっとしたらメタデータを1つのファイルとして別扱いしてるのかな。 そうなのかもな...。
おかあつ   2008年07月24日 02:46
atmarkit の記事、前のページにブロックアルゴリズムのなんたるかが書いてあった。
... けど、なんか漠然とした感じは消えないなぁ ...
ねこ☆ミ。   2008年07月24日 02:49
http://en.wikipedia.org/wiki/File_fragmentation#Techniques_for_mitigating_fragmentation
より、

■原文
>Many of today's file systems attempt to preallocate longer chunks, or chunks from different free space fragments, called extents to files that are actively appended to.

■訳
多くの今日(こんにち)のファイルシステムは、エクステントと呼ばれる、より長い塊、または、異なるフリースペースの断片からなる塊を、アクティブに追加するファイルへ事前割り当てしようと試みる。


自分の辞書はProactive は出ているけど、preallocateが出ていない。。。

オラクルって、extent sizeごとにちょびちょび増えていくイメージだと思う。
でも、普通のファイルシステムはがばっとフリースペースの塊とか、フリースペースが断片化されているいくつかの塊を使って、
それの塊をエクステントと呼ぶ?

でも、オラクルも正規化された1レコードみたいなデータでなく、
大きいデータを扱えるからなぁ。その時は、
普通のファイルシステムと同じ動作になるのかも(?_?

というか、もう寝ようZZZzzz。。。
おかあつ   2008年07月24日 02:56
preallocate は alc には出てた。
http://eow.alc.co.jp/preallocate/UTF-8/

けど、pre がつく単語は、「事前にxxする」と訳せることが多いので、この場合も「事前に割り当てられた」と訳せる。

ねこ☆ミ。   2008年07月24日 02:57
だめだ、眠すぎて文章が壊れている。。。

ねこ☆ミ。   2008年07月24日 02:59
extentって物理的につながっていると思っていたのだけど、
断片化されている場合がある?!
おかあつ   2008年07月24日 03:10
http://www.atmarkit.co.jp/flinux/rensai/fs02/fs02b.html

ブロックアルゴリズムとは...

詳しく書いてあるけど、正直、結構読みづらく感じる。
おかあつ   2008年07月24日 03:37
僕、ext2も、 FATみたいな アロケーションテーブルを持っているんだと思ってたら、違うんだね。

これは、extent のこともきちんと理解しないといけないけど、それ以前の問題として B-TREEを理解しないといけないんだと思う。

http://www.atmarkit.co.jp/flinux/rensai/fs02/fs02c.html
http://slady.net/java/bt/view.php
http://www.jbixbe.com/doc/tutorial/BTree.html
http://answers.google.com/answers/threadview?id=510893

atmarkit の記事は凄く詳しいと思う。 図を交えながら詳細まで踏み込んで説明されてる。
でも、どこか漠然としていて読みにくさを感じるのは何故だろう ...。

こういう文章って、どうしても「いきなり飛び出す専門用語」が多くなりがちで、それがふえるとともに推測が増えるからかなと思う。 いきなり O(n) とか O(log(n)) とか言われても、どっちの方が効率がいいのかピンとこないものな...。 それもこちらの勉強不足ではあるんだけど...。

英語版 wiki って そのへんちゃんとしてることが多い様な気がしなくもない...。
おかあつ   2008年07月24日 04:26
おかあつ   2008年07月24日 04:29
おかあつ   2008年07月24日 04:35
http://www.atmarkit.co.jp/flinux/rensai/fs03/fs03b.html

> 2番目に確保されたデータブロックは開始アドレスが210、サイズが1なので、210から211までの大きさである。本来であれば「1+1」が2 番目のデータのオフセットとなるが、ここではオフセットは10となっている。これは、1番目のデータと2番目のデータの間に「10-2=8」のギャップが存在しているためである。実際に使用されているデータは、開始位置から2bytesしかない。

> このギャップは、最初のエクステントデータに書き込みが行われて値が修正されない限り、ほかのプログラムが使用することはできないようになっている。このように、エクステントではスパースに対応したギャップを置くことで、ほかのデータが途中に書き込まれることによるフラグメンテーションを防いでいる。



この説明を読んで理解できるヤツっているのか?
自分だけわかる自分専門用語の羅列。
言葉の説明がないので、何のこと言っているのかさっぱりワケワカラン。

知ってれば「あぁあれのことか」ってピンと来るんだろうけど...
おかあつ   2008年07月24日 04:39
> スパース(Sparse)ファイルとは、データとデータの間に書き込みのないスペースが存在するファイルである。データベースなど、ランダムアクセスが発生するアプリケーションは、データ領域を論理領域として確保する場合があるため、こうしたファイルを生成する。ファイルシステムによっては、空白のブロック部分をディスクに保存せず、データが存在する部分のみを書き込むなどの方法で、こうしたファイルを効率的に管理している。


「データ領域を論理領域として確保する場合がある」 ってなんのこっちゃ。
これよんで「あぁそうそう!論理領域ね!作ってる作ってる!」っていうヤツが居るのだろうか。
居ないだろう、さすがに。 居たら判ったふりしてるヤツだろう。

この人、確かに凄く詳しいけど、文章がナゾ杉。
早稲田大学で助手やっている人らしいけど...。

おかあつ   2008年07月24日 04:56
あび   2008年07月25日 12:42
B-TREE って二分木のことだよね。OracleのINDEXとかで使ってるやつでそ?
おかあつ   2008年07月25日 14:17
腑抜けがぁ! 違うわ!

二分木は Binary Tree!

B-TREEは 色々説があるけど BayerTree とか Balanced Tree とか言われているらしい。

二分木は二股以上分かれないけど、B-TREEは設定によって3つ以上にも分岐する。

でも、Oracleのインデックスとかに使われているヤツではある。

ほめてつかわす。 うむうむ。
 
出展 2008年07月22日02:38 『リナックスはデフラグ不要?』

著者オカアツシについて


小学生の頃からプログラミングが趣味。都内でジャズギタリストからプログラマに転身。プログラマをやめて、ラオス国境周辺で語学武者修行。12年に渡る辺境での放浪生活から生還し、都内でジャズギタリストとしてリベンジ中 ─── そういう僕が気付いた『言語と音楽』の不思議な関係についてご紹介します。

特技は、即興演奏・作曲家・エッセイスト・言語研究者・コンピュータープログラマ・話せる言語・ラオ語・タイ語(東北イサーン方言)・中国語・英語/使えるシステム/PostgreSQL 15 / React.js / Node.js 等々




おかあつ日記メニューバーをリセット


©2022 オカアツシ ALL RIGHT RESERVED