/ファイルシステム総合スレその 9 /

**login:Penguin** · 2008/10/26(日) 15:18:36

過去スレ
　01 http://pc.2ch.net/test/read.cgi/linux/1006743807/
　02 http://pc5.2ch.net/test/read.cgi/linux/1063025258/
　03 http://pc8.2ch.net/test/read.cgi/linux/1101495293/
　04 http://pc8.2ch.net/test/read.cgi/linux/1136695633/
　05 http://pc8.2ch.net/test/read.cgi/linux/1152348695/
　06 http://pc11.2ch.net/test/read.cgi/linux/1173530292/
07
08 http://pc11.2ch.net/test/read.cgi/linux/1190788761/

**login:Penguin** · 2009/01/31(土) 02:34:48

俺なんか自作ファイルシステムとsshサーバと自作webサーバ動かしてるけど障害なんか一度も起こってないよ。
まぁ、運用半年だけど。

**login:Penguin** · 2009/01/31(土) 02:35:15

てか、毎日のようにアップデートしてるからか。

**login:Penguin** · 2009/01/31(土) 05:35:35

>>606
Gentooのコンパイルフラグにイロイロ詰め込んでsystemをビルドしちゃったりするあれか

**593** · 2009/01/31(土) 08:53:41

>>595-596さん素早いレス、ありがとうございました。

**login:Penguin** · 2009/01/31(土) 13:34:15

>>611
みんなのためにうpしてくれ

**login:Penguin** · 2009/02/01(日) 20:05:24

>>607
学生や学者は便利な人柱かよwww

**login:Penguin** · 2009/02/01(日) 20:41:56

>>616
学者は失敗しても成功しても論文にできるんだよ。
失敗したら、この方法はダメだったからもっといい方法を考えないとダメだね、って感じの論文にするわけ。

**login:Penguin** · 2009/02/01(日) 21:19:39

失敗しても論文にしとかないと、また同じ方法試をやっちゃう人がでちゃうしね

**login:Penguin** · 2009/02/01(日) 22:42:33

学者がbtrfs使ってる間は
おまいらは黙ってxfsを使え

**login:Penguin** · 2009/02/01(日) 23:04:21

真のチャレンジャーは/をzfs+fuseで使ってるだろ。

**login:Penguin** · 2009/02/01(日) 23:41:08

>>620
/に使えたっけ？

**login:Penguin** · 2009/02/01(日) 23:44:45

/devとかはudev様がtmpfs上に作ってくれるようになったから、頑張れば
いけるかな？そのあたりのでできるかできないか微妙な点まで含めての
チャレンジャーなわけで。

**login:Penguin** · 2009/02/01(日) 23:48:53

>>621
だからこそのチャレンジャーなんだと思うぞ。
FUSEなのに、/を作ったみたいな。

まぁ、個人的には次のkernelからbtrfsが入るみたいなので、開発が一気に進むといいな、と。

**login:Penguin** · 2009/02/02(月) 13:08:37

>>623
prepatchのほうは俺の環境じゃまともに動かんかった。どうしてもROになる。

**login:Penguin** · 2009/02/03(火) 01:00:53

exFAT FS キタ
ttp://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01294.html

**login:Penguin** · 2009/02/03(火) 02:30:48

>>625
何がきたの？

**login:Penguin** · 2009/02/03(火) 07:25:35

>>626
そのメールの先を読んでいったら、
exFATのroなドライバとかがすでに出てきてる

**login:Penguin** · 2009/02/03(火) 08:06:00

「仕様書とかは紐付きってことはなかったの？」
「仕様書？そんなものはない。USBのイメージをリバったんだよ」

でワラタ。

**login:Penguin** · 2009/02/03(火) 21:21:36

基本FATなんだったら難しくないだろうな。

**login:Penguin** · 2009/02/03(火) 22:50:14

exFAT 構造解析
ttp://homepage3.nifty.com/k-takata/diary/exFAT.txt

**login:Penguin** · 2009/02/04(水) 00:00:15

おがわさんスゲー

**login:Penguin** · 2009/02/04(水) 22:29:01

ext3はディレクトリ内のファイルの数が多かったりすると極端に遅くなるなあ。
xfsやreiserはその点良かったけどこの二つはファイルアクセス時に変にCPUのウエイトが掛かる時があって
他に動いているアプリの動きが妙にもっさりする時があった。

その点jfsは全然問題なくて使い勝手良い感じがする。今まであまり話題にならなかったから使わなかったけど、
なんでマイナーなのかな。てかHDD容量増えてきてext3の使い勝手が悪くならなきゃ自分もあえてjfsは
使わなかったかも。目立った長所も短所も無いって感じだからマイナーなのか・・

btrfsは一応モジュール組み込んでtoolも入れたけどなんかリーナスが半ば無理やりマージしちゃったみたいで
速攻でバグ出てたって聞いたから試してないや。実はリーナスはこれに期待してるんじゃないだろうか。

今度買うHDDが1Tだけど、まあ少なくともこの容量でext3は個人的にもう使えないな。fsckなんてかかったら
どれ位時間を食うのか・・btrfsが使い物になるまでjfsでいっとこう。

**login:Penguin** · 2009/02/04(水) 22:32:40

ext4を試していない時点でネタ。

**login:Penguin** · 2009/02/04(水) 23:02:19

アンチXFS以外にも長文がいたか

**login:Penguin** · 2009/02/04(水) 23:07:07

>>633
一時期ext4を通常にマウントしただけでextentになってしまう(つまり元に戻らないw)恐ろしいバグがあって、
その時にファイルシステムすっ飛ばして懲りたw

使った期間が短かったし少し前の話だから比較にならないけどext3と比べてそう大差無いような感じだった。
まあ純粋に64ビットの設計なのだろうからディレクトリ内のファイルの数が膨れたりしてもext3のように
遅くならないと思うんだけど。なんとなくext4は短命に終わる気がしないでもない。

**login:Penguin** · 2009/02/04(水) 23:23:21

>>635
ext4がbtrfsまでのつなぎなのは確かだけど、btrfsがFedora以外の
ディストリビューションのデフォルトfsになるぐらいに安定するまで
あと何年かかることやら…

**login:Penguin** · 2009/02/05(木) 00:12:22

>>636
Linuxが業務で使われるケースも増えてくるでしょうから、そういった意味では互換性、信頼性を重視してきて
当分ext4が有利になっていくのでしょうけど。でもbtrfsは思ったより早いのではないでしょうか、リーナスの動きがw

リーナスはZFSが以前から気になっていたけどSunが冷たいらしくライセンスでモジュール化できないとか聞きました。
そこへ来てZFSと似たような仕組みのbtrfsが浮上、半ば無理やりマージしたリーナス。
リーナスは少し前からLinuxに革新的なFSが欲しかったのではないでしょうか。

なんとなくbtrfsはリーナスのひいきになるのではと思ってます。マージしたら開発速度も上がるでしょうし。

**login:Penguin** · 2009/02/05(木) 04:51:29

>>632
前からいってるじゃん。安定しているって

**login:Penguin** · 2009/02/05(木) 07:11:00

>>637
このスレでもおそらく100回以上ガイシュツだと思いますが、他のOSだとまともな
はずのfsも、Linuxに持ってくると腐ってしまいがちで、結局どのfs使っても性能も
信頼性も低いレベルで似たり寄ったりという批判は身に染みているでしょうしねぇ。
ZFSやHammer FSはライセンス上の問題があったし、btrfsは渡りに船だったでしょう。

ただ、それと各ディストリビューションがデフォルトfsとして採用するようになる
ぐらいに完成されるのかは話が別。Solarisですでに動いているZFSをFreeBSDに
移植するのにも結構難儀していること、過去のLinuxのfsの実績を考えると、
楽観的にはなれません。

ext3ベースで拡張するだけのext4ですら、マージされてから次期Fedoraのデフォルト
fsになるまで2年以上かかりましたが、現状のbtrfsはなんでマージしちゃったんだっ
ていうぐらいのとんでもなくアレな完成度ですから。

**login:Penguin** · 2009/02/05(木) 08:41:43

なんか直接金もらってる発言権の高い開発者グループに対して変なアンチがいるのか?
未実装機能はまだあるにしろ、安定性は高いレベルにある。

vfsは根本から置き代わり、読める掛けるだけを軸としたfsレイヤとして活躍することになるだろう。

**login:Penguin** · 2009/02/05(木) 09:49:49

アレな完成度とか、安定性は高い、とかだけここに書かれても

**login:Penguin** · 2009/02/05(木) 09:54:24

文学的表現でファイルシステムを評価するスレはここですか？

**login:Penguin** · 2009/02/05(木) 10:03:08

リナスの寵愛を受けたbtrfsは
今後ますます開発に拍車がかかる

私は最終ユーザー

ただ強いもの、優れたもの、みんなが選ぶものに
日和るだけ

**login:Penguin** · 2009/02/05(木) 10:16:03

ext4の空あけて
オラクル高く輝けば
マージの精気溌溂と
希望は踊る大容量
おお晴朗のブロックに
聳ゆるデータの姿こそ
金甌無欠ゆるぎなき
Linuxの誇りなれ

**login:Penguin** · 2009/02/05(木) 12:06:38

>>642
主観による妄想で洗脳しあう文学なんてのは「学」とは名前が付いていても学問じゃねぇ。

**login:Penguin** · 2009/02/05(木) 13:11:14

>>632

ext3はもう使わなくなって長いんだけど、dir_indexつけても遅いの？

**login:Penguin** · 2009/02/05(木) 13:17:27

このスレで何度も出てるからネタだって事ぐらい分かるだろ。
っていうか、コピペにマジレスすんな。

**646** · 2009/02/05(木) 18:54:59

コピペにマジレスでも何でも良いけど
もうかれこれ2年位前からmke2fsはext[23]にデフォでdir_index付けるんで>>632の環境のように遅くなったりはしない
更に言えば去年の9月位からdir_indexのデフォのハッシュアルゴリズムがteaからhalf_md4に変わって更に速くなった
ようするに>>632のは2年以上前のext3の話ってこと
その位昔のext3はdir_index無しがデフォだったから、確かに>>632のような状況だった

http://e2fsprogs.sourceforge.net/e2fsprogs-release.html
これからこのスレを読む人は↑を読んでからそのレスが単なるアンチレスかどうかを判断したほうが良い

**login:Penguin** · 2009/02/05(木) 20:41:01

大きなファイルの削除さえ軽くなればまだまだ
ext3でいいのだが。

**632** · 2009/02/05(木) 23:26:47

>>646
はい、今の現状で遅く感じます。ただjfsと比べて極端にって訳ではないです。あるディレクトリ配下のファイルなどが
20万個を超えたあたりで差が出てくるような・・　こんなディレクトリを削除したりするにも時間がかかります。

>>648
コピペでもなんでもこっちもどうだっていいですが、現状を言っているだけですのでw
e2fsprogshは1.39からデフォでdir_indexついてますね。つまりdir_indexを付けて早くなったって喜べるのが
既に2年以上前の話って事ですよね。

事実自分もググって得た情報でdir_indexで激的にはやくなるって喜んで試してまるで変化無しで調べたら既にdir_indexついてた
ってのが1年以上前の事です。

それよりもext3のマウントオプションでrelatimeを指定する方法がかなり動きが良くなりましたね。他はジャーナルのモードを
変えたりしてみたけど大した効果は無かったです。

**login:Penguin** · 2009/02/05(木) 23:33:30

>>650
メモリ足りてないよ。dentry canche とか、slabtopで見てみれ。

**login:Penguin** · 2009/02/06(金) 00:35:05

slabtopの見方がよくわかんないけどこんな感じ。

OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
496020 495985 99% 0.13K 16534 30 66136K dentry
257706 257705 99% 0.88K 14317 18 229072K jfs_ip
213056 213056 100% 0.48K 13316 16 106528K ext3_inode_cache

なんかext3はinode_cacheとかを以外と早めに解放しちゃう感じがする。xfsなんかは電源切るまで
かなり保持してるけど、まあ今はxfs使ってないんだけど確かに検索など早かったなあ。

メモリも搭載2Gで32ビットLinuxなんでdmesgはこんな感じ。
[ 0.000000] 1163MB HIGHMEM available.
[ 0.000000] 883MB LOWMEM available.

うだうだ言ってないで64ビットいっとけって事でしょうか・・・　だけど64ってlibも32と64用を用意してアプリまで
これは32で用意とか使い分けする手間が面倒くさくて^^;

**login:Penguin** · 2009/02/08(日) 10:40:02

このスレって、XFS信者とアンチが居ないと、こんなにも寂しいスレだったんだね
前は一日に10～30レスとかついてたのに、今はまる二日レス無しとか…

アンチさん早く出てきてよ
dir_index付けても、付けなくとも速度に変化無し、とか言ってる奴が放置されてますよ
どうやらinode_cacheとext3_inode_cacheの区別もついてないみたいだし、そこら辺についてもよろしくお願いします

**login:Penguin** · 2009/02/08(日) 11:55:34

ext3が遅いだって？あんなの使ってる奴はただ頭が固いだけさ。
素直にJFSを使ってる君は偉い。XFSもおすすめだよ。

ext4が日の目を見ることもないだろうしねw

**login:Penguin** · 2009/02/08(日) 12:12:18

Fedoraで標準採用されてなかったけ？
iiimfぐらいには注目されるだろう

**login:Penguin** · 2009/02/08(日) 13:21:55

>>655 ヒドスｗ
誰か１台なのに将来を見据えてOCFS2とか噛ましてる奴はおらんの？

**login:Penguin** · 2009/02/08(日) 13:32:14

そういや、crtime か birthtime って stat(2) でひろえるように(なった|なる)のか？

**login:Penguin** · 2009/02/08(日) 19:08:15

XFSで起動時にfsckする方法ってあります？
init.dの早いほうに入れればいいのかな・・・

**login:Penguin** · 2009/02/08(日) 19:13:30

xfsってfsckできたっけ

**login:Penguin** · 2009/02/08(日) 19:14:49

実行はできるけど、XFSでfsckなんて意味ないだろ。
３０行ないんだし、一度読めばわかる。

**login:Penguin** · 2009/02/08(日) 19:19:15

If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).

**login:Penguin** · 2009/02/08(日) 19:27:21

>>659
コマンドはあるけど、中身は return(0)してるだけだぞ。

**login:Penguin** · 2009/02/08(日) 20:49:31

さすがFSXＯ(≧▽≦)Ｏ

**login:Penguin** · 2009/02/08(日) 20:51:15

fsckに時間掛けるような2流と一緒にすな~
HDDが10テラとかあったらfsckに何時間かかるんだよ、2流のFSは。

**login:Penguin** · 2009/02/08(日) 21:53:05

>>663,664
ジサクジエーン？（ﾆﾔﾆﾔ

**login:Penguin** · 2009/02/10(火) 03:47:27

SSD向きのファイルシステムってどれが良いでしょうか。

**login:Penguin** · 2009/02/10(火) 09:15:58

>>666
フラッシュに依存した難しいことはSSDのコントローラに全部お任せして、
fsは普通のfsを使うというのが今の流れ。ただ、discard requestは
出せたほうがいい。
ttp://www.atmarkit.co.jp/flinux/rensai/watch2008/watch08b.html

2.6.28でdiscard request出すようになっているんだっけ?

**login:Penguin** · 2009/02/10(火) 10:24:03

discard requestを出したからといって、現在市場に出回っているSSD側がちゃんとそれを理解して
ウェアレベリングを最適化してるかどうかは怪しい気がするな。

現状簡単に出来るのは、とりあえず、mount時 noatime を付けることとか、/tmp を tmpfs にすることや、
RHEL/CentOS なら stateless linux を試してみるとか、それくらい？

**login:Penguin** · 2009/02/13(金) 07:49:09

4GBとか8GBとかならまだしも32GBとか64GBとかのサイズになるともう
寿命で壊れる前に商品価値がなくなって新しいものに目が行くようになる。
ショウジョウバエ並の勢いで世代交代が進んでるから
半年もすると泣けるほどスペックが変わったりする。よな?

小細工で稼げる寿命なんて知れてるぜ。
確実に削れて行くものを長保ちさせる小細工は確かに楽しいけどな。

書き込み寿命でセルが壊れるより、データ保持寿命で電荷が抜ける方が早いぜきっと。

**login:Penguin** · 2009/02/13(金) 10:57:44

まあ普通に使ってりゃ使い物になる期間はHDDと大差ないだろうが。

電荷抜けて…バックアップとって貸金庫にしまったりするんで？

**login:Penguin** · 2009/02/14(土) 06:15:49

stateless linuxてただのpxeboot？

**login:Penguin** · 2009/02/14(土) 06:53:50

PXEbootを使ってrootfsを共有するための設定を簡略化するためのツール…じゃないかな

ちょっと前に調べたときは、まだ開発中という感じでどうやって使うのかよくわからなかった
自分の調べ方が悪いだけかもしれんが

**login:Penguin** · 2009/02/14(土) 09:35:29

つ ttp://fedoraproject.org/wiki/StatelessLinux
> It is not any single technology. It's a new way of thinking

なんか宗教ぽくてあれだな。
どこからブートしてもいいけど、各ノードの状態を100%サーバ側にも保存して
HDDが飛ぼうと別のPCにしようと必ず同じ状態を再現するという思想が新しいって
ことらしい。

ネットブートならSANbootかNFSroot、ローカルブートならHDD imageの
同期ツールを動かすんだってさ。技術的に新しいのは

・単一イメージ・ツリーを元にした多数台のNFSroot/SANboot
　スナップショットとかunionfsを使うのかな？
・HDDイメージの同期処理
　devicemapperで処理してるそうだけど詳細不明

の２点かな？

**login:Penguin** · 2009/02/14(土) 11:12:03

宗教ぽいｗ
redhat ユダヤ人がかぶってる帽子の名前だしな
宗教そのもの

**login:Penguin** · 2009/02/14(土) 23:52:47

btrfsて、2.6.27では使えないんでしょうかね。
btrfs-unstable-standalone.gitを採ってきて、2.6.27対応版がlogにあったから
そこまで戻ってコンパイルできて、insmodも出来たのに…mkfs.btrfsしてもmountできない

**login:Penguin** · 2009/02/15(日) 08:39:12

>>675
2.6.27 より大人しく 2.6.29 系使え。
ただし、ext4+extents のほうが btrfs より安定してて楽だぞ。

**675** · 2009/02/15(日) 09:35:36

コメントthxです。
Fedora10上の話を考えているので、今の環境そのままで済むなら楽だなと思いまして…難だと言う事ですね

**login:Penguin** · 2009/02/15(日) 11:32:22

>Fedora10上の話を考えているので
それ理由になってないだろ(w
まずFedoraの使い方を勉強したほうがいいな

**login:Penguin** · 2009/02/15(日) 13:36:32

何で理由にならない？
btrfsモジュール以外、別に手を入れずにbtrfsを触れるならそうしたいってだけでしょ。

**login:Penguin** · 2009/02/15(日) 18:29:23

楽をしたいってのと今の時期btrfsを使うってのは究極に反対の意味なんだがw

**login:Penguin** · 2009/02/16(月) 01:56:56

>>675
その btrfs とユーザスペースのバージョンが合ってないんじゃない。
もし btrfs-progs-0.18 で mkfs したのなら、kernel 2.6.29-rc2 以降じゃないと駄目なはず。

**login:Penguin** · 2009/02/16(月) 02:52:29

kernelのビルドの意味自体わかってないようなヤシは放置しとけ。

**675** · 2009/02/16(月) 20:43:00

>>681
Thx.
その線ですね、また試してみます。

**login:Penguin** · 2009/02/17(火) 00:25:21

―Sun Microsystemsの「ZFS」など、最近はファイルシステムに関する話題がにぎやかだ。
Linuxもこうした動きに加わるつもりがあるか。
http://www.computerworld.jp/topics/osst/135711-2.html

Linusが今後のLinuxファイルシステムの展望を語っています。
ZFS, btrfs, ZFSにも言及しています。

**login:Penguin** · 2009/02/17(火) 00:57:36

> ZFS, btrfs, ZFSにも言及しています。

ZFSのバターサンドですね、わかります

**login:Penguin** · 2009/02/17(火) 03:37:18

btrfs が安定するのは何年後かな…

**login:Penguin** · 2009/02/17(火) 19:15:07

今までXFSをシステム用パーティションに使っていて特に速度は気にならなかった。
mplayerのアーカイブ展開と削除が遅いと思っていたけど、
ファイルサイズが大きいからだと思っていた。

そんなわけで倉庫用の1TB HDDをすべてXFSでフォーマットして
音楽ファイルや動画ファイルをコピーし始めたんだけど...
3GBの動画ファイルはスムーズにコピーできるのに、
3MB*400個の音楽ファイルはものすごく遅い。

散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...
今からフォーマット変更はできないし、親HDDの空き領域は別のファイルで埋まってる。
仕方ないのでもう１台1TBのHDDを買って、EXT4か何かでフォーマットして、
コピーをやり直そうと思う

**login:Penguin** · 2009/02/17(火) 19:36:50

> 3GBの動画ファイルはスムーズにコピーできるのに、
> 3MB*400個の音楽ファイルはものすごく遅い。
> 散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...

3MBのファイルってのは、一般的に大きいファイルの方に分類されるんだけどな
ちなみに小さいファイルってのはクラスタサイズ以下のファイルの事
まあ人によってはiノードに直接収まるサイズのファイルだけを、小さいファイルと言う人もいるけどね

ついでに言っとくと、XFSは小さいファイルの大量処理が遅いんじゃなくて、単純にファイルの大量処理が遅いんだよ
嘘だと思うなら、スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ

**login:Penguin** · 2009/02/17(火) 21:12:08

>>688
LinuxのXFSの場合クラスタサイズは4Kbytes、
inodeのサイズは256bytesであってる?

**login:Penguin** · 2009/02/17(火) 21:39:46

> スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ

1.2TBのファイル操作の結果なんて、どのファイルシステムでもすぐには分からないよ。

> 単純にファイルの大量処理が遅いんだよ

どうなのかな。
3GBぐらいのファイルを10個ほどコピーしたときはスムーズに感じたけど、
mp3の音楽ファイルになってからは激烈に遅く感じた。

Wikipediaを信用するわけではないけど、
http://ja.wikipedia.org/wiki/ジャーナリングファイルシステム
> 一般にディスク上のファイルシステムに書き込まれるデータには、
> データ自体を現す実データ部分とその実データのディスク上の位置、ファイル名/更新日時、
> アクセス権限などの管理情報を現すメタデータ部分の2種類に分類される。

XFSは実データの書き込み自体は非常に速いんだけど、
メタデータの書き込みが非常に遅いのかなと。

3GB*1くらいのファイルだと、
どのファイルシステムでも実データの書き込みには一定の時間がかかる。
そこが十分に速ければ、
メタデータ処理が遅くても十分太刀打ちできそうに思う。

極端な話、こんな感じ。
XFS (実データ書き込み40秒 + メタデータ書き込み1秒) * 400個 = 16400秒
EXT4 (実データ書き込み50秒 + メタデータ書き込み0.1秒) * 400個 = 20040秒

>>688がすでに「3GBの動画ファイルを400個用意して試してみ」たことがあるのなら、
そうなのかなとも思うけど

**login:Penguin** · 2009/02/17(火) 22:06:20

最後の2行以外全くの不要

**login:Penguin** · 2009/02/17(火) 23:18:30

俺は昔倉庫用のやつだけXFSにした時がある。やっぱりCDやDVDのサイズのコピーなど早かったな。
ルートをXFSにしたら読み込みや検索(これは馬鹿っぱや)は早いけど書き込みが若干遅かったし削除は
やたら遅かった・・　確かにコンパイルした後のソースディレクトリみたいな小さいファイル大量の削除とか
特に遅かった。

でもそれ以上に時々カーネルに変なウエイトが掛かってた。ディスクアクセス時に他のアプリの動きが
やたら遅く、下手したらマウスカーソルまで遅くなった。今のカーネルで使えばまた違うんだろうけど
それ以来XFS使ってないな。

大量のコピー時にも色々な作業するからシステム負荷が軽いのがいいな。だから今はext3とjfsの使い分け。
てかだんだんjfsに移行してる。来年になったらバター犬を試してみたい。

**login:Penguin** · 2009/02/18(水) 08:12:09

メターデータの処理が遅いって何度も出てるじゃん。
で、ジャーナルを別ディスクにしても遅いんだ。

>>692
たまに引っかかるのは俺もあったけど、
dirtyなデータが一定を超えてフラッシュしてるとかじゃないかな？

**login:Penguin** · 2009/02/18(水) 08:55:34

>>687
あれ？昔聞いた話だと、大量の小さなファイルの扱いは
XFSが得意だと聞いたんだけどな。
Bonnie++でのベンチマーク比較を見れば一目瞭然だろうけど、
どこかにXFSとext3の比較載ってなかったかな・・・。

**login:Penguin** · 2009/02/18(水) 09:00:45

あった。やっぱりXFSの方が早いじゃん。
http://www.miraclelinux.com/asianux/about/data/17.html

**login:Penguin** · 2009/02/18(水) 09:03:48

>>692
そういえばXFSってCPU使用率が高いんだっけ？
他の処理と平行してコピーとかしてれば、
ext3の方がパフォーマンスが良くなるのかもね。

**login:Penguin** · 2009/02/18(水) 12:32:18

小さいファイルの処理が速いのは昔からreiserfsと決まってる

**login:Penguin** · 2009/02/18(水) 18:01:16

>>692
> でもそれ以上に時々カーネルに変なウエイトが掛かってた。ディスクアクセス時に他のアプリの動きが
> やたら遅く、下手したらマウスカーソルまで遅くなった。今のカーネルで使えばまた違うんだろうけど

これ、ext3で大きなファイルを削除したときにもなるんだけど、
Linuxでは解決が難しい問題なの？
それとも、JFSにするとかbtrfsの成熟を待つかすればいい話なの？

**login:Penguin** · 2009/02/18(水) 18:05:27

>>698
サーバ用OSとして使うことを前提としたカーネル設計or設定だからかもね。
クライアントOSとして使うのなら、UIで引っかかったり待たせたりしないように
ってのを最優先すべきなんだが。

Mac OS Xなんか使ってると、完全にUI優先なのがよく分かる。
その代わりサーバとして使うと問題ありまくりだけど。

**login:Penguin** · 2009/02/18(水) 18:07:20

>>692
> 時々カーネルに変なウエイトが掛かってた。

たぶんディストリビューションのほうでxfs_fsr(デフラグ)を
定期的にかけてたんだと思う。

俺はCPU使用率は気にならなかったけど、
妙なタイミングでHDDがゴリゴリいいだすのが気になっていた。
xfs_dbでシステム用パーティションのフラグメント状況を調べたら、
1ヶ月以上使っていてパッケージの更新も時々していたにもかかわらず、
ほぼ最適化されていた。

次回はEXT4とReiserFSを試してみるよ。
ReiserFSは以前使ってたけど、開発者が逮捕されて先がないように感じたので使うのをやめていた。
JFSも興味持ったけど、ちょっとマイナーすぎるな。
ZFSは「FUSE経由でZFSを使った場合、出力操作についてはXFSの30～60％の性能しか得られないようだ」。
http://www.itmedia.co.jp/enterprise/articles/0806/27/news052_2.html

Btrfsはまだ不安だし、
http://wiki.livedoor.jp/linuxfs/d/btrfs
> ディスク容量の85%を越えるまではwriteできる。(100%使いきれない)(2009131現在)
というのが気になる

**login:Penguin** · 2009/02/18(水) 18:12:56

書いてしまった後であれだけど、
> カーネルに変なウエイト
ってどういうことだろう。
topでみたときのどのプロセスに当たるんだろう。
「システム全体が重くなる」ぐらいに解釈したけど、
それもあやふやな話だしなあ

**login:Penguin** · 2009/02/18(水) 20:27:15

>>699
いやそういうことじゃないと思う。
(ext3でのファイル削除中に) GUIが遅くなるという表層のものじゃなくて、I/O全般が
固まってるかのような状態になるから、サーバー用途だろうがあまり頂けない状況だと思うが。
ユーザー空間でCPUサイクルを消費し続けるようなプロセスにはあまり影響が無いようなのだけど。

なぜだか理解してないが、ファイルの削除時には、カーネル空間に突入した際にCPUサイクルを
たくさん使う処理が非常に高い優先度でキューに入っていて、ユーザーが発行している
システムコールがどんどん後回しにされているような感覚を受けるレスポンスなんだよね。
色々検索してみたんだが、どういう理由でこうなるのか、なかなか見つけられない。

>>701
XFSも >>692氏の言うように、妙に「カーネルに処理を奪われてる」ようなスループットの悪さが
出るのを経験してるが、xfs_fsrによるものでじゃないと記憶してる。ext3のように、
「数GBのファイルを消してみたら必ず起こる」といった簡単な条件じゃないみたい。

**login:Penguin** · 2009/02/18(水) 21:16:05

>>702
chmod -R のようにジャーナルログが急速に太る処理をやらせると、
swapout不可能なメモリが増えて死ねる。

**login:Penguin** · 2009/02/18(水) 22:03:29

リビングに置いてmp3再生専用のジュークボックスLinuxマシンを組もうと思っていて
静音の為ストレージはSSDにしようかなと思っているのですが
そういう用途でお勧めのFSはなんでしょう？
頻繁に書き込みが発生して寿命が縮むのは嫌ですが
まったくジャーナリングしてくれないのも不安。
無難にext3か。将来が不安なReiser3か。ネタでJFSにするか？

**692** · 2009/02/18(水) 22:07:36

皆レストン。

引っかかるってのはまさに>>702が的確に書いている感じ。HDDのスループットが限界に来たとかCPUの処理量を
超えたとかじゃない、ホントにこっちの処理が後回しになってる感じ。

簡単に言うと例えば何かファイルをネットワーク越しに他のマシンへコピーしてる状態で、何か処理をしてその時にCPU
使用率100%になっても大きくネットワークの転送速度って落ちないでしょう。例えばローカルの処理でHDDのスループット
が限界まで来ちゃったとしてもその間の書き込みや読み出しはHDDの能力にしたがって下がっちゃうけどネットワークの
転送は続くでしょう。

自分の言っている引っかかりってのが出たときは、この状況下だとネットワークの転送が0になります。ガクンっと落ちて
完全に0までいく。まさにその時GUIだけじゃなくてI/O全般が固まってる感じ。

**login:Penguin** · 2009/02/18(水) 22:10:07

>>704
その用途でジャーナリングが必要か？

**login:Penguin** · 2009/02/18(水) 22:13:34

>>704
そんな使い方ならreadが多くてwriteが殆ど無いだろうから、
事実上Write限界による寿命なんて来ない。
つーか、先に他の部分が故障する。
精神安定剤として、少しでもwriteを減らしたいなら、noatime付けときゃいい。

**login:Penguin** · 2009/02/18(水) 22:54:01

あのext3でrmしたときの挙動は何なんだろうね
たとえrm完了がもっと遅くなってもいいから他の処理を邪魔すんなと。

**login:Penguin** · 2009/02/18(水) 22:56:30

>>707
そうですね。
なるべくsyslog吐かないようにとは思っていましたが
noatime付けないと読み出しただけでatime書かれちゃうんでしたか。
Debian Lennyでext4はまだ安定してないかな？

**login:Penguin** · 2009/02/19(木) 14:55:51

>>705
つまりXFSの処理のどこかにネットワークやカーソルにも影響するような
ジャイアントロックがあるのかな？

**login:Penguin** · 2009/02/19(木) 19:39:32

OCFSってどうなん？
使ってみた報告とか皆無なんだが

/**ファイルシステム総合スレ その 9 **/

/ファイルシステム総合スレその 9 /