Bug 691267
| Summary: | [RFE] kernel: add new syncfs syscall | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Harshula Jayasuriya <harshula> | |
| Component: | kernel | Assignee: | Red Hat Kernel Manager <kernel-mgr> | |
| Status: | CLOSED ERRATA | QA Contact: | Red Hat Kernel QE team <kernel-qe> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 6.0 | CC: | eguan, esandeen, lczerner, rwheeler | |
| Target Milestone: | rc | Keywords: | FutureFeature | |
| Target Release: | 6.2 | |||
| Hardware: | Unspecified | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | kernel-2.6.32-180.el6 | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 691474 (view as bug list) | Environment: | ||
| Last Closed: | 2011-12-06 12:46:47 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 691474 | |||
Upstream discussion: http://thread.gmane.org/gmane.linux.file-systems/51497/ Hm, seems upstream doesn't have it wired up on PPC? $ grep -lR __NR_syncfs arch/* arch/blackfin/include/asm/unistd.h arch/ia64/include/asm/unistd.h arch/mips/include/asm/unistd.h arch/s390/include/asm/unistd.h arch/sh/include/asm/unistd_32.h arch/sh/include/asm/unistd_64.h arch/x86/include/asm/unistd_32.h arch/x86/include/asm/unistd_64.h A patch for m68k just got sent on the 23rd. Anyway, not a big deal to wire it up for ppc; and we don't usually patch arches we don't build in any case. Sent to rhkernel-list. I have backported following upstream patches and tested on x86_64, i686, s390, ppc64.
b7ed78f56575074f29ec99d8984f347f6c99c914
introduce sys_syncfs to sync a single file system
c7a1fcd8e6e0c3c8f4f8f74fc926ff04da3bf7a7
include/asm-generic/unistd.h: fix syncfs syscall numbe
d0d2e31af691ed3dbb4e556bf939b86ef745e6a3
[S390] wire up sys_syncfs
834796a8493809ae6667b65c4c044066f41d32c7
powerpc: Wire up new syscalls
Thanks!
-Lukas
Patch(es) available on kernel-2.6.32-180.el6 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2011-1530.html |
------------------------------------------------------------ commit b7ed78f56575074f29ec99d8984f347f6c99c914 Author: Sage Weil <sage> Date: Thu Mar 10 11:31:30 2011 -0800 introduce sys_syncfs to sync a single file system It is frequently useful to sync a single file system, instead of all mounted file systems via sync(2): - On machines with many mounts, it is not at all uncommon for some of them to hang (e.g. unresponsive NFS server). sync(2) will get stuck on those and may never get to the one you do care about (e.g., /). - Some applications write lots of data to the file system and then want to make sure it is flushed to disk. Calling fsync(2) on each file introduces unnecessary ordering constraints that result in a large amount of sub-optimal writeback/flush/commit behavior by the file system. There are currently two ways (that I know of) to sync a single super_block: - BLKFLSBUF ioctl on the block device: That also invalidates the bdev mapping, which isn't usually desirable, and doesn't work for non-block file systems. - 'mount -o remount,rw' will call sync_filesystem as an artifact of the current implemention. Relying on this little-known side effect for something like data safety sounds foolish. Both of these approaches require root privileges, which some applications do not have (nor should they need?) given that sync(2) is an unprivileged operation. This patch introduces a new system call syncfs(2) that takes an fd and syncs only the file system it references. Maybe someday we can $ sync /some/path and not get sync: ignoring all arguments The syscall is motivated by comments by Al and Christoph at the last LSF. syncfs(2) seems like an appropriate name given statfs(2). A similar ioctl was also proposed a while back, see http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2 Signed-off-by: Sage Weil <sage> Signed-off-by: Al Viro <viro.org.uk> commit c7a1fcd8e6e0c3c8f4f8f74fc926ff04da3bf7a7 Author: Andrew Morton <akpm> Date: Tue Mar 22 16:30:07 2011 -0700 include/asm-generic/unistd.h: fix syncfs syscall number syncfs() is duplicating name_to_handle_at() due to a merging mistake. Cc: Sage Weil <sage> Cc: Al Viro <viro.org.uk> Signed-off-by: Andrew Morton <akpm> Signed-off-by: Linus Torvalds <torvalds> ------------------------------------------------------------ Architecture specific commits: ------------------------------------------------------------ commit 1bbf28756149a0aa0e3c8a74cea9bbe715639027 Author: Ralf Baechle <ralf> Date: Fri Mar 25 18:45:20 2011 +0100 MIPS: Wire up syncfs(2). Signed-off-by: Ralf Baechle <ralf> commit d0d2e31af691ed3dbb4e556bf939b86ef745e6a3 Author: Heiko Carstens <heiko.carstens.com> Date: Wed Mar 23 10:15:58 2011 +0100 [S390] wire up sys_syncfs Signed-off-by: Heiko Carstens <heiko.carstens.com> Signed-off-by: Martin Schwidefsky <schwidefsky.com> commit 4e3d96deff59d126cfa289645e136e295e65480f Author: Mike Frysinger <vapier> Date: Tue Mar 22 13:41:22 2011 -0400 Blackfin: wire up new syncfs syscall Signed-off-by: Mike Frysinger <vapier> commit 9298168d16faf939141cddc836b6b9b1ef2a8aac Author: Tony Luck <tony.luck> Date: Tue Mar 22 10:54:24 2011 -0700 [IA64] New syscalls for 2.6.39 Four new syscalls: sys_name_to_handle_at sys_open_by_handle_at sys_clock_adjtime sys_syncfs Signed-off-by: Tony Luck <tony.luck> commit 2a03cfbd906dc9bbf5e9a97727cf4ba1889d4829 Author: Paul Mundt <lethal> Date: Tue Mar 22 21:56:08 2011 +0900 sh: wire up sys_syncfs. Signed-off-by: Paul Mundt <lethal> ------------------------------------------------------------