で追加された。
.TP
\fBO_DSYNC\fP
-Write operations on the file will complete according to the requirements of
-synchronized I/O \fIdata\fP integrity completion.
+ファイルに対する書き込み操作は、同期 I/O の\fIデータ\fP完全性完了の要件に基づいて行われる。
-By the time \fBwrite\fP(2) (and similar) return, the output data has been
-transferred to the underlying hardware, along with any file metadata that
-would be required to retrieve that data (i.e., as though each \fBwrite\fP(2)
-was followed by a call to \fBfdatasync\fP(2)). \fISee NOTES below\fP.
+\fBwrite\fP(2) (や同様のコール) が返るまでに、
+書き込まれたデータおよびデータを取得するのに必要なファイルメタデータが裏で利用されているハードウェアに転送される (つまり、\fBwrite\fP(2)
+の後に \fBfdatasync\fP(2) を呼び出したのと同じようになる)。 \fI下記の「注意」も参照のこと\fP。
.TP
\fBO_EXCL\fP
この呼び出しでファイルが作成されることを保証する。このフラグが \fBO_CREAT\fP と
\fIdirfd\fP 引数として使うことで、 そのシンボリックリンクに対して操作を行うことができる。
.TP
\fBO_SYNC\fP
-Write operations on the file will complete according to the requirements of
-synchronized I/O \fIfile\fP integrity completion (by contrast with contrast
-with the synchronized I/O \fIdata\fP integrity completion provided by
-\fBO_DSYNC\fP.)
+ファイルに対する書き込み操作は、同期 I/O の\fIファイル\fP完全性完了の要件に基づいて行われる (これに対し \fBO_DSYNC\fP では同期 I/O
+の\fIデータ\fP完全性完了が提供される)。
-By the time \fBwrite\fP(2) (and similar) return, the output data and
-associated file metadata have been transferred to the underlying hardware
-(i.e., as though each \fBwrite\fP(2) was followed by a call to \fBfsync\fP(2)).
-\fISee NOTES below\fP.
+\fBwrite\fP(2) (や同様のコール) が返るまでに、 書き込まれたデータと関連するファイルメタデータが裏で利用されているハードウェアに転送される
+(つまり、\fBwrite\fP(2) の後に \fBfsync\fP(2) を呼び出したのと同じようになる)。 \fI下記の「注意」も参照のこと\fP。
.TP
\fBO_TMPFILE\fP (Linux 3.11 以降)
.\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e
.IP
.\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788
.\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe
-\fBO_TMPFILE\fP requires support by the underlying filesystem; only a subset of
-Linux filesystems provide that support. In the initial implementation,
-support was provided in the ext2, ext3, ext4, UDF, Minix, and shmem
-filesystems. XFS support was added in Linux 3.15.
+\fBO_TMPFILE\fP は、 裏で利用されるファイルシステムによるサポートが必要である。 一部の Linux
+ファイルシステムだけがこの機能をサポートしている。 最初の実装では、 ext2, ext3, ext4, UDF, Minix, shmem
+ファイルシステムがサポートしていた。 XFS でのサポートが Linux 3.15 で追加された。
.TP
\fBO_TRUNC\fP
ファイルが既に存在し、通常ファイルであり、 アクセスモードで書き込みが許可されている (つまり、 \fBO_RDWR\fP または \fBO_WRONLY\fP
(それぞれ最終アクセス時刻、最終状態変更時刻、最終修正時刻である。 \fBstat\fP(2) 参照) が現在時刻に設定される。 さらに親ディレクトリの
\fIst_ctime\fP と \fIst_mtime\fP も現在時刻に設定される。 それ以外の場合で、O_TRUNC フラグでファイルが修正されたときは、
ファイルの \fIst_ctime\fP と \fIst_mtime\fP フィールドが現在時刻に設定される。
-.SS 同期入出力
-The POSIX.1\-2008 "synchronized I/O" option specifies different variants of
-synchronized I/O, and specifies the \fBopen\fP() flags \fBO_SYNC\fP, \fBO_DSYNC\fP,
-and \fBO_RSYNC\fP for controlling the behavior. Regardless of whether an
-implementation supports this option, it must at least support the use of
-\fBO_SYNC\fP for regular files.
-
-Linux implements \fBO_SYNC\fP and \fBO_DSYNC\fP, but not \fBO_RSYNC\fP. (Somewhat
-incorrectly, glibc defines \fBO_RSYNC\fP to have the same value as \fBO_SYNC\fP.)
-
-\fBO_SYNC\fP provides synchronized I/O \fIfile\fP integrity completion, meaning
-write operations will flush data and all associated metadata to the
-underlying hardware. \fBO_DSYNC\fP provides synchronized I/O \fIdata\fP integrity
-completion, meaning write operations will flush data to the underlying
-hardware, but will only flush metadata updates that are required to allow a
-subsequent read operation to complete successfully. Data integrity
-completion can reduce the number of disk operations that are required for
-applications that don't need the guarantees of file integrity completion.
-
-To understand the difference between the the two types of completion,
-consider two pieces of file metadata: the file last modification timestamp
-(\fIst_mtime\fP) and the file length. All write operations will update the
-last file modification timestamp, but only writes that add data to the end
-of the file will change the file length. The last modification timestamp is
-not needed to ensure that a read completes successfully, but the file length
-is. Thus, \fBO_DSYNC\fP would only guarantee to flush updates to the file
-length metadata (whereas \fBO_SYNC\fP would also always flush the last
-modification timestamp metadata).
-
-Before Linux 2.6.33, Linux implemented only the \fBO_SYNC\fP flag for
-\fBopen\fP(). However, when that flag was specified, most filesystems actually
-provided the equivalent of synchronized I/O \fIdata\fP integrity completion
-(i.e., \fBO_SYNC\fP was actually implemented as the equivalent of \fBO_DSYNC\fP).
+.SS "同期 I/O"
+POSIX.1\-2008 の「同期 I/O」の選択肢として複数種類が規定されており、 動作を制御するために \fBopen\fP() フラグとして
+\fBO_SYNC\fP, \fBO_DSYNC\fP, \fBO_RSYNC\fP が規定されている。 この選択肢を実装がサポートしているかに関わらず、
+各実装では少なくとも通常のファイルに対して \fBO_SYNC\fP が利用できなければならない。
+
+Linux は \fBO_SYNC\fP と \fBO_DSYNC\fP を実装しているが、 \fBO_RSYNC\fP は実装していない (少し間違っているのだが、
+glibc では \fBO_RSYNC\fP が \fBO_SYNC\fP と同じ値で定義されている)。
+
+\fBO_SYNC\fP は、 同期 I/O での\fIファイル\fP完全性完了を提供する。 つまり、
+書き込み操作はデータとすべての関連メタデータを裏で利用されているハードウェアにフラッシュすることを意味する。 \fBO_DSYNC\fP は、 同期 I/O
+での\fIデータ\fP完全性完了を提供する。 つまり、 書き込み操作はデータを裏で利用されているハードウェアにフラッシュするが、
+それ以降の読み出し操作が正常に完了するのに必要なメタデータの更新のみをフラッシュする。 データ完全性完了は、
+ファイル完全性完了を必要としないアプリケーションで、 ディスク操作の数を減らすことができる。
+
+2 種類の完了の違いを理解するために、 ファイルメタデータの 2 つの要素、 ファイルの最終修正時刻 (\fIst_mtime\fP)
+とファイル長、を考える。 すべての書き込み操作は最終修正時刻を更新するが、 ファイルの末尾にデータを追加する書き込み操作のみがファイル長を変更する。
+最終修正時刻は、 読み出しが正常に完了するのに必要ではないが、 ファイル長は必要である。 したがって、 \fBO_DSYNC\fP
+はファイル長のメタデータの更新がフラッシュされることだけを保証する (これに対して \fBO_SYNC\fP
+では最終修正時刻のメタデータも常にフラッシュされる)。
+
+Linux 2.6.33 より前では、 Linux は \fBopen\fP() では \fBO_SYNC\fP フラグのみを実装していた。 しかしながら、
+このフラグが指定された場合、 ほとんどのファイルシステムで提供されていたのは実際には同期 I/O での\fIデータ\fP完全性完了と等価なものであった
+(つまり、 \fBO_SYNC\fP は実際には \fBO_DSYNC\fP と等価なものとして実装されていた)。
.\"
.\"
-Since Linux 2.6.33, proper \fBO_SYNC\fP support is provided. However, to
-ensure backward binary compatibility, \fBO_DSYNC\fP was defined with the same
-value as the historical \fBO_SYNC\fP, and \fBO_SYNC\fP was defined as a new
-(two\-bit) flag value that includes the \fBO_DSYNC\fP flag value. This ensures
-that applications compiled against new headers get at least \fBO_DSYNC\fP
-semantics on pre\-2.6.33 kernels.
+Linux 2.6.33 行こう では、 正しい \fBO_SYNC\fP のサポートが提供されている。 しかしながら、
+バイナリレベルの後方互換性を保証するため、 \fBO_DSYNC\fP は以前の \fBO_SYNC\fP と同じ値で定義されており、 \fBO_SYNC\fP は
+\fBO_DSYNC\fP フラグの値を含む新しい (2 ビットの) フラグ値として定義されている。 これにより、
+新しいヘッダを使ってコンパイルされたアプリケーションで、 2.6.33 より前のカーネルで少なくとも \fBO_DSYNC\fP
+の動作は同じになることが保証される。
.SS NFS
NFS を実現しているプロトコルには多くの不備があり、特に \fBO_SYNC\fP と \fBO_NDELAY\fP に影響する。
この非標準のアクセスモードはいくつかの Linux ドライバで、デバイス固有の \fBioctl\fP(2)
操作にのみ使用されるディスクリプタを返すために使われている。
.SS "openat() や他のディレクトリファイルディスクリプタ API の基本原理"
-\fBopenat\fP() and the other system calls and library functions that take a
-directory file descriptor argument (i.e., \fBfaccessat\fP(2),
+\fBopenat\fP() やディレクトリファイルディスクリプタを引き数を取る他のシステムコールやライブラリ関数 (\fBfaccessat\fP(2),
\fBfanotify_mark\fP(2), \fBfchmodat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2),
\fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmknodat\fP(2),
\fBname_to_handle_at\fP(2), \fBreadlinkat\fP(2), \fBrenameat\fP(2), \fBsymlinkat\fP(2),
-\fBunlinkat\fP(2), \fButimensat\fP(2) \fBmkfifoat\fP(3), and \fBscandirat\fP(3)) are
-supported for two reasons. Here, the explanation is in terms of the
-\fBopenat\fP() call, but the rationale is analogous for the other interfaces.
-
-First, \fBopenat\fP() allows an application to avoid race conditions that
-could occur when using \fBopen\fP() to open files in directories other than
-the current working directory. These race conditions result from the fact
-that some component of the directory prefix given to \fBopen\fP() could be
-changed in parallel with the call to \fBopen\fP(). Such races can be avoided
-by opening a file descriptor for the target directory, and then specifying
-that file descriptor as the \fIdirfd\fP argument of \fBopenat\fP().
+\fBunlinkat\fP(2), \fButimensat\fP(2) \fBmkfifoat\fP(3), \fBscandirat\fP(3))
+は二つの理由から用意されている。 ここでは、 \fBopenat\fP コールに関して説明するが、この基本原理は他のインターフェースでも同じである。
+
+最初の理由として、 \fBopenat\fP() を使うと、 アプリケーションは、 カレントワーキングディレクトリ以外のディレクトリで \fBopen\fP()
+を使ってファイルをオープンする際に起こり得る競合条件を避けることができる。 これらの競合条件は、 \fBopen\fP()
+に渡されたディレクトリプレフィックスの構成要素が \fBopen\fP() の呼び出しと並行して変化する可能性があるという点に由来している。
+このような競合条件は、 対象のディレクトリに対するファイルディスクリプタをオープンし、 それから \fBopenat\fP() の \fIdirfd\fP
+引き数としてそのファイルディスクリプタを指定することで、 避けることができる。
.\"
.\"
-Second, \fBopenat\fP() allows the implementation of a per\-thread "current
-working directory", via file descriptor(s) maintained by the application.
-(This functionality can also be obtained by tricks based on the use of
-\fI/proc/self/fd/\fPdirfd, but less efficiently.)
+二つ目として、 \fBopenat\fP() を使うと、アプリケーションが管理するファイルディスクリプタにより、
+スレッド単位の「カレントワーキングディレクトリ」を実装することができる (この機能は、 \fI/proc/self/fd/dirfd\fP
+を使った方法でも実現することができるが、 効率の面で落とる)。
.SS O_DIRECT
.LP
\fBO_DIRECT\fP フラグを使用する場合、ユーザ空間バッファの長さやアドレス、 I/O
OSDN Git Service
