- - PR -
2台からほぼ同時にファイル共有(RedHat GFS、クラスタ？)
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-08-20 01:31
繰り返しますが、ユーザランドからどう見えるか、という話を しているわけではないですよ。 ファイルシステムとはどういうものか、知っていますか？ たとえば http://www.atmarkit.co.jp/flinux/rensai/fs02/fs02b.html こんなものですが。こういうファイルシステムだと、同時に勝手に 書き込みを行うと「書いたつもり」の間接ブロックが知らないうちに 上書きされてファイルが壊れる、なんてことが当たり前に発生しますが。 絶対にそういうことが発生しないファイルシステムの設計を 考えていますか？ ディスク側で書き込み順序を再スケジュール されても大丈夫ですか？ ファイルシステムとして壊れないだけでなく、 ユーザが意図した通りのデータが書かれることが保証できますか？ 追記。 もっと分かりやすい話があって。 open(2)にO_APPENDフラグをつけて開いたファイルに対してwrite(2)を 発行した場合、ファイルの末尾位置を探してそこに対して追記を行う ことが保証されるのがPOSIX仕様ですが、複数のOSからの同時書き込みを 許した場合にはそんな保証はどうやったって不可能であ？ # これが保証されなきゃシステムプログラマは泣いてしまう。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-08-20 01:52 ] | ||||||||||||
|
投稿日時: 2005-08-20 07:08
おはようございます．
やっぱりそうですか． 例えば Microsoft の Excel などで同時に同じ file を Open すると 「もう誰かが開いてますよ」と警告されますし， 共同作業できる仕組みも実装してましたよね． この類ですね？ とすると，GFS ってあまり存在する意義を持たないような気がしますね． 「出来るか？出来ないか？」では「出来る」ものの， 実際には「出来ない」のと同じじゃないかと． 実際に業務で利用してる利用しているという方が 以前別スレでいらっしゃいましたけど， どんな使い方なんだろう？と真剣に疑問です． ※単なる file server という程度？ ※sendmail の spool あたりでは使えなさそう．．． | ||||||||||||
|
投稿日時: 2005-08-20 08:57
私はsistinaの人間でもないですし、GFSに詳しくもなんでもないのですが
ここ↓ http://www.sc-i.co.jp/products/sistinafaq.htm#port で述べられていることは
の部分を保証しているという意味と思っていたのですが それは認識違いなんでしょうか？ http://www.sc-i.co.jp/products/sistina.htm にも「POSIX に完全準拠」などと書かれていますので そういうものなんだと思っていたのですが。。。 なんか大きな勘違いをしてます？ | ||||||||||||
|
投稿日時: 2005-08-20 11:23
うーん、そんなに分かりにくい話だったかなあ。
とか
とか
とか書いているのに、ユーザプロセスの視点から「それは 違うんじゃない？」というのを何度も繰り返されてしまうのは。 もう一度書きますが、私が「同時に書き込むことはできないはず」 と言ってるのはカーネルからみた場合のことです。ユーザから みて通常のファイルシステムと同様に扱えるようにするためには、 ストレージを共有しているOSカーネル間で調停する必要がある。 ユーザプロセスからは競合相手を全く気にすることなく、自分が ファイルシステムを占有しているかのように使えるはず。 で、私が書いたのは「それを実現するためには、裏で動いている カーネル側にはどのような仕組みが必要か」ということであって、 ユーザプロセスからみたらどうなのか、なんて話はしてないです。 その話をすれば... ユーザプロセスから読み書きする際に裏でロックを取得したり するのにかかる時間は、そのマシンが論理的にも物理的にも占有 しているディスクを読み書きする際にディスクのプラッタ上の 目的のセクタがヘッド下にやってくるのを待っている時間と 見分けがつかないでしょう。 ユーザプロセスからみて、通常のファイルシステムと違って余計な 手間をかけなくてはならないのでは使いにくくてしょうがない。 そんなものでいいなら、NFSでも使ってればいい話であって、 もっと使いやすいものが欲しいからGFS等が出てくるわけでしょう。 で、また繰り返して書きますが、私が前に言っていたのは「そういう ファイルシステムを実現するためにはどんな仕組みが必要か」 という話であって、そのファイルシステムが通常のファイルシステム と同様にみえるのか、なんて話はしていません。 「それは当然のこと」としていましたので。 | ||||||||||||
|
投稿日時: 2005-08-22 16:25
こんにちわ．
正しいことを書いているか自信が無いのですが， あるいはぽんす様の指摘はこれを示唆されているのでしょうか？ http://www.jp.redhat.com/magazine/NO11/ ここの「図２」には lock server なるものの記述があり， これが server（kernel ?）間の調停をしてくれるもののようです． 間違っていたらゴメンナサイ． | ||||||||||||
|
投稿日時: 2005-08-22 19:52
そうです。 てゆーか、そもそもこの話は
というところからはじまってますので。 | ||||||||||||
|
投稿日時: 2005-08-22 20:57
失礼しました，見逃してました．．． でも，kernel 同士の調停をしてくれるんでしょうか？ なんとなく頭が三つある kerberos のような怪物を想像してしまいました． | ||||||||||||
|
投稿日時: 2005-08-23 07:51
mandatory lock を行うのか、ということであればまず間違いなくNoで、 ロックサーバが提供するのは、advisory lock でしょう。 そこを重視した言い方をすると、「ロックサーバが調停する」というより 「ロックサーバを介して互いに調整しあう」ということになります。 追記。 上記はストレージを共有している各OSに対しての話。 各OS上でファイルシステムがどういうロック機構を提供するか、 というのはまた全然別の話。 ローカルのマシン上で動いている複数のプロセスの間でファイルロック （レコードロック）を行う場合でも、ふつうは advisory lock です。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-08-23 08:02 ] | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。