● gfarm 全体に関わる問題点 - Linux のいくつかのバージョンにおいて、/etc/nsswitch.conf で ldap を 指定した場合、gfarm プログラムや gfsd がハングする場合があります。 この問題は、Gfarm のバグではなく、システム附属のライブラリのバグです。 具体的には、以下の条件全てが成り立つ場合に発生します。 1. あるプログラムが fork(2) システムコールを呼び出す。 2. そのプログラムが、fork(2) システムコールを呼び出す前に、getpwuid(3) のような、間接的に nss_ldap モジュールを呼び出す関数を呼び出す。 3. そのプログラムの親プロセスと子プロセスの両方が、fork(2) システム コール呼び出し後に、そのような種類の関数を呼び出す。 4. そのプログラムは、pthread ライブラリとリンクされている。 この症状は Fedora Core 3, Fedora Core 5 および CentOS 4.4 で確認され ていますが、Red Hat 8 では確認されていません。 対処予定: 現在のところ、有効な対策が不明なため対処の予定はありません。 - Gfarm ファイルシステムに対する特権ユーザはいません。 特権ユーザがいないため、ファイルの所有者の変更などの特権命令はありま せん。 対処予定: gfarm v2 の最初のリリースで対処します。 gfarm v1 での対処の予定はありません。 - gfarm_agent は、現在のところユーザ認証を行なっていません。 gfarm_agent はメタデータの読み書きを行ないます。従ってこれは、 gfarm_agent にネットワーク的に到達可能であれば、誰でも、どんな メタデータでも変更できてしまうことを意味します。 対処予定: gfarm v2 にはこの問題はありません。これは gfarm_agent に対応する 機能を gfmd が受け持っており、認証されたユーザしか gfmd にはアク セスできないためです。 今のところ gfarm v1 での対処の予定はありません。 - ファイル関係のメタデータに関して、ユーザ単位の保護機能がありません。 gfarm ユーザであれば、メタデータを保持する LDAP ないし PostgreSQL サーバに直接アクセスして gfarm ライブラリによる検査をバイパスする ことによって、誰でも、どんなファイルやディレクトリのメタデータでも 変更できてしまいます。 この問題は、gfarm.conf にアクセスできるユーザのみに当てはまります。 これは、LDAP ないし PostgreSQL へのアクセスが、gfarm.conf に設定された パスワードによって保護されているからです。 対処予定: gfarm v2 の最初のリリースで対処します。 gfarm v1 での対処の予定はありません。 - ホスト関係のメタデータに関して、ユーザ単位の保護機能がありません。 gfarm ユーザであれば、誰でも、どのホストに関するメタデータでも 変更できてしまいます。 対処予定: gfarm v2 の最初のリリースで対処します。 gfarm v1 の場合でも、メタデータを保持する LDAP サーバないし PostgreSQL サーバの設定を行なうだけでこの対処はできます。 ただし、今のところ config-gfarm が自動で行なう設定にはこの 対処は含まれていませんし、また、手動の設定は可能なものの、 gfarm の配布には、OpenLDAP 向けの方法を解説したドキュメントが 含まれていません。 PostgreSQL 向けの設定方法は、Gfarm-FAQ.ja の 3.3 に記述されて います。 - ファイルアクセス権限の検査が完全ではありません。 たとえば、ファイル作成時の権限検査において、そのファイルの存在する ディレクトリの書き込み権限は検査しますが、そのファイルの祖先のディレクトリの 「x」ビットは検査していません。このため、本来ならアクセス拒否されるはずの ディレクトリにファイルを作成できてしまうことがあります。 逆に、ファイルの作成を試みる場合、対象のファイルが既に存在するならば、 そのファイルの親ディレクトリへの書き込み権限がなくても、本来ならオープン できる筈です。しかし現在の実装では、アクセス拒否されてしまいます。 対処予定: gfarm v2 の最初のリリースで対処します。 今のところ gfarm v1 での対処の予定はありません。 - gfarm スプール中の、ディレクトリ権限設定に問題があります。 ファイルシステムノードに存在するスプール中の実ディレクトリは、ファイル 新規作成やレプリカ作成時に、必要に応じて作られます。 この実ディレクトリの所有者は、実ディレクトリ作成のきっかけとなる 処理 (ファイル新規作成やレプリカ作成) を実施したユーザとなってしまい、 必ずしも本来の所有者になりません。 また、そのような場合、実ディレクトリのモードも、本来のモードではなく 0777、すなわち誰でも読み書き可能なモードとなってしまいます。 従って、このような場合、スプールに直接アクセスすると、ディレクトリ 権限によるアクセス保護をバイパスすることができてしまいます。 また、chmod でディレクトリの書き込み権限を落した場合にも問題が生じます。 そのディレクトリの直下に既に作成されているものの、まだそのファイルシス テムノードには実体が複製されてないファイルやディレクトリを、必要に応じ て複製しようとした場合に、エラーが生じてしまいます。 もしそれがファイルではなくディレクトリだった場合、さらに問題が生じる 可能性があります。というのは、そのディレクトリ以下にファイルを作成 しようとした場合に、ディレクトリの複製ができないため、ファイル作成 自体が失敗する可能性があるためです。 この問題は、下記にも記載されています。 http://datafarm.apgrid.org/bugzilla/show_bug.cgi?id=19 対処予定: gfarm v2 では、スプールの構造上、この問題はありません。 gfarm v1 での対処の予定はありません。 - レプリカ作成時の、スプール中のファイル権限設定に問題があります。 レプリカ作成を行なった場合、そのレプリカに対応するスプール中の 実ファイルの所有者は、レプリカ作成を実施したユーザとなります。 このため、本来の所有者とは異なる所有者になることがあります。 また、そのような場合、実ファイルのモードも、本来のモードではなく 0777、すなわち誰でも読み書き可能なモードとなってしまいます。 従って、このような場合、スプールに直接アクセスすると、ファイル アクセス権限による保護をバイパスすることができてしまいます。 対処予定: gfarm v2 では、スプールの構造上、この問題はありません。 gfarm v1 での対処の予定はありません。 - グループ権限は実装されていません。 対処予定: gfarm v2 の最初のリリースで対処します。 今のところ gfarm v1 での対処の予定はありません。 - gfs_pio_sync() は、現在のところメタデータの更新を行なっていません。 対処予定: 未定です。 - クライアントがクラッシュした場合に、一貫性が失われることがあります。 gfarm v1 では、gfarm クライアントが直接メタデータを更新します。 この結果、アプリケーションが処理途中でクラッシュしたり、あるいは kill(2) された場合、メタデータの状態に一貫性がなくなる可能性が あります。 対処予定: gfarm v2 では、この問題はありません。 gfarm v1 での対処の予定はありませんが、gfsck コマンドで 一貫性のないメタデータを消去したり、あるいは Gfarm-FAQ に ある通り、gfsplck で実ファイルを消去することはできます。 - 消去すべきファイルやディレクトリが消去されず、ファイルシステム ノードのスプール中にゴミが残ることがあります。 gfarm v1 では、削除すべきレプリカやスプールディレクトリの情報を 保持するメタデータが存在しません。 このため、クライアントがクラッシュした場合のみならず、ファイルの 消去処理を行なう際に gfsd が一時的に落ちていたり、ネットワーク トラブルがあった場合など、スプール上にゴミファイルやゴミディレ クトリが残ることがあります。 対処予定: gfarm v2 の最初のリリースで対処します。 gfarm v1 での対処の予定はありませんが、Gfarm-FAQ にある通り、 gfsplck でゴミを消去することはできます。 - ファイルやディレクトリの名前に「:」が含まれていると正しく動作しない ことがあります。 より正確には「:」の後が、数字 (ただし、2桁以上で、かつ0で始まる数字 は除きます) か、あるいはアーキテクチャ名と同じ文字列であるような ファイル名やディレクトリ名を使うと正しく動作しないことがあります。 これは、この形式のファイル名が、スプール中のファイルの実体と衝突する からです。 対処予定: gfarm v2 では、スプールの構造上、この問題はありません。 gfarm v1 での対処の予定はありません。 - ファイルアクセスに使われている最中に、gfsd が予期せぬ終了をした場合、 そのファイルへの以降のアクセスはエラーとなります。 ファイルをオープンし直せばアクセス可能になります。 これは、たとえばその gfsd を動かしているファイルシステムノードを リブートした場合などに起きます。 対処予定: 未定です。 - global view に対する TRUNCATE モードでのオープンは、正しく動かない 場合があります。 あるセクションを一度だけ訪れる場合なら問題ありません。しかし、他の セクションに移動してから既に訪れたセクションに戻ってくると、その際に 再度 TRUNCATE されてしまい、書き込み内容が失われてしまいます。 対処予定: 未定です。 - global view に対する追記 (APPEND) モードでのオープンは、現時点では サポートされていません。 対処予定: 未定です。 - global view でオープン後、chmod でオープン不能なモードに変更した場合、 そのオープンされたファイルに対する処理に失敗することがあります。 これは、global view に対する API 処理では、global view を構成する 各セクション (フラグメント) をオープンし直すことがあるためです。 なお、view の種類を指定しなかった場合のデフォルトは global view です ので、やはりこの問題が生じる可能性があります。 対処予定: 現時点では仕様上の制限事項であり、対処の予定はありません。 単一のセクション (フラグメント) からなる global view に限れば、 オープン直後に明示的に gfs_pio_set_view_global() を呼び出して おけば、この問題を避けることができます。 - global view に対する API 呼び出しのエラーの意味は不明確です。 これは、複数のファイルフラグメントから構成されている global view に 対する API 呼び出しは、これまでアクセスしていたフラグメントのクローズ、 これからアクセスするフラグメントのオープン、さらに API で指定された 処理の実行という、三つの操作の組合せになる場合があるからです。 また、現在の実装では、このうち、これまでアクセスしていたフラグメントの クローズ処理でエラーが生じても、そのエラーは通知されないという問題が あります。 対処予定: 現時点では仕様上の制限事項であり、対処の予定はありません。 ただし、これまでアクセスしていたフラグメントのクローズ処理で エラーが生じた場合に関しては、時期は未定なものの、エラーを 通知するように直す予定です。 - 複数回 gfs_pio_set_view_*() API を実行した場合のエラーの意味は不明確です。 二度目以降の gfs_pio_set_view_*() の呼び出しは、以前の view のクローズ 処理と、新しい view のオープン処理を兼ねているので、クローズ時に生じた エラーか、オープン時に生じたエラーかを区別する方法はありません。 対処予定: 現時点では仕様上の制限事項であり、対処の予定はありません。 エラーを厳密に検知したい場合には、1回のオープンに対して、 gfs_pio_set_view_*() API の呼び出しを一度に限る必要があります。 - ファイルをオープン中に rename や unlink を行なうと、close 時に GFARM_ERR_NO_SUCH_OBJECT でエラーになります。 また chmod で、実行属性を変更した場合にも同様な現象が生じます。 unlink の場合については、実害はさほどありませんが、それ以外の場合は、 ファイルサイズやチェックサム、ファイルのアクセス時刻や変更時刻が 正しく更新されませんので問題が深刻です。 システムコールフック経由の場合のエラーは ENOENT (No such file or directory) です。 対処予定: gfarm v2 の最初のリリースで対処します。 今のところ gfarm v1 での対処の予定はありません。 - ファイルをオープン中に chmod や utimes を行なった場合、close 時に その変更が取り消されてしまいます。 対処予定: gfarm v2 の最初のリリースで対処します。 今のところ gfarm v1 での対処の予定はありません。 - chmod によって、実行ファイルを非実行ファイルに変更したり、あるいは 非実行ファイルを実行ファイルに変更することが可能なのは、ファイルを 構成するセクション数 (フラグメント数) が 1 つの場合だけです。 セクション数 (フラグメント数) が 1 より大きい場合は、 GFARM_ERR_OPERATION_NOT_PERMITTED でエラーになります。 システムコールフック経由の場合のエラーは EPERM (Operation not permitted) です。 対処予定: 未定です。 - stat API は、ファイルをクローズするまで、正確なファイルサイズを返しません。 section view (あるいは index view) であれば、gfs_pio_stat() API (フックの 場合なら fstat() API) を利用すれば実際のファイルサイズを得ることができます。 ただし、global view の場合には、この方法も使えません。 対処予定: 未定です。 - stat API の返す st_ino, st_nlink, st_group フィールドの値は、意味が ありません。 st_ino フィールドは、同一プロセス中では、それぞれのファイルやディレクトリ は、ユニークな値をとります。しかし、gfarm_agent を共有していない 異なるプロセス間では、たとえ同一のファイルやディレクトリであっても、 同一の値とはなりません。 また、st_ino は本来ならファイルの実体に関連するIDであり、ファイルを改名 したり、削除しても変化しません。 しかし、gfarm v1 では、st_ino はファイル名に関連するID であり、ファイル を改名すると変化してしまいますし、ファイルを削除した場合の値は未定義です。 対処予定: gfarm v2 の最初のリリースで対処します。 今のところ gfarm v1 での対処の予定はありません。 - 異なるプロセスが同時に同一のファイルやディレクトリ階層に対して処理を 行なった場合、ファイルシステムの一貫性が失われる場合があります。 異なるプロセスが同時に同一のファイルをオープンする場合に対しては、 対策がとられていますので、実用上、特に問題はありません。 しかし、ディレクトリや、多数のセクションからなるファイルの rename、 あるいは chmod でファイルの実行属性を変更する場合などのように、複数の セクションに対して改名を伴う処理を行なう場合、この問題が生じる可能性が 増えます。 対処予定: gfarm v2 の最初のリリースで対処します。 今のところ gfarm v1 での対処の予定はありません。 - gfarm ライブラリを既に利用開始しているプログラムが fork(2) した場合、 gfarm ライブラリの API を呼び出すことができるのは、親プロセスか子プ ロセスのどちらかだけです。両方がアクセスを行なった場合、gfsd サーバ プロセスに対する親子のリクエストが混ざってしまうことがあるため、 正しく動作しないことがあります。fork 前に確立した gfsd サーバとの コネクションは、親子で共有されているため、もし親と子が別のファイルを オープンした場合でも、同一の gfsd サーバへのアクセスとなる場合には、 問題が生じます。 また、親プロセスがファイルをオープン後 fork(2) し、子プロセスの側が そのファイルにアクセスする場合、親プロセスが exit(3) を呼んで終了する よりも前に、子プロセスからのアクセスは完了する必要があります。という のは、親プロセスが exit(3) 関数を呼んだ時に、gfsd に対して、そのファ イルのクローズ要求が送られるからです。このため、親プロセスが exit(3) した後は、子プロセスからのアクセスは失敗してしまいます。 さらに、親プロセスがファイルをオープン後 fork(2) した場合、子プロセス の側がそのファイルをクローズしても、そのクローズ要求は、gfsd へ送られ ません。従って、下記のような処理を行なった場合、ファイルディスクリプタ 不足のため、3. は失敗する可能性があります。 1. 親プロセスが同一の gfsd に対して多数のファイルをオープンした状態で fork(2) する。 2. 子プロセスは、そららのファイルを全てクローズする。 3. 子プロセスは、同じ gfsd が保持するファイルを多数オープンする。 これは、2. で行なったクローズが gfsd に伝わらず、gfsd が 1. でオープン したファイルのディスクリプタを保持し続けているからです。 対処予定: 未定です。 - 複製処理を途中で中断する方法がありません。 たとえ gfrep コマンドを kill しても、既にネットワーク間でのコピーを 開始しているフラグメントについては、それが完了するまで、コピーが 続いてしまいます。しかも、それでできた複製については、メタデータの 更新は行なわれません。 対処予定: 未定です。 - gfarm ライブラリは multithread safe ではありません。 対処予定: gfarm v2 で対処します。 今のところ gfarm v1 での対処の予定はありません。 - gfarm ライブラリは、単一プロセスが複数の異なるユーザ権限を使い分ける ようなアプリケーションからの利用を想定していません。 setuid() や setgid() を用いるようなアプリケーションからの利用を 想定していません。 対処予定: 未定です。 - NFS サーバとクライアントの組合せによっては、sharedsecret 認証に 失敗することがあります。 そのような問題があるか否かは、下記のコマンドを実行して、認証に 失敗することがある、すなわち gfhost の表示の第二欄が「s」ではなく 「x」となることがあるかどうかで確認できます。 sh -c 'seq 60 | while read n; do gfkey -f; gfhost -l 他のホスト; done' ここで「他のホスト」というのは、このコマンドを実行するホストと、 NFS でホームディレクトリを共有しているファイルシステムノードです。 この問題が生じる場合、下記のような方法のいずれかで回避できます。 ・「gfkey -f -p 秒数」で、有効期間を指定して鍵を生成することができます。 この期間を十分長く設定し、ジョブの実行中に、鍵の再生成が生じない ようにします。(デフォルトの有効期間は一日です。) ・認証方式を sharedsecert から、gsi_auth あるいは gsi に変更します。 ・問題の起きない NFS サーバに変更することによっても回避できます。 問題が生じることがあると確認された組合せ NFS サーバ NFS クライアント Linux 2.6.12 (Fedora Core 4) Linux 2.4.20 (RedHat 8) Linux 2.6.12 (Fedora Core 4) Linux 2.6.9 (Fedora Core 3) Linux 2.6.12 (Fedora Core 4) Linux 2.6.11 (Fedora Core 4) 問題が生じていない組合せ NFS サーバ NFS クライアント Solaris 2.6 Linux 2.4.18 (RedHat 8) NetBSD 3.0 Linux 2.4.18 (RedHat 8) 対処予定: 未定です。 - Globus をリンクして gfarm のバイナリを作成した場合、libgfarm とリンク されたプログラムが、SIGPIPE (broken pipe) シグナルを無視するように なります。 libgfarm と直接リンクしたプログラムだけでなく、システムコールフック ライブラリ経由で間接的に libgfarm とリンクした場合も同様です。 このため、たとえば「コマンド | head -1」のような処理が、最初の1行を 表示してすぐ終了するのではなく、そのコマンドが、全ての出力を既に クローズされたパイプに送りきるまで終了しないといった症状が起きます。 (ただし、そのコマンドが、このような状況で発生する EPIPE エラーを検知 していない場合のみ) 対処予定: Globus ライブラリ側での対処が必要なため、未定です。 - ファイルシステムノードのスプール領域としては、パス名の大文字小文字を 区別するファイルシステムのみをサポートしています。 MacOS や cygwin のファイルシステムや、FAT, NTFS などで、この問題が生じます。 対処予定: gfarm v2 では、スプールの構造上、この問題はありません。 gfarm v1 では仕様上の制限事項であり、対処の予定はありません。 - 設定可能な環境変数に関する参照マニュアルが存在しません。 対処予定: 未定です。 ● gfarm コマンド群に関する問題点 - gfrcmd の -l オプションは実装されていません。 対処予定: 未定です。 - gfrep は、複製先ホストをスケジュールする際に、最低空き容量 (gfarm.conf の "minimum_free_disk_space") の検査を行ないますが、これは起動時に一度 しか行なっていません。したがって、gfrep 実行中に最低空き容量を下回った 場合、そのホストが選ばれ続けてしまうという問題があります。 対処予定: 未定です。 - gfrep は、複製元ホスト選ぶ基準として、起動時のロードアベレージの低い順 を用いています。このため、gfrep コマンドを複数同時に並列で起動すると、 複製元ホストの選択が偏ってしまい、そのホストの負荷だけが高くなってしま うという問題が生じることがあります。 この問題は、同時に起動するのではなく、少しずつ起動時刻をずらすことで 回避できます。 なお、複製先ホストについては、可能な限りまんべんなく選択するように試み るので、この問題はありません。 対処予定: 未定です。 - gfmpirun は、MPICH/p4 にしか対応していません。また、全てのノードが 同じアーキテクチャで、かつ同じスプールディレクトリの絶対パスが 同一であると仮定しています。 MPICH/p4 でしか動作しない理由は、現時点の gfmpirun の実装が、 MPICH/p4 特有の -nolocal オプションを利用しているためです。 対処予定: 未定です。 - 下記のコマンドに関する参照マニュアルが存在しません。 config-agent, config-gfarm, config-gfsd, gfarm-pcp, gfarm-prun, gfarm.arch.guess, gfchmod, gfcombine, gfcombine_hook, gfcp, gfcp_hook, gfdump, gfrshl, gfsck, gfsplck, gfsshl, thput-gfpio 対処予定: 未定です。 ● システムコールフックに関する問題点 libgfs_hook に関する制限事項は、README.hook.ja に記述してあります。 そちらを御覧ください。 各問題点に関する対処の予定は、未定です。