Messages in this thread | | | Date | Thu, 30 Mar 2006 00:11:09 -0800 | From | Andrew Morton <> | Subject | Re: [patch 1/1] sys_sync_file_range() |
| |
Neil Brown <neilb@suse.de> wrote: > > On Wednesday March 29, akpm@osdl.org wrote: > > > > From: Andrew Morton <akpm@osdl.org> > > > > Remove the recently-added LINUX_FADV_ASYNC_WRITE and LINUX_FADV_WRITE_WAIT > > fadvise() additions, do it in a new sys_sync_file_range() syscall > > instead. > > Hmmm... any chance this could be split into a sys_sync_file_range and > a vfs_sync_file_range which takes a 'struct file*' and does less (or > no) sanity checking, so I can call it from nfsd?
Coming right up. (Will switch it to fget_light() too)
> Currently I implement COMMIT (which has a range) with a by messing > around with filemap_fdatawrite and filemap_fdatawait (ignoring the > range) and I'd rather than a vfs helper. > > And in nfsd I call filp->f_op->fsync between the two. Doesn't > sys_sync_file_range need to call into the filesystem at all?
Interesting question. sync_file_range() is purely a pagecache (ie: file contents) operation. It doesn't touch metadata at all.
So if it's being used for data-integrity purposes then it really only makes sense when it's doing file overwrites.
It does call into the filesystem of course - a_ops.writepages() and perhaps a_ops.writepage().
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |