On Sat, March 12, 2011 03:10, Jonathan Nieder wrote: > 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. 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. > >> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
