All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Benny Halevy <bhalevy@tonian.com>
Cc: NFS list <linux-nfs@vger.kernel.org>
Subject: Re: Does our Kernel PNFSD-Server supports recurring layout_get with open_state_id
Date: Tue, 29 May 2012 10:13:40 +0300	[thread overview]
Message-ID: <4FC47724.5070407@panasas.com> (raw)
In-Reply-To: <4FC3C3F1.8090507@tonian.com>

On 05/28/2012 09:29 PM, Benny Halevy wrote:

> On 2012-05-28 21:09, Boaz Harrosh wrote:


>> BTW after I finish implementing my stuff. I think it would be easy
>> to implement that open_state_id thing. All we need is to save the
>> open_state_id somewhere per-file or somehow identify it's receive,
>> And then just call nfs4_roc() which will do the proper work.
> 
> It's any non layout stateid so it should be pretty easy (in theory :).
> See nfs4_process_layout_stateid()
> if (stid->sc_type != NFS4_LAYOUT_STID) {}
> 
> We should be able to locate the layout stateid, if any, on the
> fp->fi_layout_states list by matching stid->sc_client.
> 


Does look easy, then. I thought it should be. I will have a shot
at it and add it to my patchset.

Do you know if we have a test case for this in pyNFS?

I need to think if we can cause this with the Linux client?
Perhaps: not set ROC, access a file and close, clear caches
at both ends, re access, something like that, I'll try.

Thanks
Boaz


  reply	other threads:[~2012-05-29  7:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-24  0:16 Does our Kernel PNFSD-Server supports recurring layout_get with open_state_id Boaz Harrosh
2012-05-24 12:41 ` Benny Halevy
2012-05-24 13:49   ` Boaz Harrosh
2012-05-24 13:50     ` Boaz Harrosh
2012-05-28 16:05     ` Benny Halevy
2012-05-28 16:09       ` [PATCH 1/5] pnfsd: make return_on_close state layout-global for the file/client Benny Halevy
2012-05-28 16:38         ` Boaz Harrosh
2012-05-28 16:09       ` [PATCH 2/5] SQUASHME: pnfsd: use LR_FLAG_INTERN for pnfsd_roc implicit layout return Benny Halevy
2012-05-28 16:09       ` [PATCH 3/5] pnfsd: add debug printouts to pnfsd_roc Benny Halevy
2012-05-28 16:53         ` Boaz Harrosh
2012-05-28 17:59           ` Benny Halevy
2012-05-28 16:09       ` [PATCH 4/5] pnfsd-lexp: return_on_close config option Benny Halevy
2012-05-28 16:52         ` Boaz Harrosh
2012-05-28 17:58           ` Benny Halevy
2012-05-28 18:01             ` Benny Halevy
2012-05-28 18:08               ` Benny Halevy
2012-05-28 18:05             ` Boaz Harrosh
2012-05-28 16:09       ` [PATCH 5/5] SQUASHME: pnfsd: lrs_present is false by default Benny Halevy
2012-05-28 16:36       ` Does our Kernel PNFSD-Server supports recurring layout_get with open_state_id Boaz Harrosh
2012-05-28 17:55         ` Benny Halevy
2012-05-28 18:09           ` Boaz Harrosh
2012-05-28 18:29             ` Benny Halevy
2012-05-29  7:13               ` Boaz Harrosh [this message]
2012-05-31  6:35                 ` 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=4FC47724.5070407@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=bhalevy@tonian.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.