On Mon, 14 Mar 2011 02:56:52 +0100 (CET)
"Indan Zupancic" [off-list ref] wrote:
On Sat, March 12, 2011 18:32, Greg KH wrote:
quoted
On Fri, Mar 11, 2011 at 08:10:01PM -0600, Jonathan Nieder wrote:
quoted
Indan Zupancic wrote:
quoted
I'm not pushing for any official convention, just what seems good taste.
In cases like this, conventions (consistency and best practices) are
very important.
quoted
Less code added, less bloat. Architecture independent, no need to update
all system call tables everywhere (all archs, libc versions and strace).
Two files changed, instead of 7 (which only hooks up x86).
Thanks for explaining. Those do seem like good reasons to use a ioctl
instead of a new syscall.
No, make it a syscall, it's more obvious and will be documented much
better.
There is no such guarantee. Everyone seems to want to add this new syncfs,
but it's not even defined what it does. "Same as sync, but only on one fs"
is IMHO not good enough, because sync's behaviour is pretty badly documented,
and that's a system call. The sync_file_range argument effects are quite
well defined, on the other hand, unlike sync behaviour. You're right for
ioctls though.
I think the semantics of sync are easily enough defined, even if
they're not well-defined in the documentation: all data which was dirty
at the time sync() was called will be written back and accessible when
the sync() returns.
I do agree that this should be a standalone syscall, not grafted into
sync_file_range() or into an ioctl.
That being said, we have two similar-looking-but-quite-different "sync"
concepts in the kernel. One is "sync for data integrity" and the other
is "sync to reduce the dirty memory load". The latter is not a data
integrity thing - it is a resource management thing.
There might one day be a requirement to be able to initiate a
resource-management-style writeback against a whole filesystem. When
that happens, we'll regret not having added a "mode" argument to
sys_syncfs().
Or maybe not - given that we're syncing the entire fs and that
sync_filesystem() does the two-pass "write for data cleaning then write
for data integrity" thing, it could be that a syncfs-for-data-cleaning
operation has little performance benefit over a
syncfs-for-data-integrity operation.