09/01/31 01:00:53 UdXn4NGp
>>606
学生・学者のくせに先進的でないのなら、そんな奴は
死んだ方が世のため人のためになる。
608:login:Penguin
09/01/31 01:44:47 SiCmIp4F
日本のテスターは本家にフィードバックしないで愚痴だけ書くから困る
609:login:Penguin
09/01/31 01:46:11 SiCmIp4F
あと、問題が起きましたがあれしてこれしてどれしたのでどれが原因か分かりませんが云々も困る
610:login:Penguin
09/01/31 02:28:40 XOOgQBBG
>>608
日本人に限らないけどね。
使うだけでレポートせず文句言うだけの香具師が多いのは。
611:login:Penguin
09/01/31 02:34:48 iBrfji9Z
俺なんか自作ファイルシステムとsshサーバと自作webサーバ動かしてるけど障害なんか一度も起こってないよ。
まぁ、運用半年だけど。
612:login:Penguin
09/01/31 02:35:15 iBrfji9Z
てか、毎日のようにアップデートしてるからか。
613:login:Penguin
09/01/31 05:35:35 gKeWExdb
>>606
Gentooのコンパイルフラグにイロイロ詰め込んでsystemをビルドしちゃったりするあれか
614:593
09/01/31 08:53:41 EI2ywcSl
>>595-596さん素早いレス、ありがとうございました。
615:login:Penguin
09/01/31 13:34:15 YvHf0PbF
>>611
みんなのためにうpしてくれ
616:login:Penguin
09/02/01 20:05:24 SFRK/n3m
>>607
学生や学者は便利な人柱かよwww
617:login:Penguin
09/02/01 20:41:56 pKZuj+ox
>>616
学者は失敗しても成功しても論文にできるんだよ。
失敗したら、この方法はダメだったからもっといい方法を考えないとダメだね、って感じの論文にするわけ。
618:login:Penguin
09/02/01 21:19:39 zfLT80pe
失敗しても論文にしとかないと、また同じ方法試をやっちゃう人がでちゃうしね
619:login:Penguin
09/02/01 22:42:33 kPVbxg7p
学者がbtrfs使ってる間は
おまいらは黙ってxfsを使え
620:login:Penguin
09/02/01 23:04:21 8wk+0NmU
真のチャレンジャーは/をzfs+fuseで使ってるだろ。
621:login:Penguin
09/02/01 23:41:08 uyWJoLXd
>>620
/に使えたっけ？
622:login:Penguin
09/02/01 23:44:45 8wk+0NmU
/devとかはudev様がtmpfs上に作ってくれるようになったから、頑張れば
いけるかな？そのあたりのでできるかできないか微妙な点まで含めての
チャレンジャーなわけで。
623:login:Penguin
09/02/01 23:48:53 +d0K0+J0
>>621
だからこそのチャレンジャーなんだと思うぞ。
FUSEなのに、/を作ったみたいな。
まぁ、個人的には次のkernelからbtrfsが入るみたいなので、開発が一気に進むといいな、と。
624:login:Penguin
09/02/02 13:08:37 gQtzoShy
>>623
prepatchのほうは俺の環境じゃまともに動かんかった。どうしてもROになる。
625:login:Penguin
09/02/03 01:00:53 Dc+aj2Os
exFAT FS キタ
URLﾘﾝｸ(lkml.indiana.edu)
626:login:Penguin
09/02/03 02:30:48 16fezc1a
>>625
何がきたの？
627:login:Penguin
09/02/03 07:25:35 n3CI8/1R
>>626
そのメールの先を読んでいったら、
exFATのroなドライバとかがすでに出てきてる
628:login:Penguin
09/02/03 08:06:00 LguxkZZC
「仕様書とかは紐付きってことはなかったの？」
「仕様書？そんなものはない。USBのイメージをリバったんだよ」
でワラタ。
629:login:Penguin
09/02/03 21:21:36 3/iPgPwE
基本FATなんだったら難しくないだろうな。
630:login:Penguin
09/02/03 22:50:14 Z6BDr0uN
exFAT 構造解析
URLﾘﾝｸ(homepage3.nifty.com)
631:login:Penguin
09/02/04 00:00:15 wLEo4sBd
おがわさんスゲー
632:login:Penguin
09/02/04 22:29:01 fd0XVi2g
ext3はディレクトリ内のファイルの数が多かったりすると極端に遅くなるなあ。
xfsやreiserはその点良かったけどこの二つはファイルアクセス時に変にCPUのウエイトが掛かる時があって
他に動いているアプリの動きが妙にもっさりする時があった。
その点jfsは全然問題なくて使い勝手良い感じがする。今まであまり話題にならなかったから使わなかったけど、
なんでマイナーなのかな。てかHDD容量増えてきてext3の使い勝手が悪くならなきゃ自分もあえてjfsは
使わなかったかも。目立った長所も短所も無いって感じだからマイナーなのか・・
btrfsは一応モジュール組み込んでtoolも入れたけどなんかリーナスが半ば無理やりマージしちゃったみたいで
速攻でバグ出てたって聞いたから試してないや。実はリーナスはこれに期待してるんじゃないだろうか。
今度買うHDDが1Tだけど、まあ少なくともこの容量でext3は個人的にもう使えないな。fsckなんてかかったら
どれ位時間を食うのか・・btrfsが使い物になるまでjfsでいっとこう。
633:login:Penguin
09/02/04 22:32:40 3f3+oVuU
ext4を試していない時点でネタ。
634:login:Penguin
09/02/04 23:02:19 eXgdnCRm
アンチXFS以外にも長文がいたか
635:login:Penguin
09/02/04 23:07:07 fd0XVi2g
>>633
一時期ext4を通常にマウントしただけでextentになってしまう(つまり元に戻らないw)恐ろしいバグがあって、
その時にファイルシステムすっ飛ばして懲りたw
使った期間が短かったし少し前の話だから比較にならないけどext3と比べてそう大差無いような感じだった。
まあ純粋に64ビットの設計なのだろうからディレクトリ内のファイルの数が膨れたりしてもext3のように
遅くならないと思うんだけど。なんとなくext4は短命に終わる気がしないでもない。
636:login:Penguin
09/02/04 23:23:21 xSbAoH6j
>>635
ext4がbtrfsまでのつなぎなのは確かだけど、btrfsがFedora以外の
ディストリビューションのデフォルトfsになるぐらいに安定するまで
あと何年かかることやら…
637:login:Penguin
09/02/05 00:12:22 E5t3i72E
>>636
Linuxが業務で使われるケースも増えてくるでしょうから、そういった意味では互換性、信頼性を重視してきて
当分ext4が有利になっていくのでしょうけど。でもbtrfsは思ったより早いのではないでしょうか、リーナスの動きがw
リーナスはZFSが以前から気になっていたけどSunが冷たいらしくライセンスでモジュール化できないとか聞きました。
そこへ来てZFSと似たような仕組みのbtrfsが浮上、半ば無理やりマージしたリーナス。
リーナスは少し前からLinuxに革新的なFSが欲しかったのではないでしょうか。
なんとなくbtrfsはリーナスのひいきになるのではと思ってます。マージしたら開発速度も上がるでしょうし。
638:login:Penguin
09/02/05 04:51:29 qGG5jtg5
>>632
前からいってるじゃん。安定しているって
639:login:Penguin
09/02/05 07:11:00 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
09/02/05 08:41:43 oMX5twyc
なんか直接金もらってる発言権の高い開発者グループに対して変なアンチがいるのか?
未実装機能はまだあるにしろ、安定性は高いレベルにある。
vfsは根本から置き代わり、読める掛けるだけを軸としたfsレイヤとして活躍することになるだろう。
641:login:Penguin
09/02/05 09:49:49 IHPIl4eS
アレな完成度とか、安定性は高い、とかだけここに書かれても
642:login:Penguin
09/02/05 09:54:24 SdsjlyWA
文学的表現でファイルシステムを評価するスレはここですか？
643:login:Penguin
09/02/05 10:03:08 3EwVVprb
リナスの寵愛を受けたbtrfsは
今後ますます開発に拍車がかかる
私は最終ユーザー
ただ強いもの、優れたもの、みんなが選ぶものに
日和るだけ
644:login:Penguin
09/02/05 10:16:03 Mbv9FmpT
ext4の空あけて
オラクル高く輝けば
マージの精気溌溂と
希望は踊る大容量
おお晴朗のブロックに
聳ゆるデータの姿こそ
金甌無欠ゆるぎなき
Linuxの誇りなれ
645:login:Penguin
09/02/05 12:06:38 Y3Wh0c2C
>>642
主観による妄想で洗脳しあう文学なんてのは「学」とは名前が付いていても学問じゃねぇ。
646:login:Penguin
09/02/05 13:11:14 x3zFmMwc
>>632
ext3はもう使わなくなって長いんだけど、dir_indexつけても遅いの？
647:login:Penguin
09/02/05 13:17:27 1Ft0Lu1H
このスレで何度も出てるからネタだって事ぐらい分かるだろ。
っていうか、コピペにマジレスすんな。
648:646
09/02/05 18:54:59 v4Yo9FA3
コピペにマジレスでも何でも良いけど
もうかれこれ2年位前からmke2fsはext[23]にデフォでdir_index付けるんで>>632の環境のように遅くなったりはしない
更に言えば去年の9月位からdir_indexのデフォのハッシュアルゴリズムがteaからhalf_md4に変わって更に速くなった
ようするに>>632のは2年以上前のext3の話ってこと
その位昔のext3はdir_index無しがデフォだったから、確かに>>632のような状況だった
URLﾘﾝｸ(e2fsprogs.sourceforge.net)
これからこのスレを読む人は↑を読んでからそのレスが単なるアンチレスかどうかを判断したほうが良い
649:login:Penguin
09/02/05 20:41:01 L5hUhHzU
大きなファイルの削除さえ軽くなればまだまだ
ext3でいいのだが。
650:632
09/02/05 23:26:47 wx2VU7dY
>>646
はい、今の現状で遅く感じます。ただjfsと比べて極端にって訳ではないです。あるディレクトリ配下のファイルなどが
20万個を超えたあたりで差が出てくるような・・ こんなディレクトリを削除したりするにも時間がかかります。
>>648
コピペでもなんでもこっちもどうだっていいですが、現状を言っているだけですのでw
e2fsprogshは1.39からデフォでdir_indexついてますね。つまりdir_indexを付けて早くなったって喜べるのが
既に2年以上前の話って事ですよね。
事実自分もググって得た情報でdir_indexで激的にはやくなるって喜んで試してまるで変化無しで調べたら既にdir_indexついてた
ってのが1年以上前の事です。
それよりもext3のマウントオプションでrelatimeを指定する方法がかなり動きが良くなりましたね。他はジャーナルのモードを
変えたりしてみたけど大した効果は無かったです。
651:login:Penguin
09/02/05 23:33:30 Hg9okPGr
>>650
メモリ足りてないよ。dentry canche とか、slabtopで見てみれ。
652:login:Penguin
09/02/06 00:35:05 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
09/02/08 10:40:02 E92veWbP
このスレって、XFS信者とアンチが居ないと、こんなにも寂しいスレだったんだね
前は一日に10～30レスとかついてたのに、今はまる二日レス無しとか…
アンチさん早く出てきてよ
dir_index付けても、付けなくとも速度に変化無し、とか言ってる奴が放置されてますよ
どうやらinode_cacheとext3_inode_cacheの区別もついてないみたいだし、そこら辺についてもよろしくお願いします
654:login:Penguin
09/02/08 11:55:34 256s1t1I
ext3が遅いだって？あんなの使ってる奴はただ頭が固いだけさ。
素直にJFSを使ってる君は偉い。XFSもおすすめだよ。
ext4が日の目を見ることもないだろうしねw
655:login:Penguin
09/02/08 12:12:18 7fBjn+3T
Fedoraで標準採用されてなかったけ？
iiimfぐらいには注目されるだろう
656:login:Penguin
09/02/08 13:21:55 zMDEiG1i
>>655 ヒドスｗ
誰か１台なのに将来を見据えてOCFS2とか噛ましてる奴はおらんの？
657:login:Penguin
09/02/08 13:32:14 Qn4DOrLe
そういや、crtime か birthtime って stat(2) でひろえるように(なった|なる)のか？
658:login:Penguin
09/02/08 19:08:15 Nj6iWNXA
XFSで起動時にfsckする方法ってあります？
init.dの早いほうに入れればいいのかな・・・
659:login:Penguin
09/02/08 19:13:30 Gk+PCnhZ
xfsってfsckできたっけ
660:login:Penguin
09/02/08 19:14:49 zMDEiG1i
実行はできるけど、XFSでfsckなんて意味ないだろ。
３０行ないんだし、一度読めばわかる。
661:login:Penguin
09/02/08 19:19:15 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
09/02/08 19:27:21 aengWAvq
>>659
コマンドはあるけど、中身は return(0)してるだけだぞ。
663:login:Penguin
09/02/08 20:49:31 vOsA2wX1
さすがFSXＯ(≧▽≦)Ｏ
664:login:Penguin
09/02/08 20:51:15 vOsA2wX1
fsckに時間掛けるような2流と一緒にすな~
HDDが10テラとかあったらfsckに何時間かかるんだよ、2流のFSは。
665:login:Penguin
09/02/08 21:53:05 zMDEiG1i
>>663,664
ジサクジエーン？（ﾆﾔﾆﾔ
666:login:Penguin
09/02/10 03:47:27 ELPBun9a
SSD向きのファイルシステムってどれが良いでしょうか。
667:login:Penguin
09/02/10 09:15:58 ysOVp1s+
>>666
フラッシュに依存した難しいことはSSDのコントローラに全部お任せして、
fsは普通のfsを使うというのが今の流れ。ただ、discard requestは
出せたほうがいい。
URLﾘﾝｸ(www.atmarkit.co.jp)
2.6.28でdiscard request出すようになっているんだっけ?
668:login:Penguin
09/02/10 10:24:03 Af8aBKdq
discard requestを出したからといって、現在市場に出回っているSSD側がちゃんとそれを理解して
ウェアレベリングを最適化してるかどうかは怪しい気がするな。
現状簡単に出来るのは、とりあえず、mount時 noatime を付けることとか、/tmp を tmpfs にすることや、
RHEL/CentOS なら stateless linux を試してみるとか、それくらい？
669:login:Penguin
09/02/13 07:49:09 8p5bcu0g
4GBとか8GBとかならまだしも32GBとか64GBとかのサイズになるともう
寿命で壊れる前に商品価値がなくなって新しいものに目が行くようになる。
ショウジョウバエ並の勢いで世代交代が進んでるから
半年もすると泣けるほどスペックが変わったりする。よな?
小細工で稼げる寿命なんて知れてるぜ。
確実に削れて行くものを長保ちさせる小細工は確かに楽しいけどな。
書き込み寿命でセルが壊れるより、データ保持寿命で電荷が抜ける方が早いぜきっと。
670:login:Penguin
09/02/13 10:57:44 MuOChzUz
まあ普通に使ってりゃ使い物になる期間はHDDと大差ないだろうが。
電荷抜けて…バックアップとって貸金庫にしまったりするんで？
671:login:Penguin
09/02/14 06:15:49 9ZZnCQXv
stateless linuxてただのpxeboot？
672:login:Penguin
09/02/14 06:53:50 L1B+yph3
PXEbootを使ってrootfsを共有するための設定を簡略化するためのツール…じゃないかな
ちょっと前に調べたときは、まだ開発中という感じでどうやって使うのかよくわからなかった
自分の調べ方が悪いだけかもしれんが
673:login:Penguin
09/02/14 09:35:29 wftwhdGA
つ URLﾘﾝｸ(fedoraproject.org)
> 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で処理してるそうだけど詳細不明
の２点かな？
674:login:Penguin
09/02/14 11:12:03 VMfzi2+P
宗教ぽいｗ
redhat ユダヤ人がかぶってる帽子の名前だしな
宗教そのもの
675:login:Penguin
09/02/14 23:52:47 t28ykXxf
btrfsて、2.6.27では使えないんでしょうかね。
btrfs-unstable-standalone.gitを採ってきて、2.6.27対応版がlogにあったから
そこまで戻ってコンパイルできて、insmodも出来たのに…mkfs.btrfsしてもmountできない
676:login:Penguin
09/02/15 08:39:12 99MJzrdu
>>675
2.6.27 より大人しく 2.6.29 系使え。
ただし、ext4+extents のほうが btrfs より安定してて楽だぞ。
677:675
09/02/15 09:35:36 TCLJQKHM
コメントthxです。
Fedora10上の話を考えているので、今の環境そのままで済むなら楽だなと思いまして…難だと言う事ですね
678:login:Penguin
09/02/15 11:32:22 ZIq4ioAu
>Fedora10上の話を考えているので
それ理由になってないだろ(w
まずFedoraの使い方を勉強したほうがいいな
679:login:Penguin
09/02/15 13:36:32 pIpyvqeo
何で理由にならない？
btrfsモジュール以外、別に手を入れずにbtrfsを触れるならそうしたいってだけでしょ。
680:login:Penguin
09/02/15 18:29:23 ZJgJLIMF
楽をしたいってのと今の時期btrfsを使うってのは究極に反対の意味なんだがw
681:login:Penguin
09/02/16 01:56:56 HVsyTtjp
>>675
その btrfs とユーザスペースのバージョンが合ってないんじゃない。
もし btrfs-progs-0.18 で mkfs したのなら、kernel 2.6.29-rc2 以降じゃないと駄目なはず。
682:login:Penguin
09/02/16 02:52:29 ytdqrJnE
kernelのビルドの意味自体わかってないようなヤシは放置しとけ。
683:675
09/02/16 20:43:00 EIQNz/Hf
>>681
Thx.
その線ですね、また試してみます。
684:login:Penguin
09/02/17 00:25:21 9ZUigC3F
―Sun Microsystemsの「ZFS」など、最近はファイルシステムに関する話題がにぎやかだ。
Linuxもこうした動きに加わるつもりがあるか。
URLﾘﾝｸ(www.computerworld.jp)
Linusが今後のLinuxファイルシステムの展望を語っています。
ZFS, btrfs, ZFSにも言及しています。
685:login:Penguin
09/02/17 00:57:36 yZYtcGBc
> ZFS, btrfs, ZFSにも言及しています。
ZFSのバターサンドですね、わかります
686:login:Penguin
09/02/17 03:37:18 cFrq3dg8
btrfs が安定するのは何年後かな…
687:login:Penguin
09/02/17 19:15:07 SVUGGIOO
今までXFSをシステム用パーティションに使っていて特に速度は気にならなかった。
mplayerのアーカイブ展開と削除が遅いと思っていたけど、
ファイルサイズが大きいからだと思っていた。
そんなわけで倉庫用の1TB HDDをすべてXFSでフォーマットして
音楽ファイルや動画ファイルをコピーし始めたんだけど...
3GBの動画ファイルはスムーズにコピーできるのに、
3MB*400個の音楽ファイルはものすごく遅い。
散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...
今からフォーマット変更はできないし、親HDDの空き領域は別のファイルで埋まってる。
仕方ないのでもう１台1TBのHDDを買って、EXT4か何かでフォーマットして、
コピーをやり直そうと思う
688:login:Penguin
09/02/17 19:36:50 8PuX+ycU
> 3GBの動画ファイルはスムーズにコピーできるのに、
> 3MB*400個の音楽ファイルはものすごく遅い。
> 散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...
3MBのファイルってのは、一般的に大きいファイルの方に分類されるんだけどな
ちなみに小さいファイルってのはクラスタサイズ以下のファイルの事
まあ人によってはiノードに直接収まるサイズのファイルだけを、小さいファイルと言う人もいるけどね
ついでに言っとくと、XFSは小さいファイルの大量処理が遅いんじゃなくて、単純にファイルの大量処理が遅いんだよ
嘘だと思うなら、スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ
689:login:Penguin
09/02/17 21:12:08 DTt/hrVg
>>688
LinuxのXFSの場合クラスタサイズは4Kbytes、
inodeのサイズは256bytesであってる?
690:login:Penguin
09/02/17 21:39:46 SVUGGIOO
> スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ
1.2TBのファイル操作の結果なんて、どのファイルシステムでもすぐには分からないよ。
> 単純にファイルの大量処理が遅いんだよ
どうなのかな。
3GBぐらいのファイルを10個ほどコピーしたときはスムーズに感じたけど、
mp3の音楽ファイルになってからは激烈に遅く感じた。
Wikipediaを信用するわけではないけど、
URLﾘﾝｸ(ja.wikipedia.org)ジャーナリングファイルシステム
> 一般にディスク上のファイルシステムに書き込まれるデータには、
> データ自体を現す実データ部分とその実データのディスク上の位置、ファイル名/更新日時、
> アクセス権限などの管理情報を現すメタデータ部分の2種類に分類される。
XFSは実データの書き込み自体は非常に速いんだけど、
メタデータの書き込みが非常に遅いのかなと。
3GB*1くらいのファイルだと、
どのファイルシステムでも実データの書き込みには一定の時間がかかる。
そこが十分に速ければ、
メタデータ処理が遅くても十分太刀打ちできそうに思う。
極端な話、こんな感じ。
XFS (実データ書き込み40秒 + メタデータ書き込み1秒) * 400個 = 16400秒
EXT4 (実データ書き込み50秒 + メタデータ書き込み0.1秒) * 400個 = 20040秒
>>688がすでに「3GBの動画ファイルを400個用意して試してみ」たことがあるのなら、
そうなのかなとも思うけど
691:login:Penguin
09/02/17 22:06:20 ljmr48rY
最後の2行以外全くの不要
692:login:Penguin
09/02/17 23:18:30 ZB4aUO6M
俺は昔倉庫用のやつだけXFSにした時がある。やっぱりCDやDVDのサイズのコピーなど早かったな。
ルートをXFSにしたら読み込みや検索(これは馬鹿っぱや)は早いけど書き込みが若干遅かったし削除は
やたら遅かった・・ 確かにコンパイルした後のソースディレクトリみたいな小さいファイル大量の削除とか
特に遅かった。
でもそれ以上に時々カーネルに変なウエイトが掛かってた。ディスクアクセス時に他のアプリの動きが
やたら遅く、下手したらマウスカーソルまで遅くなった。今のカーネルで使えばまた違うんだろうけど
それ以来XFS使ってないな。
大量のコピー時にも色々な作業するからシステム負荷が軽いのがいいな。だから今はext3とjfsの使い分け。
てかだんだんjfsに移行してる。来年になったらバター犬を試してみたい。
693:login:Penguin
09/02/18 08:12:09 me5e3SfY
メターデータの処理が遅いって何度も出てるじゃん。
で、ジャーナルを別ディスクにしても遅いんだ。
>>692
たまに引っかかるのは俺もあったけど、
dirtyなデータが一定を超えてフラッシュしてるとかじゃないかな？
694:login:Penguin
09/02/18 08:55:34 nWWnq0ds
>>687
あれ？昔聞いた話だと、大量の小さなファイルの扱いは
XFSが得意だと聞いたんだけどな。
Bonnie++でのベンチマーク比較を見れば一目瞭然だろうけど、
どこかにXFSとext3の比較載ってなかったかな・・・。
695:login:Penguin
09/02/18 09:00:45 nWWnq0ds
あった。やっぱりXFSの方が早いじゃん。
URLﾘﾝｸ(www.miraclelinux.com)
696:login:Penguin
09/02/18 09:03:48 nWWnq0ds
>>692
そういえばXFSってCPU使用率が高いんだっけ？
他の処理と平行してコピーとかしてれば、
ext3の方がパフォーマンスが良くなるのかもね。
697:login:Penguin
09/02/18 12:32:18 pOos/3lo
小さいファイルの処理が速いのは昔からreiserfsと決まってる
698:login:Penguin
09/02/18 18:01:16 T4HijFg4
>>692
> でもそれ以上に時々カーネルに変なウエイトが掛かってた。ディスクアクセス時に他のアプリの動きが
> やたら遅く、下手したらマウスカーソルまで遅くなった。今のカーネルで使えばまた違うんだろうけど
これ、ext3で大きなファイルを削除したときにもなるんだけど、
Linuxでは解決が難しい問題なの？
それとも、JFSにするとかbtrfsの成熟を待つかすればいい話なの？
699:login:Penguin
09/02/18 18:05:27 nWWnq0ds
>>698
サーバ用OSとして使うことを前提としたカーネル設計or設定だからかもね。
クライアントOSとして使うのなら、UIで引っかかったり待たせたりしないように
ってのを最優先すべきなんだが。
Mac OS Xなんか使ってると、完全にUI優先なのがよく分かる。
その代わりサーバとして使うと問題ありまくりだけど。
700:login:Penguin
09/02/18 18:07:20 FGy1ZqOt
>>692
> 時々カーネルに変なウエイトが掛かってた。
たぶんディストリビューションのほうでxfs_fsr(デフラグ)を
定期的にかけてたんだと思う。
俺はCPU使用率は気にならなかったけど、
妙なタイミングでHDDがゴリゴリいいだすのが気になっていた。
xfs_dbでシステム用パーティションのフラグメント状況を調べたら、
1ヶ月以上使っていてパッケージの更新も時々していたにもかかわらず、
ほぼ最適化されていた。
次回はEXT4とReiserFSを試してみるよ。
ReiserFSは以前使ってたけど、開発者が逮捕されて先がないように感じたので使うのをやめていた。
JFSも興味持ったけど、ちょっとマイナーすぎるな。
ZFSは「FUSE経由でZFSを使った場合、出力操作についてはXFSの30～60％の性能しか得られないようだ」。
URLﾘﾝｸ(www.itmedia.co.jp)
Btrfsはまだ不安だし、
URLﾘﾝｸ(wiki.livedoor.jp)
> ディスク容量の85%を越えるまではwriteできる。(100%使いきれない)(2009131現在)
というのが気になる
701:login:Penguin
09/02/18 18:12:56 FGy1ZqOt
書いてしまった後であれだけど、
> カーネルに変なウエイト
ってどういうことだろう。
topでみたときのどのプロセスに当たるんだろう。
「システム全体が重くなる」ぐらいに解釈したけど、
それもあやふやな話だしなあ
702:login:Penguin
09/02/18 20:27:15 T4HijFg4
>>699
いやそういうことじゃないと思う。
(ext3でのファイル削除中に) GUIが遅くなるという表層のものじゃなくて、I/O全般が
固まってるかのような状態になるから、サーバー用途だろうがあまり頂けない状況だと思うが。
ユーザー空間でCPUサイクルを消費し続けるようなプロセスにはあまり影響が無いようなのだけど。
なぜだか理解してないが、ファイルの削除時には、カーネル空間に突入した際にCPUサイクルを
たくさん使う処理が非常に高い優先度でキューに入っていて、ユーザーが発行している
システムコールがどんどん後回しにされているような感覚を受けるレスポンスなんだよね。
色々検索してみたんだが、どういう理由でこうなるのか、なかなか見つけられない。
>>701
XFSも >>692氏の言うように、妙に「カーネルに処理を奪われてる」ようなスループットの悪さが
出るのを経験してるが、xfs_fsrによるものでじゃないと記憶してる。ext3のように、
「数GBのファイルを消してみたら必ず起こる」といった簡単な条件じゃないみたい。
703:login:Penguin
09/02/18 21:16:05 Sto/47zW
>>702
chmod -R のようにジャーナルログが急速に太る処理をやらせると、
swapout不可能なメモリが増えて死ねる。
704:login:Penguin
09/02/18 22:03:29 1W/ybCbq
リビングに置いてmp3再生専用のジュークボックスLinuxマシンを組もうと思っていて
静音の為ストレージはSSDにしようかなと思っているのですが
そういう用途でお勧めのFSはなんでしょう？
頻繁に書き込みが発生して寿命が縮むのは嫌ですが
まったくジャーナリングしてくれないのも不安。
無難にext3か。将来が不安なReiser3か。ネタでJFSにするか？
705:692
09/02/18 22:07:36 IcJM0mVg
皆レストン。
引っかかるってのはまさに>>702が的確に書いている感じ。HDDのスループットが限界に来たとかCPUの処理量を
超えたとかじゃない、ホントにこっちの処理が後回しになってる感じ。
簡単に言うと例えば何かファイルをネットワーク越しに他のマシンへコピーしてる状態で、何か処理をしてその時にCPU
使用率100%になっても大きくネットワークの転送速度って落ちないでしょう。例えばローカルの処理でHDDのスループット
が限界まで来ちゃったとしてもその間の書き込みや読み出しはHDDの能力にしたがって下がっちゃうけどネットワークの
転送は続くでしょう。
自分の言っている引っかかりってのが出たときは、この状況下だとネットワークの転送が0になります。ガクンっと落ちて
完全に0までいく。まさにその時GUIだけじゃなくてI/O全般が固まってる感じ。
706:login:Penguin
09/02/18 22:10:07 /cuS6lKA
>>704
その用途でジャーナリングが必要か？
707:login:Penguin
09/02/18 22:13:34 T4HijFg4
>>704
そんな使い方ならreadが多くてwriteが殆ど無いだろうから、
事実上Write限界による寿命なんて来ない。
つーか、先に他の部分が故障する。
精神安定剤として、少しでもwriteを減らしたいなら、noatime付けときゃいい。
708:login:Penguin
09/02/18 22:54:01 1O7/we0+
あのext3でrmしたときの挙動は何なんだろうね
たとえrm完了がもっと遅くなってもいいから他の処理を邪魔すんなと。
709:login:Penguin
09/02/18 22:56:30 1W/ybCbq
>>707
そうですね。
なるべくsyslog吐かないようにとは思っていましたが
noatime付けないと読み出しただけでatime書かれちゃうんでしたか。
Debian Lennyでext4はまだ安定してないかな？
710:login:Penguin
09/02/19 14:55:51 z04j4qzs
>>705
つまりXFSの処理のどこかにネットワークやカーソルにも影響するような
ジャイアントロックがあるのかな？
711:login:Penguin
09/02/19 19:39:32 Lb+Jk4NK
OCFSってどうなん？
使ってみた報告とか皆無なんだが
712:login:Penguin
09/02/19 19:54:51 pOrVrzb0
2.6.28でXFSも速くなるようなのが入ったみたいだけど、速くなった感じがしない。
713:login:Penguin
09/02/19 23:30:57 3shEVFBp
WinXPとUbuntuの両方で外付けHDDを使うんだけど、
ファイルシステムはどうするべきだと思う?
NTFSかext3のどちらかだと思うが、
どちらが互換性やパフォーマンスの面で障害が少ないのか?
714:login:Penguin
09/02/19 23:38:13 cCKDE498
>>713
なんで人に聞くの？
715:login:Penguin
09/02/19 23:44:45 Z25DcziU
>>713
外付けHDDを2つ買って、一個をNTFS、もう一個をext3にすればいい。
716:login:Penguin
09/02/20 00:06:24 TEwNW093
>>713
悩むならFATにしとけばいいんでないかと思う。
どっちでも確実に読み書きできるし。
717:login:Penguin
09/02/20 00:51:17 hX26sJzO
>>713
パーミッションのことを考えると外付けをext3(かreiserfs)とNTFSの二つのパーティションに区切った方が良い予感。
718:login:Penguin
09/02/20 02:59:22 2k7EPZJe
>>711
OCFS2なら正直、イイ！よ。
GFSとかOpenGFSで泣いてた人にとっては神のようなクラスタFSだわ。
性能もかなりまっとう。LVS+SANとかLVS+DRBDを併用すれば簡単に
クラスタシステムを組み上げられるのは最高です。
719:login:Penguin
09/02/20 03:28:53 rWFxWd60
外部ログをSSDに乗っけてる人っている？
720:login:Penguin
09/02/20 07:56:35 4rQ+o/wl
>>713,716
FATはファイルサイズの上限が低くて(俺には)使いにくかった。
最近のディストリビューションならNTFSで良いと思うけど。
721:login:Penguin
09/02/21 06:48:33 diXlsjkP
>>718
おお、そうなのか。正直感想がなさ過ぎて迷ってたw
今度入れてみる
722:login:Penguin
09/02/21 10:02:48 Z5GPRaK3
iSCSIがかなり普及しつつあるのに、クラスタ対応fsのほうは全然なんだよねぇ。
723:login:Penguin
09/02/21 10:51:51 ol94TBik
>720
一度ハデに壊してから追ってないのでよく知らないが、
NTFSへの書き込みってちゃんと動くようになったの？
724:login:Penguin
09/02/21 16:52:53 PagV8OCn
ntfs-3gでとりあえず動いてます。
常用はしていない
725:login:Penguin
09/02/21 17:28:03 8YMgGvyx
>>723
>>720ではないけど、
実データが壊れたことは一度もない。
ただLinux側からNTFSパーティションのデータを削除すると
見かけ上データは消えているのに空き領域が増えないことはあった。
例えば50GBのNTFSパーティションで
"du *" が5GBなのに
"df" だと残容量が10GBしかないみたいな。
Windows側でもいろいろ操作していたので
Linux側のせいとも言い切れないんだけど。
結局chkdskを実行したら正しい空き容量に戻った。
そんなことが何回かあったが、
ここ2ヶ月ぐらいは不具合はおきてない。
NTFS-3GはCPU負荷がかなり高いので、そこだけが気になる
726:login:Penguin
09/02/21 19:01:39 b/h0+KPy
>>723
カーネル付属のntfsの事は忘れろ
727:login:Penguin
09/02/21 22:28:52 ol94TBik
>724-726
さんくす。カーネル外のやつ探すなんて思い付きもしなかった。
ntfs-3gいろいろウオッチしてくる。
カーネルのがアレなせいでずっと>716状態なんだわ。
728:login:Penguin
09/02/22 09:55:44 w1DGhqfd
クローズドなNTFSを無理やり実装したものよりも、
オープンなext3をWindowsに移植したものの方が安心できそうなんだけど。
現在の実装だとntfs-3gの方が安定してるの？
729:login:Penguin
09/02/22 10:26:21 beSgjmV0
>>728
何と何を比べているの？
730:login:Penguin
09/02/22 10:45:51 w1DGhqfd
Ext2IFS と ntfs-3g
731:login:Penguin
09/02/22 12:18:41 stOI91h6
ちなみにntfs-3gはかなり安定している。これにはコツがあってLinuxでntfs-3gを使うならなるべくLinuxだけ
それにアクセスするようにしといた方がいい。まる2年ntfs-3gを使っているけどノントラブル。
実際はWINと共用する時も多いだろうからその時の注意点はファイルが閉じきらないうちにOSを終了したとき、
特にWINDOWSの場合は異常終了したWINがLinuxの扱うNTFS領域にアクセスしていた場合必ずまたWINを
起動させて正常終了させとかないとたまに変になる。
732:login:Penguin
09/02/22 12:42:20 Yqyj03NJ
LinuxからだけアクセスするNTFSに何の意味があるのか
733:login:Penguin
09/02/22 12:54:50 stOI91h6
>>732
いいツッコミだ
734:login:Penguin
09/02/22 16:04:11 tLUpC+31
vxfsﾏﾝｾｰ
735:login:Penguin
09/02/22 17:17:32 HZYCnhHX
今後は複数のOSで利用する可能性があるものはexFATにしておけって感じになるのかな?
736:login:Penguin
09/02/22 18:48:45 U800G2ZZ
LinuxからはNTFSと似たような立ち位置になるんじゃね
多分ポストFATにはならん
737:login:Penguin
09/02/23 00:35:04 OM5UFZHj
exFATを見るとどうしてもextra fat(超デブ)が連想されしまう
738:login:Penguin
09/02/23 00:41:09 vF6Q5d6I
どれでもそれなりに使えるFSがないのが痛いねぇ
リムーバブルメディアには重要だと思うんだけど
739:login:Penguin
09/02/23 01:09:00 AeFg25fy
それこそオープンソースで誰でも使えて機能・安定性ともガチ鉄板
みたいなファイルシステムが、一つは欲しいよねえ…
このさい速度はあまり速くなくても構わんよ
つうかext2/3あたりがどうしてWindowsに移植されたりしないのかと
740:login:Penguin
09/02/23 01:28:37 rKbUvqb5
安定性、機能では多分NTFS>ext3だと思うよ。
741:login:Penguin
09/02/23 01:29:56 gfs0EQ4Z
>739 つうかext2/3あたりがどうしてWindowsに移植されたりしないのかと
されてるように見えるが > EXT2IFS
742:login:Penguin
09/02/23 01:31:51 rKbUvqb5
EXT2IFSってWINから自由にext3に書き込んだり出来るの?
743:login:Penguin
09/02/23 11:15:16 KfjF9GSX
一番の問題は、ファイルシステムとパーミッションの関係
744:login:Penguin
09/02/23 14:23:29 EloijtZT
ext3ifsってinodeのサイズでうまくいかなかったな、俺の環境では。
inodeのサイズをいじるくらいなら、最近ではLinuxですくなり使えるNTFSの方がいいと思った。
745:login:Penguin
09/02/23 14:26:20 i5dtDe8U
exFATにはACL機能が入っている。ところが、Vista SP1では未実装…
746:login:Penguin
09/02/23 15:14:41 vF6Q5d6I
ocfsあたりをwindows向けも配布してくればいいのに
実績もあるし、今更出し惜しみするほどのものでもないでしょ
747:login:Penguin
09/02/23 19:00:54 N2jXG+uY
ZFSをネイティブに使いたいばかりに
opensolarisに行ってしまって
そのまま帰ってこない人とか出てくるんだろうか。
748:login:Penguin
09/02/23 19:03:07 RMEIkcBQ
ZFSはメモリ使用量が・・・
749:login:Penguin
09/02/23 19:59:02 KfjF9GSX
バカが使ってから気づくんじゃないか
750:login:Penguin
09/02/23 20:09:14 nJBZND0X
>>739
ocfs2
751:login:Penguin
09/02/23 20:19:25 +UjaXVVu
>>745
要るか？
それこそNTFS使えよって話じゃね
752:login:Penguin
09/02/23 22:58:42 XOl4kN7J
>>751
そりゃHDDやらSSDならそうだろうけど、SDカードとかは
PCよりも、他のところで使うことの方が多いわけで。
753:login:Penguin
09/02/23 23:27:49 8h0TqS0R
複数環境で共有すればACLは無い方が都合がいいと思う
754:login:Penguin
09/02/24 00:48:04 PNU47U+F
俺もそう思う
別環境で設定したACLなんて無意味だし
755:login:Penguin
09/02/26 22:25:47 tsF5+r8X
SDカードとかそんなのはセキュリティなんて有って無いような物だし、中身が消えても大したもんじゃないしね。
756:login:Penguin
09/02/27 06:09:10 r6OMqEB7
>実際はWINと共用する時も多いだろうからその時の注意点はファイルが閉じきらないうちにOSを終了したとき、
>特にWINDOWSの場合は異常終了したWINがLinuxの扱うNTFS領域にアクセスしていた場合必ずまたWINを
>起動させて正常終了させとかないとたまに変になる。
その症状、Linux側でマウントするときジャーナルからの復旧が行われてないのでは。
ntfs-3gがジャーナルに対応してないとか。
757:login:Penguin
09/02/27 06:22:16 r6OMqEB7
ちょっと調べてきたので書かせてもらうと、
ntfs-3gはジャーナルの書き込みは出来るけど
ジャーナルからの復旧は出来ないらしい。
Linuxだけで使う分には問題ないのは元々ジャーナルを当てにしていないのかもしれない。
WindowsだけでNTFSを使う時に問題ないのはジャーナルにきちんと対応しているから。
Windowsで使っていて正しくアンマウントし損ねた後にntfs-3gでマウントするとおかしくなると。
758:login:Penguin
09/02/27 06:25:33 r6OMqEB7
WindowsからもLinuxからも安定して使えるFSとしてUDF2.01はどうだろうか？
各OSとの互換性を重視して一通りの属性を備えている点がポイントだけど
759:login:Penguin
09/02/27 11:36:03 rFrhZlUn
>>755
でも、SDカードの大容量化で外付けHDD的に使う人が出てくると、ACL必須。
規格としてはあったほうがいい。
760:login:Penguin
09/02/27 11:41:54 QDEi4t0U
FATの上にext3を乗っければいいじゃない。
761:login:Penguin
09/02/27 12:33:13 o2Mjgcyd
>>757
なるほど、納得した。
>>759
根本的に何を求めるための物かはっきりしてないとコケるよ。SDカードを外付けHDDとして利用する人が
何を求めるかとか根本的な問題。
ノート型PCでやたら性能良いCPU積んでとっても重くなった上にバッテリーももたないなんてモデルがあった。
性能良いからちょっと高くてもデスクトップでも使えるなんて思って買った。
コケたねw 重くて外に持ち歩く気がしないし直ぐにバッテリ無くなるし。
変に色々機能足して肥大化して安定性や速度に影響でたりしたら結局使えない中途半端FSで消えてくんじゃないかな。
762:login:Penguin
09/02/27 12:35:01 Kp8y2VVq
安定性はともかく、速度はそれほど求められないんじゃないの
使いやすいさのほうが重要だね
763:login:Penguin
09/02/27 12:45:05 UAfggC9g
>>757
確かに復旧は出来ないんだが、それが必要な状態なら一度Windowsを起動しろとメッセージを出して、
forceオプションをつけない限りマウントさせないと思うのだけれどね……
-o forceしてしまえば
> The logfile will be unconditionally cleared.
ってことでおかしくなるのもわかるんだが。
764:login:Penguin
09/02/27 20:26:16 mryp32nH
>>761
脳みそが１０年前で止まりました
こうですか？
765:login:Penguin
09/02/27 21:03:17 o2Mjgcyd
>>764
そうですね
766:login:Penguin
09/02/28 14:12:20 czwrTfys
いまどきext3なんて使ってる奴いるの？馬鹿？
767:login:Penguin
09/02/28 14:25:45 8lhPQ1EQ
>>766
うちはみんなext3だよ
768:login:Penguin
09/02/28 15:23:19 JwdYPYzY
まだext2が残ってたり…
/bootだけど
769:login:Penguin
09/02/28 17:22:43 aNwKJdXE
なんとなく、このスレ見ている人はほとんどがext3のような気がする
でもってほとんどが個人のデスクトップ仕様のような気がする
だから最適は自然とext3のような気がする
所詮個人デスクトップのfsを変えてもほとんどが自己満足のような気がする
770:login:Penguin
09/02/28 18:55:55 3GTmrs/s
もっと自信を持て
771:login:Penguin
09/03/01 02:52:29 K/NlP2TL
「作成日時」が保存できるext4に期待してたりする。
sambaを使ったファイルサーバーにおいて互換性が上がる。
772:login:Penguin
09/03/01 03:49:40 gD2Mfu4Y
>>771
Fedoraでext4試してるけど、sambaは使ってないな。
773:login:Penguin
09/03/01 10:11:23 66aHl2zT
>>769
reiserfs一択ですが何か？
Mad FS作者Hansカムバーック！！！
774:login:Penguin
09/03/01 14:42:54 ssL6mAXv
>>769
＞所詮個人デスクトップのfsを変えてもほとんどが自己満足のよう
＞な気がする
そうです。サーバ用途など特化した物でなければ何でも良い。
775:login:Penguin
09/03/03 21:38:43 NKr7FQ8a
こんにちは。
ls -laで出てくるファイルサイズの合計と
df -hで出てくる使用量の値が大きく
違っているって、どんなことが考えられますか？
Debian 5.0（AMD64）上にVMwareServer2.0を
入れて、XFS上に仮想ディスクを「allocate all disk space now」
としてファイルは2G分割で40GByte作りました。
ls -la すると、2Gのファイルが合計40GByte
になるように多数、ファイルができているように
見えるのですが、df -hすると、数MByte（数十だったかな）
程度しか消費していない...
「allocate all disk space now」やってないと、
最初は小さいファイルが少しできる
はずだから、操作ミスはしてないと思うんだが...
で、そこにWindowsをインストールすると、ls -la
で出てくるファイルサイズは変わらないように
見えるんだけど、df -hの表示は、徐々に増える...
空の40Gの仮想ディスクをNTFSフォーマットすると、
4,5時間かかる勢い...（遅...）
同じような環境はいくつあるけど、こういう現象には
はじめて、あった。何が起きているんだ...
776:login:Penguin
09/03/03 21:52:39 qXmTBZnJ
sparse file
ls -lsh
777:775
09/03/03 22:16:30 NKr7FQ8a
ありがとうございます！
「VMware Server の Web UI から、事前割当・2G 分割を指示しても
sparse fileを作りやがります。」という記事も見かけたので、大きい
ファイルをあまり作らなかったため、単に、気づいていなかっただけなのか。
URLﾘﾝｸ(blog.woremacx.com)
vmware-vdiskmanager使うことも考えます。
778:login:Penguin
09/03/04 10:42:21 uN0jlBSw
HANS REISER
Hans Reiser
779:login:Penguin
09/03/04 14:19:22 HYrKyMtS
ubuntu9.04でext4で/を作って運用中。ubuntuのカーネルも2.6.28なんだけど、一応最新の安定版2.6.28.7を
kernel.orgより落として自己ビルド。tune2fs -lでこんな感じ。
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery
extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
findコマンドとかばかっぱやになってますね。アプリのmekeなんかも端末を流れる文字の早さが違う。
780:login:Penguin
09/03/04 20:55:03 Gpey/fcN
どうせやるならmount optionにjournal_async_commitも付けてみ。
781:login:Penguin
09/03/04 22:35:19 PTgFZXPi
>>780
しったか君乙
とりあえずext4/super.c嫁
journal_async_commitはデフォルトで有効だ
782:login:Penguin
09/03/05 00:48:54 3fH/NsnT
卑しい揚げ足のとり方だなw
まるで野党だ
783:login:Penguin
09/03/05 01:08:15 7fO1LWAQ
Dragonfly BSDのHammer FS、かなり使い物になる模様。
開発のマンパワーが圧倒的に足りないはずのHammerの出来がまあまあとなると、
btrfsも意外と早く使い物になる可能性も。
784:login:Penguin
09/03/05 01:19:54 xpefxS/h
本当にデフォルトでjournal_async_commitが有効なら別に揚げ足じゃないと思うけど
785:login:Penguin
09/03/05 01:43:33 4599paQ+
何故かイメージ悪いが、ext4はかなり使い物になる印象
もっとも、ファイルシステムは数年使って判断すべきものだが
786:login:Penguin
09/03/05 01:48:05 7EIm6RPk
>>785
イメージが悪いなんて初耳だ。
787:login:Penguin
09/03/05 02:09:01 Wh17oSuT
一部でbtrfsまでの腰掛けみたいな評価だからな
788:login:Penguin
09/03/05 02:58:45 7fO1LWAQ
ext3の正統後継者なのは確かだけど、btrfsまでのつなぎなのも確かでしょ。
ZFS以降のfsとは機能的に世代がはっきり古いのだし。
789:login:Penguin
09/03/05 06:57:46 g88+Gtda
>>786
この辺限定じゃないかい。
790:login:Penguin
09/03/05 07:11:00 5YrGNOjR
>>785
イメージ悪くないよ。reiserfsから乗り換えるか迷ってるぐらい事前の評判は良い。
791:login:Penguin
09/03/05 09:43:04 owUQEQTk
私のような一般人にとって
ext3やreiser3から乗り換えるとどんなメリットがあるのですか
792:login:Penguin
09/03/05 09:49:16 TLZk7ArG
>>791
RAID構成でふっとび率がうｐするとかかな
793:login:Penguin
09/03/05 10:30:28 TF4Gm0YN
>>791
トラブル解決力が付いて一般人から逸脱する
794:login:Penguin
09/03/05 12:48:41 Zv8p611G
DragonFly BSD 2.2で実用段階になったHAMMER FSを試す
URLﾘﾝｸ(sourceforge.jp)
795:login:Penguin
09/03/05 14:50:13 rkvz8luG
>>794
CPU使用率、メモリ使用量も載せて欲しかった。
796:login:Penguin
09/03/07 11:07:50 kQUrBSwz
>>791
ありません
797:login:Penguin
09/03/07 14:07:41 ovs/dmRV
一応体感できる差としてはこんなもんか：
・ディスクがちょっと増える（使い方によるが）
（小ファイルが多いと「おっ」と思う程度は増える）
・コマンド打ったときの応答がちょっとよくなる（コマンドによるが）
（小ファイルアクセスと削除速度）
たしかに体感できる差はあるけれど、いまからreiser3する理由に足りるか
どうかはわからない。
798:login:Penguin
09/03/07 14:09:28 ovs/dmRV
しまった、ext3,reiser3->btrfsへの乗り換えメリットか。
じゃあいまだと「ありません」でFAだな。
799:login:Penguin
09/03/07 15:29:43 tAQizfuH
>>791
人柱としての厨二病的満足感を得られます。
このスレでは重要なパラメータだ。
800:login:Penguin
09/03/07 17:23:00 vYvwCjyo
ext3,reiserfs → btrfsの乗り換えメリット？
ぶっちゃけ、そんな事を聞いてくるような奴にはメリットなんて無いと断言できるよ
btrfsは、現在LVMやら、MDやら、メーカ独自のSoftwareRAIDなんかで苦労していて
ZFSみたいなFSがLinuxにもネイティブで実装されないかな、とか思っている人の為のFSだから
大体からして、サブボリュームやFSレベルでのRAID(0|1)に何のメリットも見いだせない人には
メリットなんて皆無に等しい、っていうか、(HDD|SSD)単体で使うならext4やreiserfsの方が速いし
管理も楽だよ
まあ、要約すると物理的、或いはネットワーク内に繋がってる、多数のストレージデバイスを
FSレベルでシンプルに管理したい人の為のFS、それがbtrfs
801:login:Penguin
09/03/08 00:17:58 EkVGHjwO
話の流れから見て>>791はext3やreiser3からext4に乗り換えるって言ってるように見えるんだが・・
大体今の状況で一般人がbtrfsを使えるようにする事自体が難易度あるしね。カーネルをgitにする事からだから。
安定板リリース出て標準で採用する鳥や2.6.28が選べる鳥なら即使えるのがext4、偉い違いでしょw
802:login:Penguin
09/03/08 01:52:32 MLSinT6R
そして時は流れ、時代の主流はNTFSに。
そんなときに備えての質問です。
NTFSをmountしたんだけど、ファイルを書き込めません。
mount -t ntfs -o rw /dev/sdf1 /mnt
とやってるのに。/mntに何か書こうとしてもPermission deniedになる。
何か忘れてることありますか？
ディストリはGparted0.4.1を使っています。カーネルは2.6.26です。
803:login:Penguin
09/03/08 01:57:19 /9XI2K8n
>>802
カーネルのntfsドライバなんか使って壊れても知らんぞ？
今、使い込まれているのはFUSEのNTFS-3g
804:802
09/03/08 02:00:25 MLSinT6R
ありがとうございます。
ファイルタイプにntfs-3gを指定したら書き込みが出来るようになりました。
＞壊れても知らんぞ？
神に祈りましょう。 ついでにえいしょうしてささやいてくれたら完璧です。
805:login:Penguin
09/03/08 03:28:03 LKSG8od6
>>804
灰になっても知らんぞ
とだけいっておく。
後は通常運行でドゾー
806:login:Penguin
09/03/08 11:07:25 fNF0jG1C
ちょっと古いレスだけど
>>639
> ZFSやHammer FSはライセンス上の問題があったし、btrfsは渡りに船だったでしょう。
Hammer FSのライセンス上の問題って何だろ？ BSDライセンスだよね。
「Hammer FS on FUSE」をできないかと妄想し始めてるので気になった。
807:login:Penguin
09/03/08 11:21:18 VNWXyuGy
そういやSun vs. NetAppってどうなったん
808:login:Penguin
09/03/08 15:28:07 RwK/Fmyn
このスレ的にどうよ？
Fspy
URLﾘﾝｸ(mytty.org)
809:login:Penguin
09/03/09 00:57:57 GV2fXnbN
>>808
inotifyを使った習作みたいなプログラムだね。
このinotifyを知った時には、ファイルに変更があった時にだけ
リモートサーバーに変更差分をpushするようなデーモン出来るかなー
と思ったんだが、やはりみんなそう思うらしくて、
URLﾘﾝｸ(code.google.com)
に、そういうLive Syncing (Mirror) Daemonがあったりする。
810:login:Penguin
09/03/10 17:29:28 fa0QTRY4
btrfsは名前が悪い。絶望的に。
バターfsなんて恥ずかしくて使えない。
811:login:Penguin
09/03/10 17:30:46 UYNGOKpb
バーターって読むんだけど・・・
812:login:Penguin
09/03/10 17:32:43 YEjvX6c1
作者がbutter-fsだって言ってるじゃん
813:login:Penguin
09/03/10 17:39:37 UYNGOKpb
おお、ほんとだ。すまん。
814:login:Penguin
09/03/10 17:50:40 YQAoSTI+
>>810
>>518
罵倒fsだってさ
815:login:Penguin
09/03/10 20:07:48 yDC62HHM
>>814
バトーFSだと強そうじゃね？
mke2fs -jv で1Tのハードディスク128Gと872Gに分けてフォーマットしたら
872Gの方が途中でセグメンテーションフォルトが起きました
mke2fsは大容量対応していないんですか?
816:login:Penguin
09/03/10 20:09:03 OxRS8Iom
お前んとこだけだよ
817:login:Penguin
09/03/10 21:01:28 yDC62HHM
>>816
んじゃ、HDDの初期不良かな
818:login:Penguin
09/03/11 00:50:24 oxPAi9BH
HDD: WD10EADS
xfs
1TBのフォーマットは2秒くらいで終わる。
# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 273.95
コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.20
# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 4.83
解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.22
# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.64
コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.46
819:login:Penguin
09/03/11 00:51:59 Q/Pii7+/
三国志ヲタには馬騰fs
820:login:Penguin
09/03/11 00:52:32 oxPAi9BH
ext4
1TBのフォーマットは4-5分かかる。
# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 273.64
コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.20
# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 5.76
解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 6.46
# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.51
コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.45
821:login:Penguin
09/03/11 00:54:35 oxPAi9BH
reiserfs3
1TBのフォーマットは30秒くらいで終わる。
# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 283.27
コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.19
# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 4.83
解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.24
# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.75
コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.50
822:login:Penguin
09/03/11 00:56:16 oxPAi9BH
jfs
1TBのフォーマットは1秒くらいで終わる。
# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 280.49
コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.19
# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 5.02
解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.33
# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 40.73
コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.46
823:login:Penguin
09/03/11 00:57:37 RdiNL0Kx
シングルタスクしかしない人ですか？
824:login:Penguin
09/03/11 01:07:56 Tlh+Q3Rr
どれを使っても大差ない感じなのかな。そうなるとシステム負荷が軽いのが良いな。
825:login:Penguin
09/03/11 01:09:16 oxPAi9BH
xfsは小ファイルの処理が非常に遅いと感じていたので、
HDDを買い足したついでにテストしてみた。
どのファイルシステムでも小ファイルの処理には
それなりに時間がかかるものなんだな。
(kernelとかだともっと差がつくようだが)
HDDのヘッドが退避しないうちにさっさとテストしたつもりだけど、
どこか手違いがあったのかもしれない。
あるいはWD10EADSが低速回転だから差がつかなかったのかな。
個人的なバックアップ用途としてはxfsも悪くないのかもしれない
826:login:Penguin
09/03/11 01:38:14 Tlh+Q3Rr
>>825
自分もxfsが細かいファイルにもっと時間が掛かると思ってたw
ちなみに使用しているカーネルのバージョンは?比較的最近のカーネルかな。
827:login:Penguin
09/03/11 04:29:15 KO510Owq
>>823
どんな形であれ、せっかくテストしてくれているんだから、そんな言い方をしたら失礼だぜ？
828:login:Penguin
09/03/11 05:15:14 Oxh4Vyl/
>>825
$ tar tjf MPlayer-1.0rc2.tar.bz2 |wc -l
3260
もう一桁多いのを試してほしいような…
つうか一個のディレクトリに大量に置かないと有意な差は見えないと思う。
829:login:Penguin
09/03/11 08:03:47 4YDbCnMJ
XFSはあらゆる場面において
最も速く、最も安全に使えるファイルシステムです
830:login:Penguin
09/03/11 08:55:12 hFe1ZwTZ
釣るつもりならもっと上手く書けボケ老人
831:login:Penguin
09/03/11 10:59:47 4YDbCnMJ
釣りではありません
真実を述べているだけです
832:login:Penguin
09/03/11 11:10:01 rfDVx5RA
>>831
では適切な検証をデータ込で提示してくださいな
スレ住民も条件の選び方から見て自分にあったFSか見極めるでしょうから
「そんなことしなくても自明です」なんて言ったら電波確定
833:login:Penguin
09/03/11 11:58:04 4YDbCnMJ
何をやってもXFS批判を噴出させるのが
このスレの住人というものです
834:login:Penguin
09/03/11 12:36:41 EgNJdZ2x
普段使うだけならjfs悪くないよ。
xfsはgentooでいろいろでかいのビルドするとき遅いと感じる。
835:login:Penguin
09/03/11 12:47:07 KEpL3SfB
>>825
単一ディレクトリに多数の小ファイルがある場合XFSは速いけど
多数のディレクトリに分散してそれぞれ100個程度の小ファイルがある場合は遅い
後者の場合だとext4のほうが速かった
>>834が遅いって言ってるのも、これだと思う
836:login:Penguin
09/03/11 18:58:29 VdtLCfNF
家庭内的にjfs使い始めてそろそろ2年だが問題ないなぁ。
Maildirのメールサーバだから細かいファイルが沢山できる感じだが
特に問題がおきたことはない。
(スパムを全部取っているから数は結構あるな・・・)
引っ越ししたあと、家電が増えてブレーカー落ちやすくなったんだが
バカスカ落としても何もなかったように起動してくる。
偉いぜjfs。
というわけでもっとでかい運用状況聞きたいぜ。
837:login:Penguin
09/03/11 21:17:13 8ECCLmHd
カーネルの展開が遅いって書かれてたのに、何でMPlayerの展開でテストしてんだか…
しかもHDDの型番はともかく、他はマシン構成はおろか、フォーマット時のオプションすら書かれてないし
テスト結果はかなりウソくさい
何しろウチのML115初代 ＆ AthlonX2 5000+ ＆ 2GB DDR2 × 2 ＆ WD5000AAKS ＆EN8600GT ＆ SoundBlaster Audigy無印って構成のPC上から
X ＆ KDE 4.2.1立ち上げて、その中でkonsoleからsudo emerge texliveしながら、隣のタブでMPlayerのtar玉解凍したって
ウチのext4はそんなにはかからないから
ぶっちゃけ、上記の状態ですら time tar xjf MPlayer-1.0rc2.tar.bz2 なら
real 0m3.224s
user 0m2.980s
sys 0m0.250s
俺はext2とext4しか使っていないから他は追試出来ないけど、どうせ他のテスト結果もウソっぱちだろう
838:login:Penguin
09/03/11 23:12:10 rkEwTD3M
z/Linuxに向いてるのは
どのファイルシステムですか？
839:login:Penguin
09/03/11 23:42:26 IrA1hiXP
>>836
そろそろクラッシュする頃だな
840:login:Penguin
09/03/12 00:12:25 QKWWjyLf
>>836
大規模システムで使っているＹＯ
小さいファイルが多いなら、おぬぬめ
841:login:Penguin
09/03/12 05:39:50 Uu2UFoYU
>>837
> 何しろウチのML115初代 ＆ AthlonX2 5000+ ＆ 2GB DDR2 × 2 ＆ WD5000AAKS ＆EN8600GT ＆ SoundBlaster Audigy無印って構成のPC上から
> X ＆ KDE 4.2.1立ち上げて、その中でkonsoleからsudo emerge texliveしながら、隣のタブでMPlayerのtar玉解凍したって
> ウチのext4はそんなにはかからないから
フォーマット時のオプションすら書かれてないし
テスト結果はかなりウソくさい。
というのはさておき、
> 他は追試出来ないけど
rm -rf MPlayer-1.0rc2 はできるはず。
あとマシン構成はいらないけど、
(サウンドカードとかグラボとか関係あるのかな)、
WD5000AAKSの場合は新旧プラッタがあるから
そこを書かないとね。
320GB*2プラッタ品で7200rpmだったら、
WD10EADSみたいに3プラッタ5400rpm品より
速くて当たり前のような気がする
842:login:Penguin
09/03/12 05:59:17 Gl1f5D2g
無意味に割り込みかけてくるサウンドカードとか、無駄にバスを占有する
ビデオカードとかだと影響するんでないかい。
ついでに適当な計測結果
Dell INSPIRON 1501 + 2.6.26 + reiser3
ほぼ無負荷
$ time tar xjf MPlayer-1.0rc2.tar.bz2
real 0m6.101s
user 0m4.932s
sys 0m1.124s
$ time rm -rf MPlayer-1.0rc2
real 0m0.756s
user 0m0.008s
sys 0m0.712s
843:login:Penguin
09/03/12 08:24:11 q/of3Wvv
ext3で50GBとかのファイル数個をrmすると、50GBのファイル書くのと
同じくらい時間がかかるんだけどこれは仕様？
ディレクトリエントリ操作するだけなんだから一瞬で終わってしかるべきと
思うんだが・・・
844:login:Penguin
09/03/12 12:01:29 fUWg+Y+2
>>843
このスレで何度も話題になっているが、
なぜそうなっているのか技術的理由を書ける人が
このスレに現れたことはない。
845:login:Penguin
09/03/12 12:39:28 Gl1f5D2g
>>843
inodeを忘れないであげてください。
誰かがそのファイル掴んでいる状態で削除すれば、
ディレクトリエントリ消すだけなので一瞬で終わる。
んで、放した瞬間にHDDがカリカリ言い始めるはず。
ということでinode(つうかメタデータ)の更新がすげー遅い。
846:login:Penguin
09/03/12 13:30:20 FK4CPecw
そりゃbitmap使ってるfsの宿命ですがな。
つか、このスレの住人って読込み性能にあんまりフォーカスしてないのはなぜ？
847:login:Penguin
09/03/12 14:45:45 uwGP8iQx
読み込みは気になったこと無いなぁ。
848:login:Penguin
09/03/12 20:47:20 /5waLCXS
去年のカンファレンスでプレゼンターが削除速度を速くしたくて・・・と話していたら
Ted Tsoが割り込んでクラッシュ時の信頼性をあげるために、わざとそうしていて云々と自説を述べ始めて、
スピーカー困惑。
・・・かと、思ったらそこにさらにLinusが割り込んで、「ふざけるな。オレもふだんイライラしてるんだ。高速化しる！」とか自説を
述べ始めて、二人がプレゼンターそっちのけで議論をつづけるので、セッションにすごい微妙な空気が流れたことが
発表者の中の人がかわいそうすぎます
849:login:Penguin
09/03/12 21:06:32 Q9tPCjh3
何度も言うが
難しいことを考えずにXFSを使え
850:login:Penguin
09/03/12 21:15:11 8EggFbE/
さすがXFS教。言うことが違う。
851:login:Penguin
09/03/12 21:18:29 HGzIMQq7
ここは、btrfsに期待
852:login:Penguin
09/03/12 21:19:13 2VoPly+Y
結論 JFSでまた～り
853:login:Penguin
09/03/12 23:23:22 RqJ4/lD8
プレゼンターも、突っ込んでやれよ。
俺は、Linusにつくね。
クラッシュ時の信頼性って言えば許されるとおもってんのか！
だから、ZFSみたいなのが作れないんだよ、と。
854:login:Penguin
09/03/13 00:29:01 AmR0mtlJ
信頼性軽視するからLinuxのfsは他OSからportしてきたものでもアレなことに
なっているけどな。おまけに大して性能も出ていないし。
855:login:Penguin
09/03/13 00:46:56 Xd/smKgF
いろんなFSを量産しているのも弊害だよなぁ
856:login:Penguin
09/03/13 08:53:47 QyWnsw8e
>>854
信頼性重視なの？
857:login:Penguin
09/03/13 08:55:22 QyWnsw8e
ごめん。読み違えたw
そうだよなー。
重視してるならReiserの時もあそこまでフレームが大きくならなかっただろうし。
858:login:Penguin
09/03/13 20:05:10 DZg3JUvb
Solaris ZFSの基本的な仕組みを知る
URLﾘﾝｸ(www.atmarkit.co.jp)
859: ◆IIiDC8JS7w
09/03/13 21:14:51 dlpFGOyH
たくさんのファイルを複数のディレクトリに
ファイルを作成したり、削除したりする時間を測定する
ツールがあるので、使って性能測定してみてください。
redhatの人とか、btrfsの評価で使ってくれている。
URLﾘﾝｸ(www.spinics.net)
↑の最後のほうにコードが載ってます。
860:login:Penguin
09/03/13 23:39:08 x6C+8Djd
ext4がXFSライクなデータ消失を起こしたようです。
URLﾘﾝｸ(slashdot.jp)
861:login:Penguin
09/03/13 23:41:42 E6JaImFf
一緒にすんなハゲ
XFSでこんなこと起きねえよ
862:login:Penguin
09/03/13 23:43:52 JibFhBsj
>>861
最近クラッシュしたときに、書き込みしてなかったか？
ファイルサイズが同じでも中身が0で埋まってるファイルが
できてるかもよ。
rsyncでとってたバックアップも死んでるかもwwww
863:login:Penguin
09/03/14 07:11:48 cN9wHfAO
fsのバグでもなんでも無いじゃないか。
URLﾘﾝｸ(slashdot.jp)
864:login:Penguin
09/03/14 10:33:27 wTSiQHD4
>>859
ファイルシステムベンチマークなら、bonnie++が定番。
865:login:Penguin
09/03/14 10:46:54 Fjttua0k
これってext3でも起こるよね。起こりにくいだけで。
>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。
866:login:Penguin
09/03/14 11:40:29 tgz4pVHK
＞ rename("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
＞ rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")
は
unlink("~/.kde/foo/bar/baz~")l
link("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~")
rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")
にすべきだよな
867:login:Penguin
09/03/14 14:45:40 NGZaZVb3
>>865
最初のはそうだけど、２つ目が問題なんだわ。
xfsはデフォルトでメタデータが先にコミットされるので、その直後に
クラッシュするとファイルシステムの構造的には不整合はないが、その
メタデータが指しているデータは存在しない。
で、xfsはメタデータがゴミデータを指してる状態で開けると、何が
見えるかわからん（古い/etc/passwdのブロックかもしれん）から
セキュリティ的な問題があるよね、ときちんとメタデータが指している
データを最初はゼロクリアした状態にしている（本来のデータがコミット
されたら当然そちらに付け替える）。
ext3等はデフォルトではデータが先にコミットされるので、２での問題は
生じ得ない。一方、xfsの順序は最高性能を発揮するためで、生まれた時代や
背景を考えると致し方ない。
POSIX的にはfsyncしてない限り、どちらの挙動も問題なしで、fsyncしない
アプリ開発者がPOSIXを理解してないというのが結論になる・・・が、
正直２の書き方って、すごい一般的だよね、さあどうしよう、という状況。
hogehoge > fugafuga && fsync fugafuga.new && mv fugafuga.new fugafuga
とか直していくしかない。Ubuntuだっけ？にfsyncコマンドがあるのは
このためだろうと思われる。
もっとも、ドライブキャッシュがあるとfsyncすら保証してくれないので、
さらにバリア張らないととか延々と話が続くんだけど。
868:login:Penguin
09/03/14 16:28:12 l9ZzVqeQ
blogの翻訳？
869:login:Penguin
09/03/14 19:12:33 ++9sa7SW
一時ファイルに書き込み→名前変更ってのは当たり前の技法だと思ってたけど
そうでもないのかな？
870:login:Penguin
09/03/14 20:08:40 6p4fiq3F
>>869
いや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解
871:login:Penguin
09/03/14 20:11:26 RgsfJUAA
しかしまぁ、仕様通りだから悪くない、と言っても汎用的なFSとしては使えないよなぁ
872:login:Penguin
09/03/14 20:19:32 qHb4tz1u
でもそうやって理想の仕様よりも現実を優先していくとWindowsみたいになるわけだけだが。
一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。
873:login:Penguin
09/03/14 20:21:09 Fjttua0k
>>867。
なるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。
結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。
874:login:Penguin
09/03/14 20:23:23 2PA7Wxqo
そしてHans Reiser恩赦に
875:login:Penguin
09/03/14 21:23:11 Qv+bO9QY
壊れたメタデータのコミット先を教えるかわりに
FSの破壊を軽減する司法取引だな
876:login:Penguin
09/03/14 21:57:26 wTSiQHD4
ZFSとかFS層の破壊防止を徹底してるから、
これからはそういう設計が定番になるんじゃないかな。
Btrfsはどうなんだろ？
877:login:Penguin
09/03/14 23:59:37 1qF/srTZ
super_operations構造体のメンバ
freeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・
878:login:Penguin
09/03/15 10:02:11 PCGBiEcT
>>872
これは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。
879:login:Penguin
09/03/15 10:18:44 xjkBDfQM
>>877
きまぐれ。
880:login:Penguin
09/03/15 19:42:41 PU06YtSt
もう名前変更しなくていいようにメンバは
struct struct0001_s {
member0001_t member0001;
member0002_t member0002;
member0003_t member0003;
...
として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。
881:login:Penguin
09/03/15 20:01:52 mnUY72EV
>>879
だったら やめて ちょうだい
本気で好きになりそうだから
あなたの前では きれいでいたいし
882:login:Penguin
09/03/15 20:31:39 ReDUN6Ol
>>876
btrfsはZFSと同じくCOWで書くから、この問題は起こらない
883:login:Penguin
09/03/15 20:34:14 kmO3PCzB
btrfsはなんでaddressingを128bitにしなかったの？ZFSに負けちゃうよ
884:login:Penguin
09/03/15 20:56:32 LgaDmqJ8
>>881
吹いた
885:login:Penguin
09/03/15 22:13:07 VfSmlfyi
デ♥フ♥ラ♥グ
886:login:Penguin
09/03/15 23:37:34 mnUY72EV
>>884
歌詞の一部です 若かった昔を思い出させる
今夜のナンバー １曲目は
長渕剛 素直
URLﾘﾝｸ(www.youtube.com)
887:login:Penguin
09/03/16 01:59:21 Gwa/wpQE
>>883
btr2fs誕生のフラグです
888:login:Penguin
09/03/16 02:03:51 08WqhxTZ
>>883
アドレスが128bitだとIPv6を連想して不吉だから
889:login:Penguin
09/03/16 15:19:00 fRtMFqd9
マジレスするとVFSが対応していない。
890:login:Penguin
09/03/16 15:31:04 FfCxFL0P
ext3は罪な奴だな
fsyncを徹底すると遅すぎて使い物にならないし
fsyncをしなくても十分安全だから
fsync無しの更新を一般化させてしまった
ext4も、data=orderedがデフォルトで安全なはずなんだけどなぁ
遅延アロケーションはジャーナルのコミットを考慮しない言うのか
891:login:Penguin
09/03/16 16:49:59 TUvh8KP2
extなんとかが最もポピュラーなのはなぜ？
歴史的な理由ですか？
892:login:Penguin
09/03/16 18:13:10 4dJsZZR0
なんだかんだで愛されてるんだよ
893:login:Penguin
09/03/16 18:59:45 XO5/u8kb
殺人よりはマシだからな（ワラ
894:login:Penguin
09/03/16 20:55:40 fRtMFqd9
>>891
そのとおり。
ext2時代は事実上、それしか選択肢がなかった。
ext3時代はredhatが他のFSをサポートしなかった。FSの品質はテスターの数にめっさ依存するので
ディストロの対応重要。