linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: David Chinner <dgc@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	gnb@sgi.com, xfs-oss <xfs@oss.sgi.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: review: don't block non-blocking writes when frozen
Date: Tue, 24 Apr 2007 15:55:25 +0100	[thread overview]
Message-ID: <20070424145525.GA18918@infradead.org> (raw)
In-Reply-To: <20070423231337.GN32602149@melbourne.sgi.com>

On Tue, Apr 24, 2007 at 09:13:37AM +1000, David Chinner wrote:
> So, given the catch-22 you've just presented us can we revisit the
> nfsd non-blocking I/O issue again?  This affects anyone using DM
> snapshots on their NFS servers and has nothing to do with HSMs
> or DMAPI...
> 
> FWIW, you can still do non-blocking userspace I/O to a file, so this
> XFS patch is still valid for mainline (that's how I tested it).

I've been investigating the situation a little bit more, and here's
what's going on:

 - SuS allows for O_NONBLOCK on regular files as per
   http://www.opengroup.org/onlinepubs/007908799/xsh/write.html
 - actually implementing O_NONBLOCK semantics for regular fixes
   breaks userspace when poll/select claims files are ready to
   read/write but they aren't, see http://lkml.org/lkml/2004/10/17/17

So we can't really expose O_NONBLOCK on regular files to userspace,
and we need to make sure in common code this does not happen.

EJUKEBOX on snaphots does make sense, though.  Can you please send
a full patchseries for nfsd, the common code and the xfs writepath
so that this actually gets used and behaviour is consistant for all
(or at least most) filesystems?

Also now that the patch goes to mainline please kill ugly FILP_DELAY_FLAG
and just check the flags directly.  And it should probably only check
O_NONBLOCK.  The only architecture having O_NDELAY different from
O_NONBLOCK is sparc, and it already translates the value for us.




           reply	other threads:[~2007-04-24 14:55 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20070423231337.GN32602149@melbourne.sgi.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070424145525.GA18918@infradead.org \
    --to=hch@infradead.org \
    --cc=dgc@sgi.com \
    --cc=gnb@sgi.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).