Linux 2.4.15-pre2にext3収録 36
ストーリー by Oliver
ジャーナルといっても日記じゃない 部門より
ジャーナルといっても日記じゃない 部門より
Anonymous Coward 曰く，"ジャーナリングファイルシステムの正式な採用は2.5からと言われていましたが、突如 本家Linuxカーネルに採用されることになったようです。ext2との互換性を保つ関係上、斬新な機能は実装することは不可能ですが、現時点では必要最低限の機能と安定性を実現していると思います。"
本家にもさっき掲載された。自分のマシンは総ext3だし、職場の数テラバイトなNFSサーバ郡もext3ですげー安定している。もう素のext2は使えない体になってしまった。
TurboLinuxも (スコア:3, 参考になる)
Re:TurboLinuxも (スコア:1)
TurboLinux Server 6.5 の段階でext3, ReiserFSに対応しています。
これ、発売されたのは４月頃だったのに。
magicmirror
Re:TurboLinuxも (スコア:1)
ext3 の開発者の一人は、Turbolinux, Inc. の研究開発機関である TurboLabs に所属しています。
Re:TurboLinuxも (スコア:0)
Re:TurboLinuxも (スコア:0)
って、裏はとれていますか？
だのにXFSは (スコア:0)
Ext3最大の利点というと、 (スコア:2, 参考になる)
変換作業の安全性に触れた情報をあまり見かけないのですが、どないなもんなんでしょう？
Re:Ext3最大の利点というと、 (スコア:5, 参考になる)
しかし、アレゲ好き人間としては不満でし。
ext3にない機能として
- ディレクトリのO(log n)時間での検索
- データ領域のエクステントベースの確保(xfs,jfs)
- データ領域の遅延確保(xfs,jfs?)
- i-node領域の動的確保
- ファイル末尾の統合(reiserfsのみ)
をもったファイルシステムに注目したいっす。lazy allocationの問題 (スコア:2)
一般に、大きさがあらかじめ分からないデータやメタデータ(typicalなものはdata blockやdirectory page)にたいしてlazy approachをとると、Unixのセマンティクスを壊す可能性があります。vfsopやvnopが一見正常に終了したように見えて、実は空きblockがなくなってしまったがためにlogをcommitできないという事態に陥る恐れがあります(vfsopやvnopではopがpendingのまま処理を返すことはない)。
このような問題はnfsやdfsにもありますが、これらの場合はlocalに空きblockを確保することにより修復が可能です。それに対し、ジャーナリングの場合はlogをバイパスするopが許されないため、logがcommitできなくなると修復が困難です。
Re:Ext3最大の利点というと、 (スコア:1)
最近カーネルにXFSパッチを当てて使っています。
Re:Ext3最大の利点というと、 (スコア:2, 参考になる)
Re:Ext3最大の利点というと、 (スコア:2)
-- wanna be the biggest dreamer
make bzlilo 中... (スコア:2)
今、/vmlinuz を作っています。
取り敢えず、害の出なさそうな /var (30GB) 辺りから
Re:make bzlilo 中... (スコア:2)
# しまった...
e2fsprogs 1.10 に阻まれてしまいました。(^_^;
e2fsprogs は ≧1.19 にしないといけません (手元では 1.22 を使用中。現在の最新は 1.25)。
何でか、4GB の /usr の方が 40GB の /var よりも tune2fs -j に時間がかかってしまいました (/usr を journaling してもご利益ないんですが) が、どちらにせよ数十秒で終わるので ext2 からの移行は簡単に終わりました。
どのFS？ (スコア:2)
ext3 は互換性に優れているというのは知っていますが、性能的にはどれがいいんでしょうか？
安定性はどちらももう実用になるよね。
(XFS は知らない)
-- wanna be the biggest dreamer
Re:どのFS？ (スコア:5, 興味深い)
探していたら、XFS、JFS、ReiserFS、ext3fsの比較について述べているページがありました。ただ、どうもこのページはファイルやディレクトリサイズのスケーラビリティばかり強調していて、ジャーナリング手法の比較という点からするとパッとしません。
ジャーナリングにおける大きな問題は、ログに対するガベージコレクションです。これはしばしばログ内部(主にlog-structured)、またはログとそのほかのブロック(主にmetadata logging)との間でデータの再配置を必要とします。また、ログに対するブロックのアドレッシングには従来よりも大きなオーバヘッドがかかります。したがって、再配置やアドレッシングに要するコストをログヘのまとめ書き(clustering)による利益でカバーしなければなりません。ここ数年の様子を見ていると、ログをディスクに一度書き込むというアプローチをとる限り、多くの応用にて劇的な性能改善が得られたという報告はありません。
このような問題に対し、metadataの更新キューをin coreに作っておき、更新のclusteringを実現することに集中したのがsoftupdatesです。softupdatesとジャーナリングの比較を行った報告もあります。
Re:どのFS？ (スコア:1)
ガーベジコレクションをやらないという手は無しですか？
ext3 のソースコードを見たわけではありませんが
そのログのサイズからいってガーベージコレクションせずに
in-place 更新だけに頼っているようにも見えます。
またログとその他のブロックとの間でデータの再配置を
とありますがログは固定サイズなので再配置の必要
はないような気がするのですが。よければ詳細を
ご教示ください。
Re:どのFS？ (スコア:0)
Re:どのFS？ (スコア:1)
Re:どのFS？ (スコア:3, 興味深い)
私も以前どのジャーなリングファイルシステムを使おうか迷っていたところ、次世代ファイルシステムの比較というページを見つけました。これによればReiserFSは性能はトップだが安定性では最下位になっています。これを参考にした結果、私はext3を選択しました。
fj.os.linuxでもReiserFSの内容がまるごとなくなったという記事がありました。ReiserFSの安定性にはまだ不安を感じます。
ReiserFSの内容がまるごとなくなった (スコア:3, 参考になる)
http://www.reiserfs.net/download.html
でもその事については触れられていています。
でもこの件って 2.4.5 が release されて数日後にはこのパッチが提供されていましたし、関連する部分に修正が入れば新しい release では従来のものに新たなバグが入り込む余地が当然ありますが 2.4.4 から 2.4.5 への修正内容には fs/VFS の修正が含まれていて 2.4.1 から merge された ReiserFS に対するパッチがずっと release されていた状況を見ていれば運用を慎重に行って避けられたかもしれないですね。
多分ここを見ている結構な数の人は個々の部分の patch が release されないか気になる要素を開発している側の mailing list の log を眺めたりして、いけそうだと思った時に初めて release された Kernel を試しているんじゃないかな。
取り敢えず 2.3.x から ReiserFS を使っていますが、致命的な症状には出会わずに済んでいます。
一応 LVM と組み合わせて ReiserFS 領域を resize_reisers で増減(30Gbyte 分減らした事もあります)したりしていますが軽微なトラブルにしか遭った事がありません。
# 丁度昨日までのべ容量 400Gbyte 分の LVM extent の再配置をしながら ReiserFS 領域の増減をやっていました。
automount(5 秒で umount) させている MO の fs としても ReiserFS を利用していますが物理的破損からトラブル以外に出会っていません。
Re:ReiserFSの内容がまるごとなくなった (スコア:1)
逆に言えば、そういう使い方をしなければ全然問題ないと思います。かくいう私も自宅はそういう事をしないのでほぼ全てReiserfsです。
-- Takehiro TOMINAGA // may the source be with you!
Re:どのFS？ (スコア:2, 参考になる)
なにかで読んだ記憶があります。
個人での通常利用でならext3でいいみたいですよ。
ext2との互換性という面からしても。
RedHat 7.2 (スコア:1)
カーネルをコンパイルするのにext3用のパッチをあてる手間が省けるだけでも嬉しい。
RedHat7.2は (スコア:1)
遅くなったとも早くなったとも感じません。
単なるクライアントとして使っているので
負荷をかけたりしてるわけではないですが、
安心感は得られるでしょうか。
--オフトピック--
ホントにオフトピですが、7.2にしてから
xmmsが曲ごとにデバイスエラーを返してくれます。
また再生すれば続きを聞けるのですが・・・
Kondaraのジャーナリング対応 (スコア:1)
自分ではまだ、ジャーナリングファイルシステムを使ったことないんですけどね。
参照 http://www.kondara.org:20080/?date=20010929
preやん (スコア:0)
patch当てたり、先進的なディストロで使ってる人には後追に感じるでしょうけどね。
でも、安定してるってext3出てからそんなにならないんやけど大丈夫?少なくても1年連続稼働での実績は見てみたい気はするんですけどね。
Re:preやん (スコア:0)
継続的にpatch当てながら、開発途中のある段階（例えばcriticalなbugがfixされたとか）のものをreleaseと銘打っていると考えた方がいいんでない？FreeBSDの-STABLEと-RELEASEみたいにさ。
常に開発中だから「Linuxは永遠にβ版」という見方だってできるねん。（悪い意味じゃなくてね）
Re:preやん (スコア:0)
Re:preやん (スコア:2)
# CONFIG_EXPERIMENTAL しない Linux では何も出来ん！
# というのは御意ですけどね。
Re:preやん (スコア:1)
TurboLinux7Workstation にて / を ext3 にして使用
してますが、マウント回数が30回(だったかな？)で
起動するときにfsckされました。
root password 求められました。なんでぇ？？
こういうのが起こらないのがジャーナリング
ファイルシステムじゃないのん？
$ set -o vi
Re:preやん (スコア:2)
ほんと、なんででしょう？
家のTLW7 + ext3では求めて来ませんでしたけど。
＃カーネルをstable/untestedにある2.4.9-3にしてるからかな？
＃＃ちなみにturbo-kernel 2.4.9-xではLVMが使われてることに、さっき気が付きました (^-^;;;;
訂正 (スコア:2)
＞turbo-kernel 2.4.9-xではLVMが使われてる
Logical Volume Managerの方で、Linus氏とAlan氏が採用で揉めていたVMの方ではないですね。勘違いでした m(_ _)m
Re:preやん (スコア:0)
#2.4.14はloop.o使えないしさぁ…。
とりあえず私はacパッチを使用していますが。
Re:preやん (スコア:0)
# 文脈からは distribution あたりの意味に取れるんですが。
Re:preやん (スコア:1)
distributionで合っています。英語圏でもdistroという略称はよく使われているようです(というより日本が輸入したのでしょうが)。