Provided by: manpages-ja-dev_0.5.0.0.20131015+dfsg-2_all 
名前
open, creat - ファイルやデバイスのオープン、作成を行う
書式
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
int creat(const char *pathname, mode_t mode);
説明
ファイルの pathname を与えると、 open() はファイルディスクリプタを返す。 ファイルディスク
リプタは、この後に続くシステムコール (read(2), write(2), lseek(2), fcntl(2) など) で使用
される小さな非負の整数である。 このシステムコールが成功した場合に返されるファイルディスク
リプタは そのプロセスがその時点でオープンしていないファイルディスクリプタの うち最小の数字
のものとなる。
デフォルトでは、新しいファイルディスクリプタは execve(2) を実行した後も オープンされたまま
となる (つまり、 fcntl(2) に説明がある FD_CLOEXEC ファイルディスクリプタフラグは最初は無効
である; 後述の O_CLOEXEC フラグ を使うとこのデフォルトを変更することができる)。 ファイルオ
フセット (file offset) はファイルの先頭に設定される (lseek(2) 参照)。
open() を呼び出すと、「オープンファイル記述」 (open file description) が作成される。ファ
イル記述とは、システム全体の オープン中のファイルのテーブルのエントリである。 このエントリ
は、ファイルオフセットとファイル状態フラグ (fcntl(2) F_SETFL 操作により変更可能) が保持す
る。 ファイルディスクリプタはこれらのエントリの一つへの参照である。 この後で pathname が削
除されたり、他のファイルを参照するように変更されたりしても、 この参照は影響を受けない。 新
しいオープンファイル記述は最初は他のどのプロセスとも 共有されていないが、 fork(2) で共有
が起こる場合がある。
引き数 flags には、アクセスモード O_RDONLY, O_WRONLY, O_RDWR のどれかひとつが入っていなけ
ればならない。 これらはそれぞれ読み込み専用、書き込み専用、読み書き用に ファイルをオープン
することを要求するものである。
さらに、 flags には、ファイル作成フラグ (file creation flag) とファイル状態フラグ (file
status flag) を 0 個以上「ビット単位の OR (bitwise-or)」で 指定することができる。 ファイル
作成フラグ は O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TRUNC,
O_TTY_INIT である。 ファイル状態フラグ は以下のリストのうち上記以外の残りのものである。 二
種類のフラグの違いは、ファイル状態フラグの方は fcntl(2) を使ってその内容を取得したり (場合
によっては) 変更したりできる点にある。 ファイル作成フラグとファイル状態フラグの全リストを
以下に示す:
O_APPEND
ファイルを追加 (append) モードでオープンする。 毎回の write(2) の前に lseek(2) を
行ったかのように、ファイルポインタをファイルの最後に移動する。 NFS ファイルシステム
で、 O_APPEND を使用すると、複数のプロセスがひとつのファイルに同時にデータを追加し
た場合、 ファイルが壊れてしまうことがある。 これは NFS が追加モードをサポートしてい
ないため、 クライアントのカーネル (kernel) がそれをシミュレートしなければならないの
だが、 競合状態を避けることはできないからである。
O_ASYNC
シグナル駆動 I/O (signal-driven I/O) を有効にする: このファイルディスクリプタへの
入力または出力が可能になった場合に、シグナルを生成する (デフォルトは SIGIO である
が、 fcntl(2) によって変更可能である)。 この機能が使用可能なのは端末、疑似端末、ソ
ケットのみであり、 (Linux 2.6 以降では) パイプと FIFO に対しても使用できる。 さらに
詳しい説明は fcntl(2) を参照すること。
O_CLOEXEC (Linux 2.6.23 以降)
新しいファイルディスクリプタに対して close-on-exec フラグを有効にする。 このフラグ
を指定することで、プログラムは FD_CLOEXEC フラグをセットするための fcntl(2)
F_SETFD 操作を別途呼び出す必要がなくなる。 また、ある種のマルチスレッドのプログラム
はこのフラグの使用は 不可欠である。なぜなら、個別に FD_CLOEXEC フラグを設定する
fcntl(2) F_SETFD 操作を呼び出したとしても、あるスレッドがファイルディスクリプタを
オープンするのと同時に別のスレッドが fork(2) と execve(2) を実行するという競合条
件を避けるのには十分ではないからである。
O_CREAT
ファイルが存在しなかった場合は作成 (create) する。 ファイルの所有者 (ユーザー ID)
は、プロセスの実効ユーザー ID に設定される。 グループ所有権 (グループ ID) は、プロ
セスの実効グループ ID または親ディレクトリのグループ ID に設定される (これは、ファ
イルシステムタイプ、マウントオプション、 親ディレクトリのモードに依存する。
mount(8) で説明されているマウントオプション bsdgroups と sysvgroups を参照)。
mode は新しいファイルを作成する場合に使用するアクセス許可 (permission) を指定する。
flags に O_CREAT が指定されている場合、 mode を指定しなければならない。 O_CREAT が
指定されていない場合、 mode は無視される。 有効なアクセス許可は、普段と同じようにプ
ロセスの umask によって修正され、作成されたファイルの許可は (mode & ~umask) とな
る。 このモードは、新しく作成されたファイルに対するそれ以降のアクセス にのみ適用さ
れる点に注意すること。 読み取り専用のファイルを作成する open() コールであっても、
読み書き可能なファイルディスクリプタを返すことがありうる。
mode のために以下のシンボル定数が提供されている :
S_IRWXU 00700 ユーザー (ファイルの所有者) に読み込み、書き込み、 実行の許可があ
る。
S_IRUSR 00400 ユーザーに読み込みの許可がある。
S_IWUSR 00200 ユーザーに書き込みの許可がある。
S_IXUSR 00100 ユーザーに実行の許可がある。
S_IRWXG 00070 グループに読み込み、書き込み、実行の許可がある。
S_IRGRP 00040 グループに読み込みの許可がある。
S_IWGRP 00020 グループに書き込みの許可がある。
S_IXGRP 00010 グループに実行の許可がある。
S_IRWXO 00007 他人 (others) に読み込み、書き込み、実行の許可がある。
S_IROTH 00004 他人に読み込みの許可がある。
S_IWOTH 00002 他人に書き込みの許可がある。
S_IXOTH 00001 他人に実行の許可がある。
O_DIRECT (Linux 2.4.10 以降)
このファイルに対する I/O のキャッシュの効果を最小化しようとする。このフラグを使う
と、一般的に性能が低下する。 しかしアプリケーションが独自にキャッシングを行っている
ような 特別な場合には役に立つ。 ファイルの I/O はユーザー空間バッファに対して直接行
われる。 O_DIRECT フラグ自身はデータを同期で転送しようとはするが、 O_SYNC フラグの
ようにデータと必要なメタデータの転送が保証されるわけではない。同期 I/O を保証するた
めには、 O_DIRECT に加えて O_SYNC を使用しなければならない。下記の「注意」の節の議
論も参照。
ブロックデバイスに対する似通った意味のインターフェースが raw(8) で説明されている
(但し、このインタフェースは非推奨である)。
O_DIRECTORY
pathname がディレクトリでなければオープンは失敗する。 このフラグは Linux 特有であ
り、 opendir(3) が FIFO やテープデバイスに対してコールされた場合の サービス不能
(denial-of-service) 攻撃を避けるために カーネル 2.1.126 で追加された。
O_EXCL この呼び出しでファイルが作成されることを保証する。このフラグが O_CREAT と 一緒に指
定され、 pathname のファイルが既に存在した場合、 open() は失敗 する。
これら二つのフラグが指定された際、シンボリックリンクは辿られない。 pathname がシン
ボリックリンクの場合、 シンボリックリンクがどこを指しているかに関わらず open() は
失敗する。
一般的には、 O_CREAT を指定せずに O_EXCL を使用した場合の O_EXCL の動作は規定されて
いない。 これには一つ例外があり、Linux 2.6 以降では、 pathname がブロックデバイスを
参照している場合、 O_CREAT なしで O_EXCL を使用することができる。 システムがそのブ
ロックデバイスを使用中の場合 (例えば、 マウントされているなど)、 open() はエラー
EBUSY で失敗する。
NFS では、 O_EXCL は、Linux 2.6 以降で NFSv3 以降を使っている場合でのみサポートされ
る。 O_EXCL サポートが提供されていない NFS 環境では、このフラグに頼って ロック処理
を実行するプログラムは競合状態 (race condition) に出会う 可能性がある。 ロックファ
イルを使用して不可分 (atomic) なファイルロックを実現し、 NFS が O_EXCL をサポートし
ているかに依存しないようにしたい場合、 移植性のある方法は、同じファイルシステム上に
他と名前の重ならない ファイル (例えばホスト名と PID を組み合わせた名前) を作成し、
link(2) を使用してそのロックファイルへのリンクを作成することである。 link(2) コー
ルの返り値が 0 ならばロックに成功している。 あるいは、そのファイルに stat(2) を使
用してリンク数 (link count) が 2 になっているかをチェックする。 そうなっていれ
ば、同じくロックに成功しているということである。
O_LARGEFILE
(LFS) off_t ではサイズを表せない (だだし off64_t ではサイズを表せる)ファ イルをオー
プン可能にする。この定義を有効にするためには、(どのヘッダファイ ルをインクルードす
るよりも前に) _LARGEFILE64_SOURCE マクロを定義しなければ ならない。 32 ビットシステ
ムにおいて大きなファイルにアクセスしたい場合、 (O_LARGEFILE を使うよりも)
_FILE_OFFSET_BITS 機能検査マクロを 64 に セットする方が望ましい方法である
(feature_test_macros(7) を参照)。
O_NOATIME (Linux 2.6.8 以降)
ファイルに対して read(2) が実行されたときに、最終アクセス時刻 (inode の st_atime)
を更新しない。 このフラグはインデックス作成やバックアッププログラムで使うことを意図
している。 これを使うとディスクに対する操作を大幅に減らすことができる。 このフラグ
は全てのファイルシステムに対して有効であるわけではない。 その一例が NFS であ
り、サーバがアクセス時刻を管理している。
O_NOCTTY
pathname が端末 (terminal) デバイス — tty(4) 参照 — を指している 場合に、たとえその
プロセスが制御端末を持っていなくても、オープンしたファイル は制御端末にはならない。
O_NOFOLLOW
pathname がシンボリックリンクだった場合、オープンは失敗する。 これは FreeBSD の拡張
で、Linux には バージョン 2.1.126 で追加された。 このフラグが指定された場合でも
pathname の前の方の要素 (最後のディレクトリセパレータより前の部分) にあるシンボリッ
クリンクについてはリンクが辿られる。 下記の O_PATH も参照のこと。
O_NONBLOCK または O_NDELAY
可能ならば、ファイルは非停止 (nonblocking) モードでオープンされる。 open() も、返し
たファイルディスクリプタに対する以後のすべての操作も呼び出 したプロセスを待たせるこ
とはない。 FIFO (名前付きパイプ) を扱う場合には fifo(7) も参照すること。 強制ファイ
ルロック (mandatory file lock) やファイ ルリース (file lease) と組み合わせた場合
の、 O_NONBLOCK の効果についての 議論は、 fcntl(2) を参照すること。
O_PATH (Linux 2.6.39 以降)
このフラグを指定して取得したファイルディスクリプタは、 ファイルシステムツリー内での
場所を示すため、 純粋にファイルディスクリプタレベルでの作用する操作を実行するため、
の二つの目的で使用することができる。 ファイル自身はオープンされず、 他のファイル操
作 (例えば read(2), write(2), fchmod(2), fchown(2), fgetxattr(2), mmap(2)) はエラー
EBADF で失敗する。
取得したファイルディスクリプタに対して以下の操作を行うことが「できる」。
* close(2); fchdir(2) (Linux 3.5 以降); fstat(2) (Linux 3.6 以降)
* ファイルディスクリプタの複製 (dup(2), fcntl(2) F_DUPFD など)
* ファイルディスクリプタフラグの取得と設定 (fcntl(2) の F_GETFD と F_SETFD)
* fcntl(2) の F_GETFL 操作を使ったオープンされたファイルの状態フラグの取得。 返さ
れるフラグには O_PATH ビットが含まれる。
* openat(2) や他の "*at()" 系のシステムコールの dirfd 引数としてそのファイルディス
クリプタを渡す。
* そのファイルディスクリプタを別のプロセスに UNIX ドメインソケット経由で渡す。
(unix(7) の SCM_RIGHTS を参照)
flags に O_PATH が指定された場合、 O_DIRECTORY と O_NOFOLLOW 以外のフラグビットは無
視される。
O_NOFOLLOW フラグも合わせて指定された場合、 この呼び出しではシンボリックリンクを参
照するファイルディスクリプタを返す。 このファイルディスクリプタは、 空のパス名を指
定した fchownat(2), fstatat(2), linkat(2), readlinkat(2) の呼び出しで dirfd 引数と
して使うことで、 そのシンボリックリンクに対して操作を行うことができる。
O_SYNC ファイルは同期 (synchronous) I/O モードでオープンされる。 open() が返したファイル
ディスクリプタに対して write(2) を行うと、必ず呼び出したプロセスをブロックし、 該
当ハードウェアに物理的に書き込まれるまで返らない。 以下の「注意」の章も参照。
O_TRUNC
ファイルが既に存在し、通常ファイルであり、 書き込み可モードでオープンされている (つ
まり、 O_RDWRまたはO_WRONLY の) 場合、長さ 0 に切り詰め (truncate) られる。 ファイ
ルが FIFO または端末デバイスファイルの場合、 O_TRUNC フラグは無視される。 それ以外
の場合、 O_TRUNC の効果は未定義である。
これらの選択フラグのいくつかはファイルをオープンした後でも fcntl(2) を使用して変更するこ
とができる。
creat() は flags に O_CREAT|O_WRONLY|O_TRUNC を指定して open() を行うのと等価である。
返り値
open() と creat() は新しいファイルディスクリプタを返す。 エラーが発生した場合は -1 を返
す (その場合は errno が適切に設定される)。
エラー
EACCES ファイルに対する要求されたアクセスが許されていないか、 pathname のディレクトリ部分
の何れかのディレクトリに検索許可がなかった。 またはファイルが存在せず、親ディレクト
リへの書き込み許可がなかった。 (path_resolution(7) も参照すること。)
EDQUOT O_CREAT が指定された場合で、そのファイルが存在せず、ディスクブロックか inode がその
ファイルシステムのユーザクォータに達していた。
EEXIST pathname は既に存在し、 O_CREAT と O_EXCL が使用された。
EFAULT pathname がアクセス可能なアドレス空間の外を指している。
EFBIG EOVERFLOW 参照。
EINTR 遅いデバイス (例えば FIFO、 fifo(7) 参照) のオープンが完了するのを待って停止してい
る間に システムコールがシグナルハンドラにより割り込まれた。 signal(7) 参照。
EINVAL ファイルシステムが O_DIRECT フラグをサポートしていない。 詳細は注意を参照。
EISDIR pathname はディレクトリを参照しており、書き込み要求が含まれていた (つまり O_WRONLY
または O_RDWR が設定されている)。
ELOOP pathname を解決する際に遭遇したシンボリックリンクが多過ぎる。 または O_NOFOLLOW が
指定されており、 pathname がシンボリックリンクだった。
EMFILE プロセスがオープンしているファイル数がすでに最大数に達している。
ENAMETOOLONG
pathname が長過ぎる。
ENFILE オープンされているファイルの総数がシステムの制限に達している。
ENODEV pathname がデバイススペシャルファイルを参照しており、対応するデバイスが存在しない。
(これは Linux カーネルのバグであり、この場合には ENXIO が返されるべきである)
ENOENT O_CREAT が設定されておらず、かつ指定されたファイルが存在しない。 または、 pathname
のディレクトリ部分が存在しないか壊れた (dangling) シンボリックリンクである。
ENOMEM 十分なカーネルメモリーがない。
ENOSPC pathname を作成する必要があるが、 pathname を含んでいるデバイスに新しいファイルのた
めの空き容量がない。
ENOTDIR
pathname に含まれるディレクトリ部分のどれかが実際にはディレクトリでない。 または
O_DIRECTORY が指定されており、 pathname がディレクトリでない。
ENXIO O_NONBLOCK | O_WRONLY が設定されており、指定したファイルが FIFO で そのファイルを読
み込みのためにオープンしているプロセスが存在しない。 または、ファイルがデバイススペ
シャルファイルで 対応するデバイスが存在しない。
EOVERFLOW
pathname が参照しているのが、大き過ぎてオープンできない通常のファイルである。 通
常、このエラーが発生するは、32 ビットプラットフォーム上で -D_FILE_OFFSET_BITS=64 を
指定せずにコンパイルされたアプリケーションが、ファイルサイズが (2<31)-1 ビットを超
えるファイルを開こうとした場合である。 上記の O_LARGEFILE も参照。 これは
POSIX.1-2001 で規定されているエラーである。 2.6.24 より前のカーネルでは、Linux はこ
の場合にエラー EFBIG を返していた。
EPERM O_NOATIME フラグが指定されたが、呼び出し元の実効ユーザー ID が ファイルの所有者と一
致せず、かつ呼び出し元に特権 (CAP_FOWNER) がない。
EROFS pathname が読み込み専用のファイルシステム上のファイルを参照しており、 書き込みアク
セスが要求された。
ETXTBSY
pathname が現在実行中の実行イメージを参照しており、書き込みが要求された。
EWOULDBLOCK
O_NONBLOCK フラグが指定されたが、そのファイルには矛盾するリースが設定されていた
(fcntl(2) 参照)。
準拠
SVr4, 4.3BSD, POSIX.1-2001. フラグ O_DIRECTORY, O_NOATIME, O_NOFOLLOW, O_PATH は Linux 特
有のものであり、 これらのフラグの定義を得るためには、 (「どの」ヘッダファイルをインクルー
ドするよりも前に) _GNU_SOURCE を定義する必要があるかもしれない。
O_CLOEXEC フラグは POSIX.1-2001 では規定されていないが、 POSIX.1-2008 で規定されている。
O_DIRECT は POSIX では規定されていない。 O_DIRECT の定義を得るには (「どの」ヘッダファイル
をインクルードするよりも前に) _GNU_SOURCE を定義しなければならない。
注意
Linux では、 O_NONBLOCK フラグは、 open を実行したいが read または write を実行する意図は
必ずしもないことを意味する。 これは ioctl(2) のためのファイルディスクリプタを取得するため
に、 デバイスをオープンするときによく用いられる。
「アクセスモード」の値 O_RDONLY, O_WRONLY, O_RDWR は、 flags に指定できる他の値と違
い、個々のビットを指定するものではなく、 これらの値は flags の下位 2 ビットを定義する。
O_RDONLY, O_WRONLY, O_RDWR はそれぞれ 0, 1, 2 に定義されている。 言い換えると、 O_RDONLY |
O_WRONLY の組み合わせは論理的に間違いであり、確かに O_RDWR と同じ意味ではない。 Linux で
は、特別な、非標準なアクセスモードとして 3 (バイナリでは 11) が 予約されており flags に指
定できる。 このアクセスモードを指定すると、ファイルの読み出し/書き込み許可をチェックし、
読み出しにも書き込みにも使用できないディスクリプタを返す。 この非標準のアクセスモードはい
くつかの Linux ドライバで、デバイス固有の ioctl(2) 操作にのみ使用されるディスクリプタを返
すために使われている。
O_RDONLY | O_TRUNC の影響は未定義であり、その動作は実装によって異なる。 多くのシステムでは
ファイルは実際に切り詰められる。
NFS を実現しているプロトコルには多くの不備があり、特に O_SYNC と O_NDELAY に影響する。
POSIX では、3 種類の同期 I/O が提供されており、 O_SYNC, O_DSYNC, O_RSYNC フラグがこれに対
応するものである。 今のところ (カーネル 2.6.31)、 Linux では O_SYNC だけが実装されている
が、 glibc は O_DSYNC と O_RSYNC に O_SYNC と同じ数値を割り当てている。 ほとんどの Linux
のファイルシステムは、実際には POSIX の O_SYNC の動作ではなく O_DSYNC の動作だけを実装して
いる。 POSIX の O_SYNC では、 open() がユーザ空間に返る際に、書き込みに関する全てのメタ
データの 更新がディスクに書き込まれている必要がある。 一方、 O_DSYNC では、 open() が返る
までに、実際のファイルのデータとそのデータを取得するために 必要なメタデータだけがディスク
に書き込まれていればよい。
open() はスペシャルファイルをオープンすることができるが、 creat() でスペシャルファイルを
作成できない点に注意すること。 代わりに mknod(2) を使用する。
UID マッピングを使用している NFS ファイルシステムでは、 open() がファイルディスクリプタを
返した場合でも read(2) が EACCES で拒否される場合がある。 これはクライアントがアクセス許可
のチェックを行って open() を実行するが、読み込みや書き込みの際には サーバーで UID マッピン
グが行われるためである。
ファイルが新しく作成されると、 ファイルの st_atime, st_ctime, st_mtime フィールド (それぞ
れ最終アクセス時刻、最終状態変更時刻、最終修正時刻である。 stat(2) 参照) が現在時刻に設定
される。 さらに親ディレクトリの st_ctime と st_mtime も現在時刻に設定される。 それ以外の場
合で、O_TRUNC フラグでファイルが修正されたときは、 ファイルの st_ctime と st_mtime フィー
ルドが現在時刻に設定される。
O_DIRECT
O_DIRECT フラグを使用する場合、ユーザ空間バッファの長さやアドレス、 I/O のファイルオフセッ
トに関してアラインメントの制限が課されることがある。 Linux では、アラインメントの制限は
ファイルシステムやカーネルのバージョンに よって異なり、全く制限が存在しない場合もある。 し
かしながら、現在のところ、指定されたファイルやファイルシステムに対して こうした制限がある
かを見つけるための、アプリケーション向けのインタフェースで ファイルシステム非依存のものは
存在しない。 いくつかのファイルシステムでは、制限を確認するための独自のインタフェースが 提
供されている。例えば、 xfsctl(3) の XFS_IOC_DIOINFO 命令である。
Linux 2.4 では、転送サイズ、 ユーザーバッファのアラインメント、ファイルオフセットは、 ファ
イルシステムの論理ブロックサイズの倍数でなければならない。 Linux 2.6 では、512 バイトごと
の境界に配置されていれば充分である。
メモリバッファがプライベートマッピング (mmap(2) の MAP_PRIVATE フラグで作成されたマッピン
グ) の場合には、O_DIRECT I/O は fork(2) システムコールと同時に決して実行すべきではない (プ
ライベートマッピングには、ヒープ領域に割り当てられたメモリや静的に 割り当てたバッファも含
まれる)。非同期 I/O インターフェース (AIO) 経由 やプロセス内の他のスレッドから発行され
た、このような I/O は、 fork(2) が呼び出される前に完了されるべきである。 そうしなかった場
合、データ破壊や、親プロセスや子プロセスでの予期しない 動作が起こる可能性がある。 O_DIRECT
I/O 用のメモリバッファが shmat(2) やMAP_SHARED フラグ 付きの mmap(2) で作成された場合に
は、この制限はあてはまらない。 madvise(2) でメモリバッファにアドバイス MADV_DONTFORK が設
定され ている場合にも、この制限はあてはまらない(MADV_DONTFORK はそのメモリ バッファが
fork(2) 後に子プロセスからは利用できないことを保証するも のである)。
O_DIRECT フラグは SGI IRIX で導入された。SGI IRIX にも Linux 2.4 と同様の (ユーザーバッ
ファの) アラインメントの制限がある。 また、IRIX には適切な配置とサイズを取得するための
fcntl(2) コールがある。 FreeBSD 4.x も同じ名前のフラグを導入したが、アラインメントの制限
はない。
O_DIRECT が Linux でサポートされたのは、カーネルバージョン 2.4.10 である。 古い Linux カー
ネルは、このフラグを単に無視する。 O_DIRECT フラグをサポートしていないファイルシステムもあ
り、その場合は、 O_DIRECT を使用すると open() は EINVAL で失敗する。
アプリケーションは、同じファイル、 特に同じファイルの重複するバイト領域に対して、 O_DIRECT
と通常の I/O を混ぜて使うのは避けるべきである。 ファイルシステムがこのような状況において一
貫性の問題を正しく 扱うことができる場合であっても、全体の I/O スループットは どちらか一方
を使用するときと比べて低速になるであろう。 同様に、アプリケーションは、同じファイルに対し
て mmap(2) と直接 I/O (O_DIRECT) を混ぜて使うのも避けるべきである。
NFS で O_DIRECT を使った場合の動作はローカルのファイルシステムの場合と違う。 古いカーネル
や、ある種の設定でコンパイルされたカーネルは、 O_DIRECT と NFS の組み合わせをサポートして
いないかもしれない。 NFS プロトコル自体はサーバにフラグを渡す機能は持っていないので、
O_DIRECT I/O はクライアント上のページキャッシュをバイパスするだけになり、 サーバは I/O を
キャッシュしているかもしれない。 クライアントは、 O_DIRECT の同期機構を保持するため、サー
バに対して I/O を同期して行うように依頼する。 サーバによっては、こうした状況下、特に I/O
サイズが小さい場合に 性能が大きく劣化する。 また、サーバによっては、I/O が安定したストレー
ジにまで行われたと、 クライアントに対して嘘をつくものもある。 これは、サーバの電源故障が起
こった際にデータの完全性が保たれない 危険は少しあるが、性能面での不利な条件を回避するため
に行われている。 Linux の NFS クライアントでは O_DIRECT I/O でのアラインメントの制限はな
い。
まとめると、 O_DIRECT は、注意して使うべきであるが、強力なツールとなる可能性を持っている。
アプリケーションは O_DIRECT をデフォルトでは無効になっている性能向上のためのオプションと
考えておくのがよいであろう。
「O_DIRECT でいつも困るのは、インタフェース全部が本当にお馬鹿な点だ。 たぶん危ない
マインドコントロール剤で 頭がおかしくなったサルが設計したんじゃないかな」 — Linus
バグ
現在のところ、 open() の呼び出し時に O_ASYNC を指定してシグナル駆動 I/O を有効にすること
はできない。 このフラグを有効にするには fcntl(2) を使用すること。
関連項目
chmod(2), chown(2), close(2), dup(2), fcntl(2), link(2), lseek(2), mknod(2), mmap(2),
mount(2), openat(2), read(2), socket(2), stat(2), umask(2), unlink(2), write(2), fopen(3),
fifo(7), path_resolution(7), symlink(7)
この文書について
この man ページは Linux man-pages プロジェクトのリリース 3.54 の一部 である。プロジェクト
の説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。