Linux 2.4.15-pre2にext3収録

Anonymous Coward 曰く，"ジャーナリングファイルシステムの正式な採用は2.5からと言われていましたが、突如 本家Linuxカーネルに採用されることになったようです。ext2との互換性を保つ関係上、斬新な機能は実装することは不可能ですが、現時点では必要最低限の機能と安定性を実現していると思います。"

本家にもさっき掲載された。自分のマシンは総ext3だし、職場の数テラバイトなNFSサーバ郡もext3ですげー安定している。もう素のext2は使えない体になってしまった。

TurboLinuxも

[zeissmania (3689)]

7.0Workdstationで、インストール時にext3が選択できますよ。

Re:TurboLinuxも

[magicmirror (2852)]

TurboはジャーナリングFSに対応するのが早かったですね。
TurboLinux Server 6.5 の段階でext3, ReiserFSに対応しています。
これ、発売されたのは４月頃だったのに。

--
magicmirror

Re:TurboLinuxも

[kyle (3923)]

ext3 の開発者の一人は、Turbolinux, Inc. の研究開発機関である TurboLabs に所属しています。

Re:TurboLinuxも

[Anonymous Coward]

TurboLinuxはテストも何もしないで、ただパッチをあててばら撒くだけだからな。そりゃ早いわ。

Re:TurboLinuxも

[Anonymous Coward]

テストも何もしないで

って、裏はとれていますか？

だのにXFSは

[Anonymous Coward]

TurboLinux Workstation 7でも、いまだに選択できない。ていうか、入ってもいない。技術的理由か？それとも政治的理由？

Ext3最大の利点というと、

[yasiyasi (5450)]

　既存のExt2ファイルシステムをデータを格納したまま、ジャーナリング・ファイル・システムに変換できるのが、Ext3最大の売りだと理解していたのですが、合ってますか？

　変換作業の安全性に触れた情報をあまり見かけないのですが、どないなもんなんでしょう？

Re:Ext3最大の利点というと、

[tabatee (1637)]

あんまり構造を変化させずにジャーナリングを追加しているのはメリットだし、常用するファイルシステムに対しては望ましいやりかただと思います。

しかし、アレゲ好き人間としては不満でし。
ext3にない機能として

• ディレクトリのO(log n)時間での検索
• データ領域のエクステントベースの確保(xfs,jfs)
• データ領域の遅延確保(xfs,jfs?)
• i-node領域の動的確保
• ファイル末尾の統合(reiserfsのみ)

をもったファイルシステムに注目したいっす。

lazy allocationの問題

[brake-handle (5065)]

一般に、大きさがあらかじめ分からないデータやメタデータ(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最大の利点というと、

[tkh (235)]

XFSはBalanced Binary Search Treeの一つであるB-treeを採用しているので、O(log n)で探索可能ですね。

最近カーネルにXFSパッチを当てて使っています。

Re:Ext3最大の利点というと、

[aloe plant (80)]

コンバート作業は既存の ext2 の構造には手を付けず tune2fs で新たにジャーナル領域を確保するだけ。 なので一瞬で終る。原理的にほぼ心配ないと思う。

Re:Ext3最大の利点というと、

[dai75 (557)]

あと ext2 として読むこともできる、ってのが美味しい。

--
-- wanna be the biggest dreamer

make bzlilo 中...

[oku (4610)]

今、/vmlinuz を作っています。

取り敢えず、害の出なさそうな /var (30GB) 辺りから

tune2fs -j /dev/sda1

してみるつもりです。 util-linux も 2.11l (≧2.11f) ですし 取り敢えず 逝く途 :-) を阻むものはなさそう (?) です。

Re:make bzlilo 中...

[oku (4610)]

# しまった...
e2fsprogs 1.10 に阻まれてしまいました。(^_^;
e2fsprogs は ≧1.19 にしないといけません (手元では 1.22 を使用中。現在の最新は 1.25)。

何でか、4GB の /usr の方が 40GB の /var よりも tune2fs -j に時間がかかってしまいました (/usr を journaling してもご利益ないんですが) が、どちらにせよ数十秒で終わるので ext2 からの移行は簡単に終わりました。

どのFS？

[dai75 (557)]

今のカーネルにデフォルトで入っているしで ReiserFS(LVM で;-)) 使っています。
ext3 は互換性に優れているというのは知っていますが、性能的にはどれがいいんでしょうか？

安定性はどちらももう実用になるよね。

(XFS は知らない)

--
-- wanna be the biggest dreamer

Re:どのFS？

[brake-handle (5065)]

探していたら、XFS、JFS、ReiserFS、ext3fsの比較について述べているページがありました。ただ、どうもこのページはファイルやディレクトリサイズのスケーラビリティばかり強調していて、ジャーナリング手法の比較という点からするとパッとしません。

ジャーナリングにおける大きな問題は、ログに対するガベージコレクションです。これはしばしばログ内部(主にlog-structured)、またはログとそのほかのブロック(主にmetadata logging)との間でデータの再配置を必要とします。また、ログに対するブロックのアドレッシングには従来よりも大きなオーバヘッドがかかります。したがって、再配置やアドレッシングに要するコストをログヘのまとめ書き(clustering)による利益でカバーしなければなりません。ここ数年の様子を見ていると、ログをディスクに一度書き込むというアプローチをとる限り、多くの応用にて劇的な性能改善が得られたという報告はありません。

このような問題に対し、metadataの更新キューをin coreに作っておき、更新のclusteringを実現することに集中したのがsoftupdatesです。softupdatesとジャーナリングの比較を行った報告もあります。

Re:どのFS？

[NegI (345)]

> ジャーナリングにおける大きな問題は、ログに対するガベージコレクションです。

ガーベジコレクションをやらないという手は無しですか？
ext3 のソースコードを見たわけではありませんが
そのログのサイズからいってガーベージコレクションせずに
in-place 更新だけに頼っているようにも見えます。
またログとその他のブロックとの間でデータの再配置を
とありますがログは固定サイズなので再配置の必要
はないような気がするのですが。よければ詳細を
ご教示ください。

Re:どのFS？

[Anonymous Coward]

softupdate はジャーナリングとは全然関係のないモノで。更に fsck を必要とするので直行した概念ですな。

Re:どのFS？

[makoP (3664)]

まぁログをin-coreに持つことでジャーナリングで 得られる効果の一部を実現している、と言えるんじゃ ないかな。 Soft Updatesによりinconsistencyが限定されるので、 FFS snapshotと組み合わせでon-line fsckは実現でき るし。

Re:どのFS？

[thor (5250)]

安定性はどちらももう実用になるよね。

私も以前どのジャーなリングファイルシステムを使おうか迷っていたところ、次世代ファイルシステムの比較というページを見つけました。これによればReiserFSは性能はトップだが安定性では最下位になっています。これを参考にした結果、私はext3を選択しました。

fj.os.linuxでもReiserFSの内容がまるごとなくなったという記事がありました。ReiserFSの安定性にはまだ不安を感じます。

ReiserFSの内容がまるごとなくなった

[SAY (54)]

のリンク先を読むと 2.4.5 とありましたが、
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の内容がまるごとなくなった

[tt (2867)]

あと危険なのが、2.2.x と 2.4.x を行ったり来たりしている場合ですね。カーネルバージョンによってreiserfsのフォーマットのバージョンが違うため、そのへんの運用を間違うと悲惨な目にあう事が多いようです。また個人的にReiserFS+NFSはどうも不安定なイメージがあります。

逆に言えば、そういう使い方をしなければ全然問題ないと思います。かくいう私も自宅はそういう事をしないのでほぼ全てReiserfsです。

--
-- Takehiro TOMINAGA // may the source be with you!

Re:どのFS？

[Kow (2603)]

そうとう巨大にならない限りReiserFSでなくても大丈夫だと
なにかで読んだ記憶があります。
個人での通常利用でならext3でいいみたいですよ。
ext2との互換性という面からしても。

RedHat 7.2

[Anonymous Coward]

RedHatは7.2からext3を採用していますね。この辺りも関係しているのでしょうか？

カーネルをコンパイルするのにext3用のパッチをあてる手間が省けるだけでも嬉しい。

RedHat7.2は

[swd_rgv (4751)]

RedHat7.2は標準でext3採用ですが、特に問題なしですね。
遅くなったとも早くなったとも感じません。
単なるクライアントとして使っているので
負荷をかけたりしてるわけではないですが、
安心感は得られるでしょうか。

--オフトピック--
ホントにオフトピですが、7.2にしてから
xmmsが曲ごとにデバイスエラーを返してくれます。
また再生すれば続きを聞けるのですが・・・

Kondaraのジャーナリング対応

[skamio (5870)]

ふだんKondara使ってるんですが、Kondara2.1(Asumi)からは対応しているファイルシステムがreiserfs, jfs, xfs, ext3と、よりどりみどりだそうです。ベータ版がリリースされてます。
自分ではまだ、ジャーナリングファイルシステムを使ったことないんですけどね。
参照 http://www.kondara.org:20080/?date=20010929

preやん

[Anonymous Coward]

突如本家で採用って言われてもstableなreleaseじゃ無いしねー。
patch当てたり、先進的なディストロで使ってる人には後追に感じるでしょうけどね。
でも、安定してるってext3出てからそんなにならないんやけど大丈夫?少なくても1年連続稼働での実績は見てみたい気はするんですけどね。

Re:preやん

[Anonymous Coward]

preとreleaseの差ってそんな大したことないような。
継続的にpatch当てながら、開発途中のある段階（例えばcriticalなbugがfixされたとか）のものをreleaseと銘打っていると考えた方がいいんでない？FreeBSDの-STABLEと-RELEASEみたいにさ。
常に開発中だから「Linuxは永遠にβ版」という見方だってできるねん。（悪い意味じゃなくてね）

Re:preやん

[Anonymous Coward]

＞常に開発中だから「Linuxは永遠にβ版」という見方だって ＞できるねん。 変な大阪弁は勘弁。＜寒ー てな事は置いといて、それはAgreeですよ。 でもext3が今の段階でstableってのはどうかと思うんですが。 どうなんでしょ?

Re:preやん

[oku (4610)]

でもext3が今の段階でstableってのはどうかと思うんですが。

少なくとも CONFIG_EXT3_FS は CONFIG_EXPERIMENTAL が必須ですが。
# CONFIG_EXPERIMENTAL しない Linux では何も出来ん！
# というのは御意ですけどね。

Re:preやん

[bananan_w (3061)]

> でもext3が今の段階でstableってのはどうかと思うんですが。 どうなんでしょ?

TurboLinux7Workstation にて / を ext3 にして使用
してますが、マウント回数が30回(だったかな？)で
起動するときにfsckされました。
root password 求められました。なんでぇ？？
こういうのが起こらないのがジャーナリング
ファイルシステムじゃないのん？

--
$ set -o vi

Re:preやん

[zeissmania (3689)]

＞root password 求められました。なんでぇ？？
ほんと、なんででしょう？
家のTLW7 + ext3では求めて来ませんでしたけど。
＃カーネルをstable/untestedにある2.4.9-3にしてるからかな？
＃＃ちなみにturbo-kernel 2.4.9-xではLVMが使われてることに、さっき気が付きました (^-^;;;;

訂正

[zeissmania (3689)]

自己レスです。
＞turbo-kernel 2.4.9-xではLVMが使われてる
Logical Volume Managerの方で、Linus氏とAlan氏が採用で揉めていたVMの方ではないですね。勘違いでした m(_ _)m

Re:preやん

[Anonymous Coward]

2.4.11あたりからはreleaseされてもpreな雰囲気がただよってます。2.5系列へ分岐してないので開発版のノリでリリースされてるのが問題と思われます。
#2.4.14はloop.o使えないしさぁ…。
とりあえず私はacパッチを使用していますが。

Re:preやん

[Anonymous Coward]

ディストロって何ですか？

# 文脈からは distribution あたりの意味に取れるんですが。

Re:preやん

[thor (5250)]

ディストロって何ですか？ # 文脈からは distribution あたりの意味に取れるんですが。

distributionで合っています。英語圏でもdistroという略称はよく使われているようです(というより日本が輸入したのでしょうが)。