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

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

[前50を表示]
550:login:Penguin
09/01/21 20:09:53 ubPOGmL6
>>548はXFS拒絶症なんですね、わかります。

551:login:Penguin
09/01/21 20:33:32 mATOklwj
「XFS拒絶症」って10回言ってみて

552:login:Penguin
09/01/21 20:34:37 OU0txi38
>>550
で、君がXFS信者に認定され、こういうレスをする俺がXFSアンチに認定されると。

553:login:Penguin
09/01/21 20:39:24 ubPOGmL6
>>552
そのとおりさ

554:login:Penguin
09/01/21 21:41:12 MiSYAlac
おまいらマイナーファイルシステム同士仲良くしる

555:login:Penguin
09/01/21 21:51:05 6ZLp3A6Z
“I have a dream. That one day in the kernel of Linux system.
the FS of former bunkrupt company and the FS of former big
mainframe manufacture will be able to sit down together at the disk of seagate."

556:login:Penguin
09/01/21 22:01:08 em1PHtba
カーネルのビルドなんてtmpfsでいいじゃん

557:login:Penguin
09/01/21 22:14:44 DLPhRQXi
どーでもいいから、用途別のオススメ教えろ。
テンプレ作らなきゃできないのかよ。

【Web】
【DB】
【バッチ処理】
【多重処理】

あと何かあったら追加よろしく～

558:login:Penguin
09/01/21 22:22:16 NpsqSYmx
【Web】ext3
【DB】ext3
【バッチ処理】ext3
【多重処理】ext3

Linux上での実績を考慮したらこうなりました。

559:login:Penguin
09/01/21 22:44:53 FKj2VsoD
ﾜﾛﾀ
確かに。

560:login:Penguin
09/01/22 20:57:31 pcMr5U9d
マジレスすると

【Web】Reiser3
【DB】Reiser3
【バッチ処理】Reiser3
【多重処理】Reiser3

561:login:Penguin
09/01/22 21:52:07 nQOp8IrY
>>560 「悪いけど…趣味が違うから。私、reiserfsのファンなの。ext3大っ嫌い。」
>>561 「えっ、reiserfsぅ? なぜそんなマニアックなFSをー!」
>>561 「バカな… reiserfsと言えば、B+treeとBitampのつぎはぎだらけで、
　　　しかももう放棄された成長性E(jfsより下)のプロジェクトですよ？」

562:557
09/01/22 22:11:04 cDP8WLFf
>>558,560
おまいらは使い分けもできんのか…
四角い頭の椰子に聞いた俺がバカだった。

563:login:Penguin
09/01/22 22:13:01 FA8x4VzJ
Reiserfs持ち上げるならせめてreiser4を持ち上げろよ…いくらネタでも。

564:login:Penguin
09/01/23 22:18:10 RypETPY+
reiserfsはkernel2.2～2.4への過渡期で
やってくれた記憶があるから好きになれないなぁ

565:login:Penguin
09/01/23 22:32:28 3h8Zg4uw
>>560
どれも似たり寄ったりsage
使い分けるほどじゃねえよ

566:login:Penguin
09/01/24 02:00:06 0rWx8rMa
reiserfsの作者の出所は14年先らしいが。

567:login:Penguin
09/01/24 05:12:06 TF8AXIFO
>>558
サポートの関係でそうなることはけっこうあったり。

>>566
実時間でドッグイヤーですか。

568:login:Penguin
09/01/24 23:24:12 JGINnWwe
やっぱり JFS 最高やね
性能も信頼性も

569:login:Penguin
09/01/25 10:00:22 QOAXgSVd
ext3は最悪です。
本当にありがとうございました。

570:login:Penguin
09/01/25 10:20:54 ROXca4XD
>>568,569
具体的に頼む
他の人がからみ難いじゃないか

571:login:Penguin
09/01/25 10:56:41 1fmrMHGH
ファイルシステムなのかという気もするが、Linuxって*_inode_cacheとかで
キャッシュに大量にスラブが取られて、肝心のアプリがOOM killerとかに
殺されたりします。

一応vfs_cache_pressureでなかなか起きないようにはできるものの、根本的な
疑問として

　アプリがメモリを要求してるのに、キャッシュが開放されずに
　OOM killer発動っていう流れは何よ？

というのがあるんですが、なんでメモリ要求で不足を検出したタイミングで
キャッシュ開放処理を走らせないのか誰か教えてください。

572:login:Penguin
09/01/25 11:02:00 LPC6NO2X
メモリの種類によってIOを走らせられるかどうか決まってるからだよ。
GFP_*とかで調べてみれ。

573:login:Penguin
09/01/26 22:36:22 khaVcA+g
Windows上のNTFSと、Linux上のext3は、どちらが速いですか？

574:login:Penguin
09/01/26 22:55:19 PNgXVOhm
>>573
ext3
でもそれだけで評価が決まるわけではないけどね。
あまり比較することい意味を感じないけど、なにを聞きたかったのかな？

575:login:Penguin
09/01/26 23:03:05 khaVcA+g
>>574
バックアップ用に買ったUSBのHDDを、WinとLinux、どちらに繋ごうかと思いまして

576:login:Penguin
09/01/27 00:00:06 kkfqlZMS
経験者は語る
NTFSもext3も糞

577:login:Penguin
09/01/27 00:01:14 wSLWJ55i
で、経験者のおすすめは？

578:login:Penguin
09/01/27 00:28:53 7kWbztPX
FATだろう。多分

579:login:Penguin
09/01/27 00:44:03 wsOi49LW
たしかに互換性ならFAT16最強だが。

580:login:Penguin
09/01/27 01:27:31 3sXwC4mw
今更2Gのパーティションって何に使えばいいんだよ。

ext3もそのうちこんな扱いになるんだろうな。
もうすぐ2TのHDDでるっぽいし。

581:login:Penguin
09/01/27 20:31:22 PussyOjP
Reiser4、大好きです。

582:login:Penguin
09/01/28 16:27:39 AMrE/+bm
WindowsXP向け exFAT FSが提供されたようだ。
linuxではどうなのだろう。対応する動きはあるのかな？
現物が出ていないのであれだけども。
URLﾘﾝｸ(www.microsoft.com)

583:login:Penguin
09/01/29 00:02:13 FZhoCuj7
これに返事がくるのを待てばよいのではないかと。
URLﾘﾝｸ(lkml.org)

584:login:Penguin
09/01/29 10:34:05 PcW9UB4+
> Linuxカーネル開発者の間では最近Linuxカーネルに取り込まれた「btrfs」が
> 次世代ファイルシステムの本命であると支持する向きが多い。

> 多くのユーザーはext3など現在のファイルシステムからext4を経て
> （もしくは直接）btrfsに移行していくとみられる。

ext3の後継者争いも激化の方向に
URLﾘﾝｸ(www.itmedia.co.jp)

585:login:Penguin
09/01/29 11:53:40 cNYsBpvz
企業ではext3やXFSが標準的に用いられていることが多い。

おまえらわかったか

586:login:Penguin
09/01/29 12:08:12 cvyn7tiC
>>558で既出。LinuxのXFSはねーよ。

587:login:Penguin
09/01/29 14:25:14 dR/fL2Y3
それにしてもocfs2にbtrfsと次世代ファイルシステムは完全にOracleに
おんぶに抱っこだな。完成度もいいし、DBは好かんがOracle見直したわ。

588:login:Penguin
09/01/29 17:02:50 oloYkLqQ
ext3が一番使われてて、一番枯れてるのは誰でも知ってること

589:login:Penguin
09/01/29 18:23:47 lmH3IpIy
枯れてるとか安定してるとかここのｽﾚじゃまったく意味無いな。
メイン環境がWinなもんだから平気で不安定版ｲﾝｽﾄする連中が殆ど。
最新で先進的かつ安定してるかどうかよく分からん物が最高だろ。

590:login:Penguin
09/01/29 20:05:01 h2oEOEZi
Linuxを複数入れてるんじゃないか？
めんどくせーwindowsと違ってrsyncでコピってfstabとブートローダー弄ったらokだし。

591:login:Penguin
09/01/29 23:08:04 ztRcJgTx
>>589
インストール時にデフォルトで選ばれているFS
なんじゃねーの。選択するのは面倒だから。

592:login:Penguin
09/01/30 00:51:55 DVI8ZiBT
俺は 589 とは反対で安定を求めてこのスレを読んでおります。
邪険にしないでね。

593:login:Penguin
09/01/30 08:06:46 I2CS/Xks
質問なのですが、ext3ファイルシステムを利用しているのですが、ファイルの合計容量と、パーティションを切った領域の容量が一致しません。15ギガ切っておよそ1ギガ分ぐらいがどこに使われているのか分かりません。
もしかして、ファイルシステムの仕様なのでしょうか。どなたがご教示ください。お願いします。

594:592
09/01/30 08:11:12 I2CS/Xks
連投すみません。
あと、合計の容量と現在の使用量はkde4のdolphinのプロパティーで確認したものです。

595:login:Penguin
09/01/30 08:37:11 tY3sh5+s
>>593
man tune2fs
URLﾘﾝｸ(www.linux.or.jp)
予約ファイルシステムブロック reserved filesystem blocks
ってのになってる。
5% くらいかな。

596:login:Penguin
09/01/30 12:16:57 pFX4Hfia
ジャーナルサイズにも気をつけろ
デフォルト意外に大きいぞ

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

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

598:login:Penguin
09/01/30 13:51:31 4mFsvRt0
>>597
バグのないプログラムは無い、というのと同じ意味だろ。

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

599:login:Penguin
09/01/30 19:44:06 TWmxU2Ks
URLﾘﾝｸ(www.atmarkit.co.jp)
>これにより、XFSで大きなディレクトリを操作するようなワークロードにおいて最大20倍の高速化が達成されたそうです。

ほほう。

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

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

601:login:Penguin
09/01/30 20:11:28 qnrJLGzh
ワークロードが違えば結果も違う罠

602:login:Penguin
09/01/30 20:27:55 BLheTFgw
他のファイルシステムと比較して遅くなるのには変わりないし。

603:login:Penguin
09/01/30 20:28:18 TWmxU2Ks
いや俺XFSなんて使ったこと一度も無いけど。

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

604:login:Penguin
09/01/30 20:30:23 xYA3qWmz
ここにはXFSアンチがいます。
みなさんとっとと虫籠に。

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

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

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

607:login:Penguin
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
バカが使ってから気づくんじゃないか

次ページ