[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 04/11 13:14 / Filesize : 219 KB / Number-of Response : 895
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:login:Penguin mailto:sage [2008/10/26(日) 15:18:36 ID:VYy55fXH]
過去スレ
 01 pc.2ch.net/test/read.cgi/linux/1006743807/
 02 pc5.2ch.net/test/read.cgi/linux/1063025258/
 03 pc8.2ch.net/test/read.cgi/linux/1101495293/
 04 pc8.2ch.net/test/read.cgi/linux/1136695633/
 05 pc8.2ch.net/test/read.cgi/linux/1152348695/
 06 pc11.2ch.net/test/read.cgi/linux/1173530292/
07
08 pc11.2ch.net/test/read.cgi/linux/1190788761/


596 名前:login:Penguin mailto:sage [2009/01/30(金) 12:16:57 ID:pFX4Hfia]
ジャーナルサイズにも気をつけろ
デフォルト意外に大きいぞ

597 名前:login:Penguin mailto:sage [2009/01/30(金) 13:04:36 ID:WGjS0Meb]
>>592
安定しているというか安全なfsを探していていつも思うのだけど、
「理論は安全・高速です、だけど、開発中なのでリスクがあってチューニングが
足りないです」って言うのに会うたびに悲しくなる。

早く、btrfsが使いもになるようになるといいな

598 名前:login:Penguin mailto:sage [2009/01/30(金) 13:51:31 ID:4mFsvRt0]
>>597
バグのないプログラムは無い、というのと同じ意味だろ。

あとリスクとチューニング不足は別の問題だ。
fsが使える程度で満足しそうな香具師が気にすることでもない。

599 名前:login:Penguin mailto:sage [2009/01/30(金) 19:44:06 ID:TWmxU2Ks]
www.atmarkit.co.jp/flinux/rensai/watch2009/watch01a.html
>これにより、XFSで大きなディレクトリを操作するようなワークロードにおいて最大20倍の高速化が達成されたそうです。

ほほう。

600 名前:login:Penguin mailto:sage [2009/01/30(金) 20:04:47 ID:Z1Th46Ur]
>>599
このスレの上の方で、環境晒してXFSが遅いと豪語していた御仁は
そのページで触れている2.6.28を使用していたようだが……



まあなんていうか
XFS信者 乙

601 名前:login:Penguin mailto:sage [2009/01/30(金) 20:11:28 ID:qnrJLGzh]
ワークロードが違えば結果も違う罠

602 名前:login:Penguin mailto:sage [2009/01/30(金) 20:27:55 ID:BLheTFgw]
他のファイルシステムと比較して遅くなるのには変わりないし。

603 名前:login:Penguin mailto:sage [2009/01/30(金) 20:28:18 ID:TWmxU2Ks]
いや俺XFSなんて使ったこと一度も無いけど。

勝手に他人を信者認定する人ってなんなの?
何故そんな妄想に取り付かれるの?

604 名前:login:Penguin mailto:sage [2009/01/30(金) 20:30:23 ID:xYA3qWmz]
ここにはXFSアンチがいます。
みなさんとっとと虫籠に。



605 名前:login:Penguin mailto:sage [2009/01/30(金) 23:45:30 ID:/3Gy34CB]
>>598
btrfsは今後も同じ構造を保つとは決まっていないと言われてたはずだが、
そう言うリスクは玄人には不要なんですよね、わかります。

606 名前:login:Penguin mailto:sage [2009/01/31(土) 00:00:18 ID:VtRFqVoU]
中毒者なら毎回のデータ移行をむしろ喜びと感じるはず。
ext3でデータ飛ばすのは恥だが、変態^H^Hキワモ^H^H^H先進的なFSで
データを飛ばすことはむしろチャレンジャーの誇りと考える。

主に学生、それも研究室に入るくらいの学生がよくかかる病だ。

607 名前:login:Penguin mailto:sage [2009/01/31(土) 01:00:53 ID:UdXn4NGp]
>>606
学生・学者のくせに先進的でないのなら、そんな奴は
死んだ方が世のため人のためになる。



608 名前:login:Penguin mailto:sage [2009/01/31(土) 01:44:47 ID:SiCmIp4F]
日本のテスターは本家にフィードバックしないで愚痴だけ書くから困る

609 名前:login:Penguin mailto:sage [2009/01/31(土) 01:46:11 ID:SiCmIp4F]
あと、問題が起きましたがあれしてこれしてどれしたのでどれが原因か分かりませんが云々も困る

610 名前:login:Penguin mailto:sage [2009/01/31(土) 02:28:40 ID:XOOgQBBG]
>>608
日本人に限らないけどね。
使うだけでレポートせず文句言うだけの香具師が多いのは。

611 名前:login:Penguin mailto:sage [2009/01/31(土) 02:34:48 ID:iBrfji9Z]
俺なんか自作ファイルシステムとsshサーバと自作webサーバ動かしてるけど障害なんか一度も起こってないよ。
まぁ、運用半年だけど。

612 名前:login:Penguin mailto:sage [2009/01/31(土) 02:35:15 ID:iBrfji9Z]
てか、毎日のようにアップデートしてるからか。

613 名前:login:Penguin mailto:sage [2009/01/31(土) 05:35:35 ID:gKeWExdb]
>>606
Gentooのコンパイルフラグにイロイロ詰め込んでsystemをビルドしちゃったりするあれか

614 名前:593 mailto:sage [2009/01/31(土) 08:53:41 ID:EI2ywcSl]
>>595-596さん素早いレス、ありがとうございました。



615 名前:login:Penguin mailto:sage [2009/01/31(土) 13:34:15 ID:YvHf0PbF]
>>611
みんなのためにうpしてくれ

616 名前:login:Penguin mailto:sage [2009/02/01(日) 20:05:24 ID:SFRK/n3m]
>>607
学生や学者は便利な人柱かよwww

617 名前:login:Penguin mailto:sage [2009/02/01(日) 20:41:56 ID:pKZuj+ox]
>>616
学者は失敗しても成功しても論文にできるんだよ。
失敗したら、この方法はダメだったからもっといい方法を考えないとダメだね、って感じの論文にするわけ。

618 名前:login:Penguin mailto:sage [2009/02/01(日) 21:19:39 ID:zfLT80pe]
失敗しても論文にしとかないと、また同じ方法試をやっちゃう人がでちゃうしね

619 名前:login:Penguin mailto:sage [2009/02/01(日) 22:42:33 ID:kPVbxg7p]
学者がbtrfs使ってる間は
おまいらは黙ってxfsを使え

620 名前:login:Penguin mailto:sage [2009/02/01(日) 23:04:21 ID:8wk+0NmU]
真のチャレンジャーは/をzfs+fuseで使ってるだろ。

621 名前:login:Penguin mailto:sage [2009/02/01(日) 23:41:08 ID:uyWJoLXd]
>>620
/に使えたっけ?

622 名前:login:Penguin mailto:sage [2009/02/01(日) 23:44:45 ID:8wk+0NmU]
/devとかはudev様がtmpfs上に作ってくれるようになったから、頑張れば
いけるかな?そのあたりのでできるかできないか微妙な点まで含めての
チャレンジャーなわけで。

623 名前:login:Penguin mailto:sage [2009/02/01(日) 23:48:53 ID:+d0K0+J0]
>>621
だからこそのチャレンジャーなんだと思うぞ。
FUSEなのに、/を作ったみたいな。

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

624 名前:login:Penguin mailto:sage [2009/02/02(月) 13:08:37 ID:gQtzoShy]
>>623
prepatchのほうは俺の環境じゃまともに動かんかった。どうしてもROになる。



625 名前:login:Penguin mailto:sage [2009/02/03(火) 01:00:53 ID:Dc+aj2Os]
exFAT FS キタ
ttp://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01294.html

626 名前:login:Penguin mailto:sage [2009/02/03(火) 02:30:48 ID:16fezc1a]
>>625
何がきたの?

627 名前:login:Penguin mailto:sage [2009/02/03(火) 07:25:35 ID:n3CI8/1R]
>>626
そのメールの先を読んでいったら、
exFATのroなドライバとかがすでに出てきてる

628 名前:login:Penguin mailto:sage [2009/02/03(火) 08:06:00 ID:LguxkZZC]
「仕様書とかは紐付きってことはなかったの?」
「仕様書?そんなものはない。USBのイメージをリバったんだよ」

でワラタ。

629 名前:login:Penguin mailto:sage [2009/02/03(火) 21:21:36 ID:3/iPgPwE]
基本FATなんだったら難しくないだろうな。

630 名前:login:Penguin mailto:sage [2009/02/03(火) 22:50:14 ID:Z6BDr0uN]
exFAT 構造解析
ttp://homepage3.nifty.com/k-takata/diary/exFAT.txt

631 名前:login:Penguin mailto:sage [2009/02/04(水) 00:00:15 ID:wLEo4sBd]
おがわさんスゲー

632 名前:login:Penguin mailto:sage [2009/02/04(水) 22:29:01 ID:fd0XVi2g]
ext3はディレクトリ内のファイルの数が多かったりすると極端に遅くなるなあ。
xfsやreiserはその点良かったけどこの二つはファイルアクセス時に変にCPUのウエイトが掛かる時があって
他に動いているアプリの動きが妙にもっさりする時があった。

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

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

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

633 名前:login:Penguin mailto:sage [2009/02/04(水) 22:32:40 ID:3f3+oVuU]
ext4を試していない時点でネタ。

634 名前:login:Penguin mailto:sage [2009/02/04(水) 23:02:19 ID:eXgdnCRm]
アンチXFS以外にも長文がいたか



635 名前:login:Penguin mailto:sage [2009/02/04(水) 23:07:07 ID:fd0XVi2g]
>>633
一時期ext4を通常にマウントしただけでextentになってしまう(つまり元に戻らないw)恐ろしいバグがあって、
その時にファイルシステムすっ飛ばして懲りたw

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

636 名前:login:Penguin mailto:sage [2009/02/04(水) 23:23:21 ID:xSbAoH6j]
>>635
ext4がbtrfsまでのつなぎなのは確かだけど、btrfsがFedora以外の
ディストリビューションのデフォルトfsになるぐらいに安定するまで
あと何年かかることやら…

637 名前:login:Penguin mailto:sage [2009/02/05(木) 00:12:22 ID:E5t3i72E]
>>636
Linuxが業務で使われるケースも増えてくるでしょうから、そういった意味では互換性、信頼性を重視してきて
当分ext4が有利になっていくのでしょうけど。でもbtrfsは思ったより早いのではないでしょうか、リーナスの動きがw

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

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

638 名前:login:Penguin mailto:sage [2009/02/05(木) 04:51:29 ID:qGG5jtg5]
>>632
前からいってるじゃん。安定しているって

639 名前:login:Penguin mailto:sage [2009/02/05(木) 07:11:00 ID:bpZOwpx9]
>>637
このスレでもおそらく100回以上ガイシュツだと思いますが、他のOSだとまともな
はずのfsも、Linuxに持ってくると腐ってしまいがちで、結局どのfs使っても性能も
信頼性も低いレベルで似たり寄ったりという批判は身に染みているでしょうしねぇ。
ZFSやHammer FSはライセンス上の問題があったし、btrfsは渡りに船だったでしょう。

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

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

640 名前:login:Penguin mailto:sage [2009/02/05(木) 08:41:43 ID:oMX5twyc]
なんか直接金もらってる発言権の高い開発者グループに対して変なアンチがいるのか?
未実装機能はまだあるにしろ、安定性は高いレベルにある。

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

641 名前:login:Penguin mailto:sage [2009/02/05(木) 09:49:49 ID:IHPIl4eS]
アレな完成度とか、安定性は高い、とかだけここに書かれても

642 名前:login:Penguin mailto:sage [2009/02/05(木) 09:54:24 ID:SdsjlyWA]
文学的表現でファイルシステムを評価するスレはここですか?

643 名前:login:Penguin mailto:sage [2009/02/05(木) 10:03:08 ID:3EwVVprb]
リナスの寵愛を受けたbtrfsは
今後ますます開発に拍車がかかる

私は最終ユーザー

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

644 名前:login:Penguin mailto:sage [2009/02/05(木) 10:16:03 ID:Mbv9FmpT]
ext4の空あけて
オラクル高く輝けば
マージの精気溌溂と
希望は踊る大容量
おお晴朗のブロックに
聳ゆるデータの姿こそ
金甌無欠ゆるぎなき
Linuxの誇りなれ



645 名前:login:Penguin mailto:sage [2009/02/05(木) 12:06:38 ID:Y3Wh0c2C]
>>642
主観による妄想で洗脳しあう文学なんてのは「学」とは名前が付いていても学問じゃねぇ。

646 名前:login:Penguin mailto:sage [2009/02/05(木) 13:11:14 ID:x3zFmMwc]
>>632

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

647 名前:login:Penguin mailto:sage [2009/02/05(木) 13:17:27 ID:1Ft0Lu1H]
このスレで何度も出てるからネタだって事ぐらい分かるだろ。
っていうか、コピペにマジレスすんな。

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

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

649 名前:login:Penguin mailto:sage [2009/02/05(木) 20:41:01 ID:L5hUhHzU]
大きなファイルの削除さえ軽くなればまだまだ
ext3でいいのだが。

650 名前:632 mailto:sage [2009/02/05(木) 23:26:47 ID:wx2VU7dY]
>>646
はい、今の現状で遅く感じます。ただjfsと比べて極端にって訳ではないです。あるディレクトリ配下のファイルなどが
20万個を超えたあたりで差が出てくるような・・ こんなディレクトリを削除したりするにも時間がかかります。

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

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

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

651 名前:login:Penguin mailto:sage [2009/02/05(木) 23:33:30 ID:Hg9okPGr]
>>650
メモリ足りてないよ。dentry canche とか、slabtopで見てみれ。

652 名前:login:Penguin mailto:sage [2009/02/06(金) 00:35:05 ID:jLbt0bn0]
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で用意とか使い分けする手間が面倒くさくて^^;

653 名前:login:Penguin mailto:sage [2009/02/08(日) 10:40:02 ID:E92veWbP]
このスレって、XFS信者とアンチが居ないと、こんなにも寂しいスレだったんだね
前は一日に10〜30レスとかついてたのに、今はまる二日レス無しとか…

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

654 名前:login:Penguin mailto:sage [2009/02/08(日) 11:55:34 ID:256s1t1I]
ext3が遅いだって?あんなの使ってる奴はただ頭が固いだけさ。
素直にJFSを使ってる君は偉い。XFSもおすすめだよ。

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



655 名前:login:Penguin mailto:sage [2009/02/08(日) 12:12:18 ID:7fBjn+3T]
Fedoraで標準採用されてなかったけ?
iiimfぐらいには注目されるだろう

656 名前:login:Penguin mailto:sage [2009/02/08(日) 13:21:55 ID:zMDEiG1i]
>>655 ヒドスw
誰か1台なのに将来を見据えてOCFS2とか噛ましてる奴はおらんの?

657 名前:login:Penguin mailto:sage [2009/02/08(日) 13:32:14 ID:Qn4DOrLe]
そういや、crtime か birthtime って stat(2) でひろえるように(なった|なる)のか?

658 名前:login:Penguin mailto:sage [2009/02/08(日) 19:08:15 ID:Nj6iWNXA]
XFSで起動時にfsckする方法ってあります?
init.dの早いほうに入れればいいのかな・・・

659 名前:login:Penguin mailto:sage [2009/02/08(日) 19:13:30 ID:Gk+PCnhZ]
xfsってfsckできたっけ

660 名前:login:Penguin mailto:sage [2009/02/08(日) 19:14:49 ID:zMDEiG1i]
実行はできるけど、XFSでfsckなんて意味ないだろ。
30行ないんだし、一度読めばわかる。

661 名前:login:Penguin mailto:sage [2009/02/08(日) 19:19:15 ID:vXSExsjO]
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).

662 名前:login:Penguin mailto:sage [2009/02/08(日) 19:27:21 ID:aengWAvq]
>>659
コマンドはあるけど、中身は return(0)してるだけだぞ。


663 名前:login:Penguin mailto:sage [2009/02/08(日) 20:49:31 ID:vOsA2wX1]
さすがFSXO(≧▽≦)O

664 名前:login:Penguin mailto:sage [2009/02/08(日) 20:51:15 ID:vOsA2wX1]
fsckに時間掛けるような2流と一緒にすな~
HDDが10テラとかあったらfsckに何時間かかるんだよ、2流のFSは。



665 名前:login:Penguin mailto:sage [2009/02/08(日) 21:53:05 ID:zMDEiG1i]
>>663,664
ジサクジエーン?(ニヤニヤ

666 名前:login:Penguin [2009/02/10(火) 03:47:27 ID:ELPBun9a]
SSD向きのファイルシステムってどれが良いでしょうか。

667 名前:login:Penguin mailto:sage [2009/02/10(火) 09:15:58 ID:ysOVp1s+]
>>666
フラッシュに依存した難しいことはSSDのコントローラに全部お任せして、
fsは普通のfsを使うというのが今の流れ。ただ、discard requestは
出せたほうがいい。
ttp://www.atmarkit.co.jp/flinux/rensai/watch2008/watch08b.html

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


668 名前:login:Penguin mailto:sage [2009/02/10(火) 10:24:03 ID:Af8aBKdq]
discard requestを出したからといって、現在市場に出回っているSSD側がちゃんとそれを理解して
ウェアレベリングを最適化してるかどうかは怪しい気がするな。

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

669 名前:login:Penguin mailto:sage [2009/02/13(金) 07:49:09 ID:8p5bcu0g]
4GBとか8GBとかならまだしも32GBとか64GBとかのサイズになるともう
寿命で壊れる前に商品価値がなくなって新しいものに目が行くようになる。
ショウジョウバエ並の勢いで世代交代が進んでるから
半年もすると泣けるほどスペックが変わったりする。よな?

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

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

670 名前:login:Penguin mailto:sage [2009/02/13(金) 10:57:44 ID:MuOChzUz]
まあ普通に使ってりゃ使い物になる期間はHDDと大差ないだろうが。

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

671 名前:login:Penguin mailto:sage [2009/02/14(土) 06:15:49 ID:9ZZnCQXv]
stateless linuxてただのpxeboot?

672 名前:login:Penguin mailto:sage [2009/02/14(土) 06:53:50 ID:L1B+yph3]
PXEbootを使ってrootfsを共有するための設定を簡略化するためのツール…じゃないかな

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

673 名前:login:Penguin mailto:sage [2009/02/14(土) 09:35:29 ID:wftwhdGA]
つ 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で処理してるそうだけど詳細不明

の2点かな?

674 名前:login:Penguin mailto:sage [2009/02/14(土) 11:12:03 ID:VMfzi2+P]
宗教ぽいw
redhat ユダヤ人がかぶってる帽子の名前だしな
宗教そのもの



675 名前:login:Penguin mailto:sage [2009/02/14(土) 23:52:47 ID:t28ykXxf]
btrfsて、2.6.27では使えないんでしょうかね。
btrfs-unstable-standalone.gitを採ってきて、2.6.27対応版がlogにあったから
そこまで戻ってコンパイルできて、insmodも出来たのに…mkfs.btrfsしてもmountできない

676 名前:login:Penguin mailto:sage [2009/02/15(日) 08:39:12 ID:99MJzrdu]
>>675
2.6.27 より大人しく 2.6.29 系使え。
ただし、ext4+extents のほうが btrfs より安定してて楽だぞ。

677 名前:675 mailto:sage [2009/02/15(日) 09:35:36 ID:TCLJQKHM]
コメントthxです。
Fedora10上の話を考えているので、今の環境そのままで済むなら楽だなと思いまして…難だと言う事ですね

678 名前:login:Penguin mailto:sage [2009/02/15(日) 11:32:22 ID:ZIq4ioAu]
>Fedora10上の話を考えているので
それ理由になってないだろ(w
まずFedoraの使い方を勉強したほうがいいな

679 名前:login:Penguin mailto:sage [2009/02/15(日) 13:36:32 ID:pIpyvqeo]
何で理由にならない?
btrfsモジュール以外、別に手を入れずにbtrfsを触れるならそうしたいってだけでしょ。

680 名前:login:Penguin mailto:sage [2009/02/15(日) 18:29:23 ID:ZJgJLIMF]
楽をしたいってのと今の時期btrfsを使うってのは究極に反対の意味なんだがw

681 名前:login:Penguin mailto:sage [2009/02/16(月) 01:56:56 ID:HVsyTtjp]
>>675
その btrfs とユーザスペースのバージョンが合ってないんじゃない。
もし btrfs-progs-0.18 で mkfs したのなら、kernel 2.6.29-rc2 以降じゃないと駄目なはず。

682 名前:login:Penguin mailto:sage [2009/02/16(月) 02:52:29 ID:ytdqrJnE]
kernelのビルドの意味自体わかってないようなヤシは放置しとけ。

683 名前:675 mailto:sage [2009/02/16(月) 20:43:00 ID:EIQNz/Hf]
>>681
Thx.
その線ですね、また試してみます。

684 名前:login:Penguin mailto:sage [2009/02/17(火) 00:25:21 ID:9ZUigC3F]
―Sun Microsystemsの「ZFS」など、最近はファイルシステムに関する話題がにぎやかだ。
Linuxもこうした動きに加わるつもりがあるか。
www.computerworld.jp/topics/osst/135711-2.html

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



685 名前:login:Penguin mailto:sage [2009/02/17(火) 00:57:36 ID:yZYtcGBc]
> ZFS, btrfs, ZFSにも言及しています。

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

686 名前:login:Penguin mailto:sage [2009/02/17(火) 03:37:18 ID:cFrq3dg8]
btrfs が安定するのは何年後かな…

687 名前:login:Penguin mailto:sage [2009/02/17(火) 19:15:07 ID:SVUGGIOO]
今までXFSをシステム用パーティションに使っていて特に速度は気にならなかった。
mplayerのアーカイブ展開と削除が遅いと思っていたけど、
ファイルサイズが大きいからだと思っていた。

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

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

688 名前:login:Penguin mailto:sage [2009/02/17(火) 19:36:50 ID:8PuX+ycU]
> 3GBの動画ファイルはスムーズにコピーできるのに、
> 3MB*400個の音楽ファイルはものすごく遅い。
> 散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...

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

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

689 名前:login:Penguin mailto:sage [2009/02/17(火) 21:12:08 ID:DTt/hrVg]
>>688
LinuxのXFSの場合クラスタサイズは4Kbytes、
inodeのサイズは256bytesであってる?

690 名前:login:Penguin mailto:sage [2009/02/17(火) 21:39:46 ID:SVUGGIOO]
> スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ

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

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

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

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

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

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

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

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

691 名前:login:Penguin mailto:sage [2009/02/17(火) 22:06:20 ID:ljmr48rY]
最後の2行以外全くの不要

692 名前:login:Penguin mailto:sage [2009/02/17(火) 23:18:30 ID:ZB4aUO6M]
俺は昔倉庫用のやつだけXFSにした時がある。やっぱりCDやDVDのサイズのコピーなど早かったな。
ルートをXFSにしたら読み込みや検索(これは馬鹿っぱや)は早いけど書き込みが若干遅かったし削除は
やたら遅かった・・ 確かにコンパイルした後のソースディレクトリみたいな小さいファイル大量の削除とか
特に遅かった。

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

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

693 名前:login:Penguin mailto:sage [2009/02/18(水) 08:12:09 ID:me5e3SfY]
メターデータの処理が遅いって何度も出てるじゃん。
で、ジャーナルを別ディスクにしても遅いんだ。

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

694 名前:login:Penguin mailto:sage [2009/02/18(水) 08:55:34 ID:nWWnq0ds]
>>687
あれ?昔聞いた話だと、大量の小さなファイルの扱いは
XFSが得意だと聞いたんだけどな。
Bonnie++でのベンチマーク比較を見れば一目瞭然だろうけど、
どこかにXFSとext3の比較載ってなかったかな・・・。



695 名前:login:Penguin mailto:sage [2009/02/18(水) 09:00:45 ID:nWWnq0ds]
あった。やっぱりXFSの方が早いじゃん。
www.miraclelinux.com/asianux/about/data/17.html

696 名前:login:Penguin mailto:sage [2009/02/18(水) 09:03:48 ID:nWWnq0ds]
>>692
そういえばXFSってCPU使用率が高いんだっけ?
他の処理と平行してコピーとかしてれば、
ext3の方がパフォーマンスが良くなるのかもね。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<219KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef