Andrew Morton akpm@digeo.com:
o low-latency zap_page_range
o resurrect /proc/meminfo:Buffers
o hugetlb pages
o fix reverse map accounting leak
o add /proc/meminfo:Mapped
o ext3 ceanup: use EXT3_SB
o hold the page ref across -readpage
o fix a bogus OOM condition for __GFP_NOFS allocations
o clean up the TLB takedown code, remove debug
o add dump_stack(): cross-arch backtrace
o various small cleanups
cattelan@sgi.com:
o XFS: "AutoVersion"
Christoph Hellwig hch@sgi.com:
o XFS: update pagebuf comments
o XFS: Return -ENOMEM on vmap failure in _pagebuf_lookup_pages
o Import XFS CVS from 10092002
Peter Anvin hpa@zytor.com:
o CPU detection fixes
James Simmons jsimmons@maxwell.earthlink.net:
o These files missed the handle_sysrq change
o Removed selection.h header. It is not needed and in the future
selections will be a pure userland solution. Use set_current_state
instead in tty_ioctl.c
o Renames console.c and vt.c. The idea is to break these massive
files into smaller ones. The main goal is to move all the high end
tterminal emulation into one file. This way we can have a light
weight printk without the extra weight. nice for embedded systems
Mark Lord lord@sgi.com:
o XFS: remove dead code paths from create/mkdir/link/symlink
o merge xfs up to 2.5.35
mark@alpha.dyndns.org:
o ov511 1.62 for 2.5.34
pdelaney@lsil.com:
o Fusion-MPT driver update
stern@rowland.harvard.edu:
o USB storage: Merging raw_bulk.c with transport.c
Anton Altaparmakov aia21@cantab.net:
o NTFS: Pages are no longer kmapped around calls to
Ben Collins bcollins@debian.org:
o IEEE-1394 updates
David Gibson david@gibson.dropbear.id.au:
o Remove CONFIG_SMP around wait_task_inactive()
David S. Miller davem@redhat.com:
o sparc64 2.5.x file corruptions found
David Woodhouse dwmw2@infradead.org:
o Add three functions for rbtree manipulation -- rb_next(), rb_prev()
and rb_replace_node()
o Remove bogus rb_root_t and rb_node_t typedefs in favour of 'struct
rb_node' and 'struct rb_root' Remove duplicate implementation of
rb_next() in net/sched/sch_htb.c while we're at it.
Eric Sandeen sandeen@sgi.com:
o XFS: teach icmn_err about CE_WARN
o XFS: change symlink perms to 777
o XFS: add error checks to linvfs_direct_IO
Greg Kroah-Hartman greg@kroah.com:
o USB: change the contact email address for the omninet driver
o Driver Model: add dev_get_drvdata() and dev_set_drvdata() functions
o Driver Model: fix oops when device is removed from system
o USB: Convert the core code to use struct device_driver
o USB: convert usb-serial drivers to new driver model
o USB: convert the drivers/usb/class files to the new USB driver
model
o USB: convert the drivers/usb/image files to the new USB driver
model
o USB: convert the drivers/usb/input files to the new USB driver
model
o USB: convert the drivers/us
もう2.5.36でてます (スコア:3, 参考になる)
Andrew Morton akpm@digeo.com:
o low-latency zap_page_range
o resurrect /proc/meminfo:Buffers
o hugetlb pages
o fix reverse map accounting leak
o add /proc/meminfo:Mapped
o ext3 ceanup: use EXT3_SB
o hold the page ref across -readpage
o fix a bogus OOM condition for __GFP_NOFS allocations
o clean up the TLB takedown code, remove debug
o add dump_stack(): cross-arch backtrace
o various small cleanups
cattelan@sgi.com:
o XFS: "AutoVersion"
Christoph Hellwig hch@sgi.com:
o XFS: update pagebuf comments
o XFS: Return -ENOMEM on vmap failure in _pagebuf_lookup_pages
o Import XFS CVS from 10092002
Peter Anvin hpa@zytor.com:
o CPU detection fixes
James Simmons jsimmons@maxwell.earthlink.net:
o These files missed the handle_sysrq change
o Removed selection.h header. It is not needed and in the future
selections will be a pure userland solution. Use set_current_state
instead in tty_ioctl.c
o Renames console.c and vt.c. The idea is to break these massive
files into smaller ones. The main goal is to move all the high end
tterminal emulation into one file. This way we can have a light
weight printk without the extra weight. nice for embedded systems
Mark Lord lord@sgi.com:
o XFS: remove dead code paths from create/mkdir/link/symlink
o merge xfs up to 2.5.35
mark@alpha.dyndns.org:
o ov511 1.62 for 2.5.34
pdelaney@lsil.com:
o Fusion-MPT driver update
stern@rowland.harvard.edu:
o USB storage: Merging raw_bulk.c with transport.c
Anton Altaparmakov aia21@cantab.net:
o NTFS: Pages are no longer kmapped around calls to
Ben Collins bcollins@debian.org:
o IEEE-1394 updates
David Gibson david@gibson.dropbear.id.au:
o Remove CONFIG_SMP around wait_task_inactive()
David S. Miller davem@redhat.com:
o sparc64 2.5.x file corruptions found
David Woodhouse dwmw2@infradead.org:
o Add three functions for rbtree manipulation -- rb_next(), rb_prev()
and rb_replace_node()
o Remove bogus rb_root_t and rb_node_t typedefs in favour of 'struct
rb_node' and 'struct rb_root' Remove duplicate implementation of
rb_next() in net/sched/sch_htb.c while we're at it.
Eric Sandeen sandeen@sgi.com:
o XFS: teach icmn_err about CE_WARN
o XFS: change symlink perms to 777
o XFS: add error checks to linvfs_direct_IO
Greg Kroah-Hartman greg@kroah.com:
o USB: change the contact email address for the omninet driver
o Driver Model: add dev_get_drvdata() and dev_set_drvdata() functions
o Driver Model: fix oops when device is removed from system
o USB: Convert the core code to use struct device_driver
o USB: convert usb-serial drivers to new driver model
o USB: convert the drivers/usb/class files to the new USB driver
model
o USB: convert the drivers/usb/image files to the new USB driver
model
o USB: convert the drivers/usb/input files to the new USB driver
model
o USB: convert the drivers/us
# rm -rf ./.
Re:長い… (スコア:1, 参考になる)
全文に目を通す人なら、アンカーぐらいクリックしてくれるさ。
Re:長い… (スコア:0)
詳細なChangeLog欲しがるような人は kernel.orgか、bk changes
で見てるんじゃないの？どうせ。
＃ 無意味な全文引用の代表だな、こりゃ。
彼のHPを見よ (スコア:0)
つまり、ChangeLogへのリンクにも許可が必要だと考えたってことさ。
激ウレシー!!! (スコア:2, 参考になる)
にして以来、IEEE1394 経由の外付け HDD も含めて全て XFS Only
で使ってきた身としては、本当に嬉しいです。ARMA だけじゃなく標準
で採用してくれる Distribution が増えるといいなぁ。
fsck が超早い、というジャーナリングのメリット以外に、明らかな
メリットを感じたことは実はあまりないんですけどね。ext2 との比較
では、普通に使っている分には体感できるほどの性能差はない感じ。
PCMCIA の無線 LAN カードのドライバが調子悪くて kernel が panic
した時に、直前に編集した /etc/default/pcmcia ファイルが、サイズ
は変わらないながら中身が全部 '\0' になってしまったことがあって、
「セキュリティ上の配慮？」なんて思ったこともありました。４ヶ月ほど
使っていますが、この件以外ではファイル消失などのトラブルは一切な
いです。ナカナカ安定してますよん。
Only Jav^Hpanese available :-)
Re:激ウレシー!!! (スコア:1)
の文書で XFS 1.0 の不具合として紹介されていましたね (^^;。
つい先日 2.4.19+最新の XFS パッチにバージョンアップしたところな
のでこの問題ともオサラバできる…かな？
Only Jav^Hpanese available :-)
Re:激ウレシー!!! (スコア:1)
fsck が超早い、というジャーナリングのメリット以外に、明らかな メリットを感じたことは実はあまりないんですけどね。ext2 との比較 では、普通に使っている分には体感できるほどの性能差はない感じ。
ですね。ext2 自体ジャーナルじゃないだけで、普通のデスクトップとして使っている分には全然見劣りしません。 でも、XFSがマージされたことはうれしいです。 これでようやく、kernel のバージョンアップが非常に楽になる。
XFS を /home にしてるので、普通に kernel.org からソース落して、
カーネルの最構築をしても、
kernel panic という状態 ー> 手で渋々マージ
という作業から解放されるので。
#パッチ当てればいいじゃんと思うかも知れないけど、なんとなく、一からコンパイルし直したいし、ブート時にカーネルのバージョンを選択したいので。
Re:激ウレシー!!! (スコア:0)
return 0;
をを・・・。
XFSも以前使ってましたが、トラブル等は（カーネルが
Re:激ウレシー!!! (スコア:1)
Re:激ウレシー!!! (スコア:0)
今は違うのかな。
Re:激ウレシー!!! (スコア:0)
"fsck.xfs simply exits with a zero exit status."
って書いてますね。
先日新しいHDDを取り付けて xfs にフォーマットしましたが、
一瞬で終りました。しかし、よくわかってませんがbad block
のチェックはどうすりゃよかったの
Re:激ウレシー!!! (スコア:1)
ただ、DOSのformat.exeが検出した不良ブロックを検出できなかったことがあるんだよね。format.exeが誤検出してる可能性もあるけど、ちと怖いんでwindowマシン（ゲーム用なんで壊れてもOK）で使用してる。
PDには (スコア:1)
うすっぺらいコメントがあらわれた！ ▼
一体どれ使えばいいの? (スコア:0)
Re:一体どれ使えばいいの? (スコア:4, 参考になる)
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
Re:一体どれ使えばいいの? (スコア:3, 参考になる)
ちょっとlinuxに関して手厳しい意見に見えるかも
しれませんが、とにかく、これだけファイルシステムに
関して詳しく解説しているところって滅多にないんじゃ
ないかと思います。是非、御一読を。
＃私は、これを呼んでファイルシステムはXFSにしました。
＃「linuxのファイルシステム」の中では、「仕組み的には」
＃XFSが一番堅牢らしい。って読めたんだけど、これって
＃読み間違い？
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
*jbdはジャーナルの書き込みにext2を使っていない
*ディスクはリクエストを出した順序に処理を行うという保証はない
という点で事実誤認をしています
嘘をまき散らす人と信じる人がいるわけですね
Re:一体どれ使えばいいの? (スコア:1)
jbdってのはこの辺で解説されてる [ibm.com]Journaling Block Deviceレイヤーのこととして話を進めますが、仮にあなたの意見が正しいとしても、現在のLinuxのVFSレイヤーにraw disk I/Oが無い以上、その上で動作するファイルシステムはどれもダメ（＝Journalの正しさを保証できない）という件の文章の結論が変わるとは思えません。
「ディスクはリクエストを出した順序に処理を行うという保証は無い」という文章も今一つ意味が判りません。Linuxの非同期ディスクアクセスについては件の文章でも言及されているので、その話ではありませんよね。ハードウェア的に発行された書き込み命令の順序が、ディスク側で入れ替わる可能性がある、ということですか？
(外付けのRAID箱ならそういう場合もあるかも知れんが)
他人の文章を事実誤認と非難するのであれば、第３者にも判るように説明する必要があると思います。で、その結果が件の文章にフィードバックされれば、ためになる情報が蓄積され、より多くの人が幸せになれると思うんですが。
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
> その上で動作するファイルシステムはどれもダメ
違います。
なぜ raw disk I/O(そもそもこの用語で何を仰りたいのかよくわかりませんが)
が無ければ書き込み操作の完了が保証されないとお考えなのでしょうか。
正しく排他処理を行えば簡単に実現できます。
最もナイーブに作ればログの書き込みは
- ログデータを書き込むためのロックを獲得
- オンメモリのログデータを変更
- I/O リクエスト発行
- I/O リクエストの完了待ち
- ログデータを書き込むためのロックを解放
のようになります。> ハードウェア的に発行された書き込み命令の順序が、ディスク側で入れ替わる可能性がある、ということですか？
はい、あります。
ハードディスクの書き込みキャッシュを利用している場合、
個々の書き込み操作の間の順序関係は守られないかもしれません。
守りたい場合は書き込みごとに書き込みキャッシュを
フラッシュする必要があります。
この場合、softupdate はフラッシュだらけになってしまいますが
LFS や JFS の場合はトランザクションの開始と終了(コミット)だけ
書き込み順序が守られていればよいのでフラッシュの回数を抑えられる、
かもしれません。
# Linux のファイルシステムはどれも対応してないようですが…
# というか、現在の所、正しく対応しているファイルシステムの実装はない?
Re:一体どれ使えばいいの? (スコア:1)
判りやすい解説ありがとうございますm(__)m
ACさんなんで#168239 [srad.jp]と同じ方かどうか判りませんが、初めからこういう風に書いてあれば私なんぞが異論を挟む余地はありません。raw disk I/Oってのは、HDD上のキャッシュ以外の要素を考慮しなくて良い直接的なディスク操作、という意味で使ってます。おっしゃる通り、きちんと排他処理がなされていれば結果は同じですね。
でも、HDD上のキャッシュをソフトからフラッシュする汎用的な方法ってあります？SCSIならありそうな気がしますが、IDEの場合そんな高級な操作って出来るのかな…
Re:一体どれ使えばいいの? (スコア:0)
今時のATAコマンドはSCSIと変わりません。
Re:一体どれ使えばいいの? (スコア:0)
親コメントの補足説明です。
「ハードディスクの書き込みキャッシュ」とは
「ハードディスクに搭載されている書き込みキャッシュ」のことです。
Re:一体どれ使えばいいの? (スコア:0)
意味わかって書いてます？
Re:一体どれ使えばいいの? (スコア:0)
なぜ「…という点が間違っているので注意」と書けないのかな。
Re:一体どれ使えばいいの? (スコア:0)
Ext3 や Linux のファイルシステムに関して誤認があるのだから、
XFS と他の ファイルシステムとの比較に役に立つとは思えません。
そもそも具体的なデータを示してあるわけでもありませんし。
Re:一体どれ使えばいいの? (スコア:0)
次のような記述があります。
> 図 4.4(d) ではじめて inode が更新される。
> inode は一般に HDD の sector サイズよりも小さいので、
> この更新は all or nothing で実行される。
> 従って、inode が「破損」する可能性は考えなくて良い。
これは嘘です。
大抵のハードディスクでは、
セクタへの書き込み中に電源が落ちると、
そのセクタのデータが壊れる可能性があります。
このことは各社
Re:一体どれ使えばいいの? (スコア:1)
> 2つ目は、 Storage はある単位での write リクエストに対して、
> 完全実行か無実行になることだ。 もっと分かりやすく言えば、
> SCSI IO request の単位でもいいし、 IDE のコマンドの単位でもいいし、
> sector 単位の書き込みでもいいから、 とにかく「この命令を実行し始めたら、
> これだけは最後までやり遂げる」 という基本単位を保証してもらわ
> なくてはいけない、と言うことだ。 一般には、これは Sector 単位で
>保証されていて、 ある Sector を上書きし始めたら、その Sector
> の書き込みに関しては HDD 側が保証するのが一般的だ。
指摘されてる件は、現実的ではあっても、上述の前提条件を満たして
いない場合ですよね。これを仮定しないと「いわゆるジャーナル
ファイルシステム以外全部ダメ」の結論しか出ない。
それ以外の優劣を論じるためにクリティカルセクションの大きさを
基準にしている。
と、読んだのですが違ってますか？
＃現実の電源断でセクタが壊れる可能性自体は認めますよ。もちろん。
Re:一体どれ使えばいいの? (スコア:0)
現実的でないモデルにもとづいて
> それ以外の優劣を論じ
ることにどれだけ意味があるのでしょうか。
むしろ私は、
> これを仮定しないと「いわゆるジャーナル
> ファイルシステム以外全部ダメ」の結論しか出ない
から、都合のよい前提条件を仮定したのではないか、
と、読んだのですが違ってますか？
そもそも、元の資料 [iij4u.or.jp]の
> このRobust なファイルシステムの実装には3つの前提がある。
Re:一体どれ使えばいいの? (スコア:1)
断罪に見えたので反応しただけです。私自身が有識者ではありません。
>むしろ私は、
(略)
>から、都合のよい前提条件を仮定したのではないか、
>と、読んだのですが違ってますか？
それらが優れているのは認めながらも、それで終りにしたくなかったん
じゃないかと勝手に想像してます。
>そもそも、元の資料 [iij4u.or.jp]の
>> このRobust なファイルシステムの実装には3つの前提がある。
>の部分がおかしいです。
こっちの方は、あの文書の弁護や代弁しようとは思いません。
＃ただ、あれは３年ぐらいは前の文書ですよね。多分。
代わりに、私の疑問を提出しときます。
別コメント [srad.jp]で「HDDがコマンドを順に実行するとは限らない」
という情報が出て来てます。これは、、、
(1) 本当ですか？
(2) LFSやJFSの設計に影響しますか？
これらがどちらもyesだとしても、LFSやJFSが無意味なわけではないですよね？
あの文書とsoftupdateも、当時は(FreeBSDでは現在も)同程度に意味が
あった(ある)のだと思います。
＃ほとんど歴史文書だと分かんないことが問題。
Re:一体どれ使えばいいの? (スコア:0)
推測なんですが、本当なんじゃないでしょうかね。たとえば SCSI-2 だと command queuing があって reorder が許されてたと思います。本当にそういうことをするデバイス(ディスクドライブ)があるかどうかは知りませんが、あってもおかしくはないのではないかと(物理セクタに不良があった場合など、reorder とかしてるかも)。
本当なら影響するんだけれど、個々のデバイスの内部での reorder は機種やメーカーによって
Re:一体どれ使えばいいの? (スコア:1)
FSとHDDとでそれぞれ現状を仮定して、別々に設計の最適化を行っているのが
うまく噛みあってないみたいですね。両者が集まってモデル作りをしないと
いけないのでしょう。
メタデータの書き込みと一般のデータの書き込みを分離して、メタデータ側は
reorderしないことぐらいが最低限の必須要件なんですかね？
Re:一体どれ使えばいいの? (スコア:0)
「2つの書き込みがあったときに どちらが先に書き込まれるかを指定する手段があること」
だけです。そして現行のハードディスクはこの条件を守っています。
この条件が満たされれば、ファイルシステムはログに対するトランザクションの開始と終了を確実に行えま
Re:一体どれ使えばいいの? (スコア:1)
「重要なのは、トランザクションに続いてデータが書き込まれるという
順序で、それぞれの中での書き込み順は問題ではない。完了したか、
しなかったかが分かればよい」
ということでしょうか？
どうも、私はメタデータとトランザクションとを混同していたようです。
ども、長々とありがとうございました。
＃ところで、この話題って２回目ですか？
＃教えてもらってもすぐ忘れる奴＞わし。
Re:一体どれ使えばいいの? (スコア:0)
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
fs周りのツールとkernelを対応の物に更新
tune2fs -J たーげっと
fstab ext2からext3に置き換え
mount -o remount /hoge
でお終い。
ただし、ext2を拡張しただけあってパフォーマンスは他の二つに比べて落ちます。
# rm -rf ./.
Re:一体どれ使えばいいの? (スコア:1, 参考になる)
tune2fs -j ターゲット
ですね。
自分はこれに、-c 0 もしてます。
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
ReiserFSとext3をどちらも1年以上使っています。現時点で自分が管理しているPCが4台、!PCな小型マシンが2台あって、ReiserFS使ったりext3使ったり混在させたりしています。
# ポリシがないな > 自分
数度のクラッシュを経験してますが、どちらのファイルシステムについても特に困った経験はないです。また、ファイルシステムに大きな負荷をかける使い方をしていないので、性能的に困ったこともないですね。
ということで、個人的にはReiserFSとext3の2つについてはわりと安定している印象があります。
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
色々遊んでるひとは、fs飛んだ～とかkernelこけた～とか悲鳴を聞いた覚えがあります。
ReiserFSって中身はDB(の様な物)なので、 それなりに準備すればDBとして使うことも可能とか。(うろ覚え)
私的印象は以下の通りです。
- ext3
- ReiserFS
- XFS
# 誤解など誤情報を含んでいる可能性高ext2 との高い上下互換性の為、取っつきやすい
作業時間に対するC/P率が一番高い(すぐ設定できる割にそれなりの安全性)
スクラッチから作られ、高性能及び高機能のため将来性十分
ext2 との相互互換性はないのが多少難点
基本的にSGI 自身による移植。開発チームの一部ごたごたがあったにもかかわらず存続している
SGI のマシンで培われた信頼性が維持できれば有望株となれるはず
# すんません、使ってないのでよく知りません(^^;;)
# rm -rf ./.
Re:一体どれ使えばいいの? (スコア:1)
なるほどそうかも。
XFSについてはほとんど情報を持っていませんが、一度だけ試したことがあります。確かカーネルモジュールがReiserFSとext3よりも相当に大きかった覚えがあります。単なるモジュールのサイズなので稼働時のメモリ消費量を表すわけではありませんが。
XFSはもともとSGIのWS用に設計されているので、常時大量のメモリを確保して性能を発揮するような構造を持っていたように思います。だとすると、高性能なファイルサーバなどには向いているけど資源の貧弱な環境には厳しいのでは?
# 誤解かもしれないので識者のツッコミ希望
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
XFS のメーリングリストでは、486DX4(100MHz), メモリ24MBの
マシンでカーネルをコンパイルしたとき、ext2 よりも XFS を
使った方が (少しだけ) 速かったという報告がされていました。
ストリーミングデータを扱うのでなければメモリ16MBでも動作に
問題はないだろうということです。
Re:一体どれ使えばいいの? (スコア:1)
# rm -rf ./.
Re:一体どれ使えばいいの? (スコア:0)
Re:一体どれ使えばいいの? (スコア:1)
# rm -rf ./.
Re:一体どれ使えばいいの? (スコア:3, 参考になる)
極端に遅くなるらしいですな。あんまり気にしてないけど。
(多分、10BASE-TでLAN組んでるからだと思いますが)
ツールが揃っていて安定感があって、一番使いやすいのは
ext3じゃないかな。うちは古くからサーバにしてたマシンとかの
大きなパーティションを、カーネルとツールを入れ換えて
順次ext3にアップグレードして使ってますよ。
信頼性の必要な既存のサーバに導入するのならお勧め。
ジャーナリングがメタデータだけでなく、
ファイルそのもののデータにも効くのも特徴です。
ただ、ジャーナリング処理の分、ext2よりも遅いですけど。
まぁ、僕の場合はslackベースのplamoを使ってましたから、
これが一番やりやすかったというのもあるかも。
XFSは大容量ファイルを扱うのに長けているので、
巨大なムービーとか、でかいデータベースとかの
大きなデータをガンガン使う用途にいいみたい。
Reiserfsはこまごましたファイルを高速に操作するのが
上手みたいなんで、コンパイルの時に威力を発揮します。
# ただ、ReiserFSはフルに常用すると、なんか不安定っぽい。
よって、基本はext3、大容量ファイルストレージにはXFS、
ゴリゴリコンパイラで開発する部分にはReiserFSって感じかな。
Re:一体どれ使えばいいの? (スコア:0)
本当に信頼性ってありますか?
この辺り、ちょっと疑問なんですが。
# 普段はsoftupdatesなFreeBSD User
Re:一体どれ使えばいいの? (スコア:0)
じゅうぶんな動作実績のあるext2に＋αしただけなんで、歴史の浅いreiserfsなんかよりは安心できるって程度の話。
# FreeBSDマンセーなやつはウザイ。
Re:一体どれ使えばいいの? (スコア:1)
ってことで、ここでURIをいくつか貼るべきなんだけど、ブックマークしていたページがことごとく404……。
……わたしゃXFS使ってます。って、これじゃ何の参考にもならないわな。
Re:一体どれ使えばいいの? (スコア:1)
このため1つのdirectoryに沢山のファイルが出来るような 使い方をする人はReiserFS か XFS を使うと幸せになれるのではないかと思います。適当なdirectory に20,000くらいファイルを作って ls とかしてみるとパフォーマンスの違いを体感出来ます。