Re: NFSv4/pNFS possible POSIX I/O API standards

[Christoph Hellwig <hch@infradead.org>]

On Tue, Nov 28, 2006 at 05:54:28AM +0000, Christoph Hellwig wrote:
> What crack do you guys have been smoking?

I'd like to apologize for this statement, it was a little harsh.

I still think most of these APIs are rather braindead, but then again
everyone does braindead APIs from now to then.

I still think it's very futile that you try to force APIs using
standizations on us.  Instead of going down that route please try
to present a case for every single API you want, including reasonings
why this can't be fixed by speeding up existing APIs.  Note that with
us I don't mean just linux but also other OpenSource OSes.  Unless you
at least get Linux and FreeBSD and Solaris to agree on the need for
the API it's very pointless to go anywhere close to a standization body.

Anyway, let's go on to the individual API groups:

 - readdirplus

	This one is completely unneeded as a kernel API.  Doing readdir
	plus calls on the wire makes a lot of sense and we already do
	that for NFSv3+.  Doing this at the syscall layer just means
	kernel bloat - syscalls are very cheap.

 - lockg

	I'm more than unhappy to add new kernel-level file locking calls.
	The whole mess of lockf vs fcntl vs leases is bad enough that we
	don't want to add more to it.  Doing some form of advisory locks
	that can be implemented in userland using a shared memory region
	or message passing might be fine.

 - openg/sutoc

	No way.  We already have a very nice file descriptor abstraction.
	You can pass file descriptors over unix sockets just fine.

 - NFSV4acls

	These have nothing to do at all with I/O performance.  They're
	also sufficiently braindead.  Even if you still want to push for
	it you shouldn't mix it up with anything else in here.

 - statlite

	The concept generally makes sense.  The specified details are however
	very wrong.  Any statlite call should operate on the normal
	OS-specified stat structure and have the mask of flags as an
	additional argument.  Because of that you can only specific
	existing posix stat values as mandatory, but we should have an
	informal agreement that assigns unique mask values to extensions.
	This allows applications to easily fall back to stat on operating
	systems not supporting the flags variant, and also allows new
	operating systems to implement stat using the flags variant.
	While we're at it statlight is a really bad name for this API,
	following that *at APIs it should probably be {l,f,}statf.

 - O_LAZY

	This might make some sense.  I'd rather implement lazyio_synchronize
	and lazyio_propagate as additional arguments to posix_fadvise, though.

 - readx/writex

	Again, useless bloat.  Syscalls are cheap, and if you really want
	to submit multiple s/g I/Os at the same time and wait for all of
	them use the Posix AIO APIs or something like Linux's io_submit.