OSDN Git Service

Update README
[linuxjm/LDP_man-pages.git] / original / man2 / sync_file_range.2
index 5c17812..8a24c87 100644 (file)
@@ -1,8 +1,7 @@
-.\" Hey Emacs! This file is -*- nroff -*- source.
-.\"
 .\" Copyright (c) 2006 Andrew Morton <akpm@osdl.org>
 .\" and Copyright 2006 Michael Kerrisk <mtk.manpages@gmail.com>
 .\"
+.\" %%%LICENSE_START(VERBATIM)
 .\" Permission is granted to make and distribute verbatim copies of this
 .\" manual provided the copyright notice and this permission notice are
 .\" preserved on all copies.
 .\"
 .\" Formatted or processed versions of this manual, if unaccompanied by
 .\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
 .\"
 .\" 2006-07-05 Initial creation, Michael Kerrisk based on
 .\"     Andrew Morton's comments in fs/sync.c
 .\" 2010-10-09, mtk, Document sync_file_range2()
 .\"
-.TH SYNC_FILE_RANGE 2 2010-10-09 "Linux" "Linux Programmer's Manual"
+.TH SYNC_FILE_RANGE 2 2014-08-19 "Linux" "Linux Programmer's Manual"
 .SH NAME
 sync_file_range \- sync a file segment with disk
 .SH SYNOPSIS
@@ -89,11 +89,11 @@ Therefore, unless the application is strictly performing overwrites of
 already-instantiated disk blocks, there are no guarantees that the data will
 be available after a crash.
 There is no user interface to know if a write is purely an overwrite.
-On file systems using copy-on-write semantics (e.g.,
+On filesystems using copy-on-write semantics (e.g.,
 .IR btrfs )
 an overwrite of existing allocated blocks is impossible.
 When writing into preallocated space,
-many file systems also require calls into the block
+many filesystems also require calls into the block
 allocator, which this system call does not sync out to disk.
 This system call does not flush disk write caches and thus does not provide
 any data integrity on systems with volatile disk write caches.
@@ -172,25 +172,30 @@ Out of disk space.
 refers to something other than a regular file, a block device,
 a directory, or a symbolic link.
 .\" FIXME . (bug?) Actually, how can 'fd' refer to a symbolic link (S_ISLNK)?
-.\" (In userspace at least) it isn't possible to obtain a file descriptor
+.\" (In user space at least) it isn't possible to obtain a file descriptor
 .\" for a symbolic link.
 .SH VERSIONS
 .BR sync_file_range ()
 appeared on Linux in kernel 2.6.17.
-.SH "CONFORMING TO"
+.SH CONFORMING TO
 This system call is Linux-specific, and should be avoided
 in portable programs.
 .SH NOTES
+.SS sync_file_range2()
 Some architectures (e.g., PowerPC, ARM)
 need 64-bit arguments to be aligned in a suitable pair of registers.
 .\" See kernel commit edd5cd4a9424f22b0fa08bef5e299d41befd5622
 On such architectures, the call signature of
 .BR sync_file_range ()
-is flawed, since it forces a register to be wasted as padding between the
+shown in the SYNOPSIS would force
+a register to be wasted as padding between the
 .I fd
 and
 .I offset
 arguments.
+(See
+.BR syscall (2)
+for details.)
 Therefore, these architectures define a different
 system call that orders the arguments suitably:
 .PP
@@ -214,8 +219,17 @@ glibc transparently wraps
 .BR sync_file_range2 ()
 under the name
 .BR sync_file_range ().
-.SH "SEE ALSO"
+.SH SEE ALSO
 .BR fdatasync (2),
 .BR fsync (2),
 .BR msync (2),
 .BR sync (2)
+.SH COLOPHON
+This page is part of release 3.79 of the Linux
+.I man-pages
+project.
+A description of the project,
+information about reporting bugs,
+and the latest version of this page,
+can be found at
+\%http://www.kernel.org/doc/man\-pages/.