On Fri, March 11, 2011 12:55, Arnd Bergmann wrote:
On Friday 11 March 2011, Indan Zupancic wrote:
quoted
quoted
http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2
The patch there seems much more reasonable than introducing a whole
new systemcall just for 20 lines of kernel code. New system calls are
added too easily nowadays.
The only problem with adding new system calls is that we are stuck
with the interface until the end of time, so we must be sure not
to get it wrong. The same thing is true for any other interface
such as ioctl or extensions to existing system calls. People usually
get away with adding new ioctls more easily because it is less
obvious when they are added.
Agreed.
I'm not sure this feature is important enough to add. I can't really
think of a regular use case where this would be useful, generally
it's transparent on which mount files are. Add symlinks, and you
give users a lot of rope. Any user has to make sure that all the
files they want to sync are on the same file system.
About the arguments against 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., /).
It would be better to fix NFS, or mount it with the fsc option (assuming
a sync will write to the local cache instead of hanging forever then).
- 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.
You can use sync_file_range() on those files to schedule the writes
and then do the fsync(2) as usual (both on files and dirs).
If there still is a good reason to implement this, please don't add it
as a new system call, but add it to sync_file_range(), as that seems
the best place for odd file synchronisation operations.
Greetings,
Indan
Indan Zupancic wrote:
If there still is a good reason to implement this, please don't add it
as a new system call, but add it to sync_file_range(), as that seems
the best place for odd file synchronisation operations.
I have no strong preference about how this is added (and in fact I'm
quite ignorant about the usual conventions), but:
- as a sysadmin, it really _would_ be nice to be able to say
"sync /usr" to sync /usr;
- the existing functionality of sync_file_range is about controlling
writeback behavior for files, not mounts.
So unless there is a shortage of syscall numbers or something, I find
the request to omit this or tack it onto sync_file_range odd. Could
you explain the benefit?
Thanks,
Jonathan
On 03/11/2011 06:45 PM, Indan Zupancic wrote:
On Fri, March 11, 2011 12:55, Arnd Bergmann wrote:
quoted
On Friday 11 March 2011, Indan Zupancic wrote:
quoted
quoted
http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2
The patch there seems much more reasonable than introducing a whole
new systemcall just for 20 lines of kernel code. New system calls are
added too easily nowadays.
The only problem with adding new system calls is that we are stuck
with the interface until the end of time, so we must be sure not
to get it wrong. The same thing is true for any other interface
such as ioctl or extensions to existing system calls. People usually
get away with adding new ioctls more easily because it is less
obvious when they are added.
Agreed.
I'm not sure this feature is important enough to add. I can't really
think of a regular use case where this would be useful, generally
it's transparent on which mount files are. Add symlinks, and you
give users a lot of rope. Any user has to make sure that all the
files they want to sync are on the same file system.
About the arguments against sync(2):
quoted
- 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., /).
It would be better to fix NFS, or mount it with the fsc option (assuming
a sync will write to the local cache instead of hanging forever then).
quoted
- 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.
You can use sync_file_range() on those files to schedule the writes
and then do the fsync(2) as usual (both on files and dirs).
If there still is a good reason to implement this, please don't add it
as a new system call, but add it to sync_file_range(), as that seems
the best place for odd file synchronisation operations.
Greetings,
Indan
--
Hi Indan,
I think that you missed the point of the extension.
Ric
On Sat, March 12, 2011 00:56, Jonathan Nieder wrote:
Indan Zupancic wrote:
quoted
If there still is a good reason to implement this, please don't add it
as a new system call, but add it to sync_file_range(), as that seems
the best place for odd file synchronisation operations.
I have no strong preference about how this is added (and in fact I'm
quite ignorant about the usual conventions), but:
I'm not pushing for any official convention, just what seems good taste.
- as a sysadmin, it really _would_ be nice to be able to say
"sync /usr" to sync /usr;
This is independent of the implementation.
- the existing functionality of sync_file_range is about controlling
writeback behavior for files, not mounts.
True, but what happens when you sync a mount? In the end it's about odd,
non-standard syncing behaviour, so I think it fits sync_file_range well.
Like sync_file_range, it's trickier to use than it seems at first, so it
fits well with the other "keep this in mind before using it" requirements.
So unless there is a shortage of syscall numbers or something, I find
the request to omit this or tack it onto sync_file_range odd. Could
you explain the benefit?
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). The code ends
up near the code it calls, so it makes contextual sense.
As for the reason not to add it at all, well, if everything that seemed
a good idea at the time was added as a system call it would be an even
bigger mess than it already is. So it doesn't have to be a bad idea to
not make it, not being useful enough is sufficient.
In this case it's just a performance improvement over sync(2). It doesn't
add a new feature. Main argument given for the performance problem seems
to be "NFS can be slow". Anything else?
Greetings,
Indan