linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: Peng Tao <tao.peng@primarydata.com>,
	linux-nfs@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2] nfs41: change PNFS_LAYOUTRET_ON_SETATTR to only return on truncation to smaller size
Date: Sun, 14 Sep 2014 18:43:28 +0200	[thread overview]
Message-ID: <20140914164328.GA13467@lst.de> (raw)
In-Reply-To: <541572BE.6000504@plexistor.com>

On Sun, Sep 14, 2014 at 01:49:34PM +0300, Boaz Harrosh wrote:
> This is in violation of the pnf-objects draft.

Ithought that's an RFC by now? :)

> We are obliged
> on chown to return layouts because of how the CAPs work, they
> have an embedded CAPs version which might increment when chown
> is changed, and also the credential keys. Which means that using
> the old layout will return an E_ACCESS from the OSD.

This is a good enough argument to just split the flags into one
for chown and one for truncate.  Can you confirm that any other
setattr but a truncate to a smaller size or chown is fine with
your interpretation of RFC5664?

> But..
> 
> I will agree with this patch. The above is true in an OSD
> protocol higher then NO_SEC. But none of the current implementation
> support anything other then NO_SEC.
> 
> Second also with none-NO_SEC once a client does a chown the server
> needs to RECALL all other clients, so as Peng says above the Server
> should/can also recall from us.
> 
> But some good sole needs to make an errata at the RFC draft so to
> explain.

I'd rather not violate the existing RFC unless we have a good reason for it
and an errata out.  Having a flag to return on chown for the object layout
seems like the easier way to go forward.

  reply	other threads:[~2014-09-14 16:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12  3:04 [PATCH v2] nfs41: change PNFS_LAYOUTRET_ON_SETATTR to only return on truncation to smaller size Peng Tao
2014-09-14 10:49 ` Boaz Harrosh
2014-09-14 16:43   ` Christoph Hellwig [this message]
2014-09-17 13:40     ` Benny Halevy

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=20140914164328.GA13467@lst.de \
    --to=hch@lst.de \
    --cc=boaz@plexistor.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tao.peng@primarydata.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).