Re: [PATCH v3] introduce sys_syncfs to sync a single file system

[Indan Zupancic]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/