-.\" 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-01-17 "Linux" "Linux Programmer's Manual"
+.TH SYNC_FILE_RANGE 2 2013-04-01 "Linux" "Linux Programmer's Manual"
.SH NAME
sync_file_range \- sync a file segment with disk
.SH SYNOPSIS
.nf
-.B #define _GNU_SOURCE
+.BR "#define _GNU_SOURCE" " /* See feature_test_macros(7) */"
.B #include <fcntl.h>
.BI "int sync_file_range(int " fd ", off64_t " offset ", off64_t " nbytes ,
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.
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 "SEE ALSO"
+.SH NOTES
+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 ()
+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
+.in +4n
+.nf
+.BI "int sync_file_range2(int " fd ", unsigned int " flags ,
+.BI " off64_t " offset ", off64_t " nbytes );
+.fi
+.in
+.PP
+The behavior of this system call is otherwise exactly the same as
+.BR sync_file_range ().
+
+A system call with this signature first appeared on the ARM architecture
+in Linux 2.6.20, with the name
+.BR arm_sync_file_range ().
+It was renamed in Linux 2.6.22,
+when the analogous system call was added for PowerPC.
+On architectures where glibc support is provided,
+glibc transparently wraps
+.BR sync_file_range2 ()
+under the name
+.BR sync_file_range ().
+.SH SEE ALSO
.BR fdatasync (2),
.BR fsync (2),
.BR msync (2),
-.BR sync (2),
-.BR feature_test_macros (7)
+.BR sync (2)
+.SH COLOPHON
+This page is part of release 3.65 of the Linux
+.I man-pages
+project.
+A description of the project,
+and information about reporting bugs,
+can be found at
+\%http://www.kernel.org/doc/man\-pages/.
OSDN Git Service
