cvs commit: src/sys/nfsclient nfs_bio.c nfs_vfsops.c nfsargs.h nfsmount.h src/sys/sys buf.h bufobj.h src/sys/kern vfs_bio.c

[Brian Fundakowski Feldman]

On Sat, Jun 11, 2005 at 07:10:21AM -0700, Alfred Perlstein wrote:
> * Brian Fundakowski Feldman <green at freebsd.org> [050610 23:49] wrote:
> > On Fri, Jun 10, 2005 at 08:49:30PM -0700, Alfred Perlstein wrote:
> > > Returning EAGAIN from a disk IO seems bogus, are you sure it makes
> > > sense to do that when IO_NDELAY is set?  Shouldn't it just be ignored
> > > like other FSes do?
> > 
> > Well, it's not disk IO, it's network IO.  I figure if you set that
> > flag you should expect commensurate error return values.  This is
> > conceivably a useful behavior, and POSIX does not forbid it, so I just
> > made the judgement call to not deny the functionality.
> > 
> > Would you actually be surprised to get EAGAIN if you requested
> > non-blocking access to a file stream, ignoring the fact that it just
> > happens to not have been done already for other S_ISREG file streams?
> 
> How does one poll(2) or kqueue(2) to determine when EAGAIN will
> "go away" ?  Maybe I'm misreading the code, but it appears that
> O_FSYNC writes on a non-blocking write will _always_ return
> EAGAIN?  So when is it safe to "AGAIN"? :)

Well, the easy solution is just fsync(2) :) This change jibes with
Terry's explanation (thanks, Juli).  It would be good to implement
the rest of the functionality for non-blocking NFS client, too, but I
think that can be dne gradually over time.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\