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.
next prev parent 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).