アカウント名:
パスワード:
jbdってのはこの辺で解説されてる [ibm.com]Journaling Block Deviceレイヤーのこととして話を進めますが、仮にあなたの意見が正しいとしても、現在のLinuxのVFSレイヤーにraw disk I/Oが無い以上、その上で動作するファイルシステムはどれもダメ(=Journalの正しさを保証できない)という件の文章の結論が変わるとは思えません。
「ディスクはリクエストを出した順序に処理を行うという保証は無い」という文章も今一つ意味が判りません。Linuxの非同期ディスクアクセスについては件の文章でも言及されているので、その話ではありませんよね。ハードウェア的に発行された書き込み命令の順序が、ディスク側で入れ替わる可能性がある、ということですか? (外付けのRAID箱ならそういう場合もあるかも知れんが)
他人の文章を事実誤認と非難するのであれば、第3者にも判るように説明する必要があると思います。で、その結果が件の文章にフィードバックされれば、ためになる情報が蓄積され、より多くの人が幸せになれると思うんですが。
判りやすい解説ありがとうございますm(__)m
raw disk I/Oってのは、HDD上のキャッシュ以外の要素を考慮しなくて良い直接的なディスク操作、という意味で使ってます。おっしゃる通り、きちんと排他処理がなされていれば結果は同じですね。
でも、HDD上のキャッシュをソフトからフラッシュする汎用的な方法ってあります?SCSIならありそうな気がしますが、IDEの場合そんな高級な操作って出来るのかな…
「HDDがコマンドを順に実行するとは限らない」 という情報が出て来てます。これは、、、 (1) 本当ですか?
推測なんですが、本当なんじゃないでしょうかね。たとえば SCSI-2 だと command queuing があって reorder が許されてたと思います。本当にそういうことをするデバイス(ディスクドライブ)があるかどうかは知りませんが、あってもおかしくはないのではないかと(物理セクタに不良があった場合など、reorder とかしてるかも)。
(2) LFSやJFSの設計に影響しますか?
本当なら影響するんだけれど、個々のデバイスの内部での reorder は機種やメーカーによって
ファイルのバージョン管理なり自動バックアップを効率よくやろうと思うと、どうしてもログ構造化ファイルシステムあたりに行き着いてしまう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
一体どれ使えばいいの? (スコア: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箱ならそういう場合もあるかも知れんが)
他人の文章を事実誤認と非難するのであれば、第3者にも判るように説明する必要があると思います。で、その結果が件の文章にフィードバックされれば、ためになる情報が蓄積され、より多くの人が幸せになれると思うんですが。
Re:一体どれ使えばいいの? (スコア:2, 参考になる)
> その上で動作するファイルシステムはどれもダメ
違います。
なぜ raw disk 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つの前提がある。
>の部分がおかしいです。
こっちの方は、あの文書の弁護や代弁しようとは思いません。
#ただ、あれは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)
「重要なのは、トランザクションに続いてデータが書き込まれるという
順序で、それぞれの中での書き込み順は問題ではない。完了したか、
しなかったかが分かればよい」
ということでしょうか?
どうも、私はメタデータとトランザクションとを混同していたようです。
ども、長々とありがとうございました。
#ところで、この話題って2回目ですか?
#教えてもらってもすぐ忘れる奴>わし。
Re:一体どれ使えばいいの? (スコア:0)
LFS や JFS に関していえば、そうです。
> #ところで、この話題って2回目ですか?
> #教えてもらってもすぐ忘れる奴>わし。
はやく前回のトランザクションがコミットされてるかたしかめて!
Re:一体どれ使えばいいの? (スコア:0)
Re:一体どれ使えばいいの? (スコア:0)
ま、それで駄目ならあきらめでしょう。少なくとも、softupdate の書き順で書
Re:一体どれ使えばいいの? (スコア:0)
ヘッドを退避するのはクラッシュを防ぐためです。
普通に考えればヘッドを退避してしまったらデータの書き込みは完了できません。
(ちなみに「大きなコンデンサ」はこのヘッドの退避に使われます。)
> 電圧降下を検出したらそのセクタを最後にする機能もあるという。
それは初耳です。どのハードディスクか教えてくれませんか?
> sector 異常は CRC で検出してくれるから、間違ったデータが出てくる確率は低いだろうし
それは違います。
ハードディスクで使われている ECC は
「書き込みが途中で止
Re:一体どれ使えばいいの? (スコア:0)
Re:一体どれ使えばいいの? (スコア:0)
書き込み順番に気をつければ大丈夫だと思います。
やはり問題はi-node(を含むsector)への書き込みが失敗する場合でしょう。
# 確率は低そうですが…
Re:一体どれ使えばいいの? (スコア:0)
> ヘッドを退避するのはクラッシュを防ぐためです。
> 普通に考えればヘッドを退避してしまったらデータの書き込みは完了できません。
> (ちなみに「大きなコンデンサ」はこのヘッドの退避に使われます。)
データ書き込みがIO命令の単位で完成する必要はないんじゃないの?セクタ単位で十分でしょう?
>> 電圧降下を検出したらそのセクタを最後にする機能もあるという。
> それは初耳です。どのハードディスクか教えてくれませんか?
HとかIとか海とか、今時大抵そうだという話を聞きますが?
#本当かどう
Re:一体どれ使えばいいの? (スコア:0)
「セクタ単位で完了するとは限らない」ということが問題なのです。
> HとかIとか海とか、今時大抵そうだという話を聞きますが?
> #本当かどうか調べたわけではありませんので確証はありませんし、
> #SCSI用の話しか聞いてないのでATAがどうかも知りませんが。
少なくとも各社のハードディスクのマニュアルには記載されてません。
例えば、I 社の SCSI ハードディスク U なんとかのスペックには
「データ書き込み中に電源が落ちた場合に失われるかもしれないセ
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として使うことも可能とか。(うろ覚え)
私的印象は以下の通りです。
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 とかしてみるとパフォーマンスの違いを体感出来ます。
ログ構造化ファイルシステム (スコア:0)
Re:ログ構造化ファイルシステム (スコア:0)
Re:ログ構造化ファイルシステム (スコア:0)
ちなみにWAFL って、daemon本とかに載ってる LFS と違うよね。
Pre 型の Journal を RAM-DISK に書いて(バックアップにバッテリーが載ってるらしい)、そこから先を完全非同期にしてるし、
巨大な単位で IO できるように IO の単位が大きくて、その中ではデータをなるべく連続
Re:ログ構造化ファイルシステム (スコア:0)
ファイルのバージョン管理なり自動バックアップを効率よくやろうと思うと、どうしてもログ構造化ファイルシステムあたりに行き着いてしまう。
Re:ログ構造化ファイルシステム (スコア:0)