On Thu, 3 Mar 2011 01:22:24 -0600, Jonathan Nieder [off-list ref] wrote:
Hi,
Sage Weil wrote:
quoted
- On machines with many of 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., /).
Fun to see this again.
quoted
- Some applications (Ceph, dpkg) 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.
This would be useful for 9p server in qemu
http://article.gmane.org/gmane.comp.emulators.qemu/95497
FWIW dpkg uses sync_file_range(2) and only syncs the files it needs to
nowadays. Other apps in the same position should probably do the
same.[1][2]
quoted
This patch introduces a new system call syncat(2) that mimics the existing
*at() interfaces by taking an fd and/or path. The fd can be either an
open file descriptor or AT_FDCWD, and the pathname can be either a path or
(unlike the usual *at() style interface) NULL. Only the file system for
the referenced file is synced.
Sounds like overengineering. The openat(2) family of calls are meant
to add flexibility to familiar calls that perform an operation with a
path relative to the cwd. To maintain familiarity, they include some
complication (AT_FDCWD, taking a relative path, and so on).
With some of the proposed changes for VFS [1] some of the *at calls also allows to
specify "" names. So i guess having syncat is useful because now we can
call sync with either an fd or with a name.
ie
syncat(fd, "");
or
syncat(AT_FDCWD, "a");
[1] http://article.gmane.org/gmane.linux.file-systems/50773
Since sync_one_filesystem(2) is new, why not just take a file or
directory fd (and perhaps flags for future expansion)? I can use
open(".", O_NONBLOCK) to get a file descriptor for the cwd.
quoted
Is this a reasonable approach? (Patch below is compile tested only. :)
Sounds reasonably sane.
As for the patch: without the pathname arg it becomes much simpler.
To my inexpert eyes, aside from that it looks good.
-aneesh