Indan Zupancic wrote:
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.
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.
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?
Huh? It is not just the speed of the sync --- unnecessary writeback
will cause wear on your thumbdrive, eat up your laptop battery, and
kill I/O performance in other tasks running at the same time.
I'm afraid I don't understand what you're saying here at all. Would
you say that fsync is superfluous, too?
Jonathan
On Sat, March 12, 2011 03:10, Jonathan Nieder wrote:
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.
I'm in no position to decide about this code's fate anyway, I only voice
my opinion in the hope people won't make the mistake of adding this as a
new system call.
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.
Ioctl or sync_file_range, it's obscure enough for an ioctl I guess.
quoted
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?
Huh? It is not just the speed of the sync --- unnecessary writeback
will cause wear on your thumbdrive, eat up your laptop battery, and
kill I/O performance in other tasks running at the same time.
The writeback will happen sooner or later, so there is no unnecessary
writeback, except if you're overwriting/deleting just written data. If
you're worried about unnecessary writeback then don't do any synching.
You're actually arguing againt this feature and for fsync().
Syncfs won't be called frequently anyway, if it was then fsync could
be used instead. So it's pretty much a slightly better version of sync.
You could call it sync2() and add a path parameter. And after a few
years replace it with sync3 with a flag argument added. Then add a
sync4 with a sigmask too. That seems the new convention and would be
consistent...
I think all new system calls (or other highly visible ABI change) should
have half a year thinking time, and when they're in they're guaranteed to
be not stable for at least 2 years. If after that time they're still in,
they become stable and part of the official ABI. Removing something new
should be as easy as adding something new. But the current trend of easily
added, but hard to remove features is asking for long-term messiness. It
takes time for code to depend on a new feature, so removing bad new stuff
isn't as bad as removing oldstuff. Pity Linus didn't figure that out yet.
I'm afraid I don't understand what you're saying here at all. Would
you say that fsync is superfluous, too?
No, fsync actually makes sense.
Greetings,
Indan
On Fri, Mar 11, 2011 at 08:10:01PM -0600, Jonathan Nieder wrote:
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.
thanks,
greg k-h