From: Benny Halevy <benny@tonian.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: NFS list <linux-nfs@vger.kernel.org>
Subject: Re: Final disposition of the pNFSD tree
Date: Wed, 26 Oct 2011 07:25:16 +0200 [thread overview]
Message-ID: <4EA799BC.5050805@tonian.com> (raw)
In-Reply-To: <4EA77E00.6090002@panasas.com>
On 2011-10-26 05:26, Boaz Harrosh wrote:
> Benny what is the state of the PNFSD tree? Can you sign on it's stability for
> a large scale testing or should I be using the nfsd-3.1 based tree?
>
Right now there is use after free of the layout stateid that I'm working on
for which I'd like to have a fix ASAP, before the end of the week
that is due to the latest work done on top of bfields' for-3.2 patch set
that I merged-in.
> As far as I could see. The last tree that did not have nfsd-3.2
> new state patches was pnfs-all-3.1-rc8-2011-10-06.
>
> pnfs-all-3.1-rc9-2011-10-17 Had some of them, but I guess not the major
> ones. (Should I test with this one?)
Correct. This version should be fine as it doesn't contain the stuff
I mentioned above. (looking at alloc_init_layout_state() tells)
>
> And pnfs-all-3.1-rc10-2011-10-18 (pnfs/pnfs-all-latest) has all of them.
> Is it stable?
Nope, I sent it out during the Bakeathon hoping I'd be able to stabilize it
on the spot but failed to do so.
>
> My last heavy testing was actually on pnfs-all-3.1-rc6-2011-09-20. If I diff
> that with pnfs-all-3.1-rc8-2011-10-06 on fs/nfsd/ I can still see huge amount
> of for-nfsd-v3.2 changes. I know you have found some bugs, So I guess I'll stick
> with the v3.1-rc6-pnfs based tree for the Server and v3.1 release Kernel + ore-v3.2
> patches.
Sounds like a valid plan, though I always appreciate testing of the latest code
where possible. So if your testing with the older version goes fine and you still
have some spare cycles to test the latest stable one it would be awesome.
>
> Do you think you will release a 3.1 based pnfs tree that is completely based on
> the v3.1-nfsd version and the old pnfs tree, without any for-v3.2-pnfsd patches?
No, I'll stabilize it as it is. It seems scary because of the use-after-free bug trashes
memory and causes havoc but it ain't so bad...
Benny
>
> Thanks
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-10-26 5:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 3:26 Final disposition of the pNFSD tree Boaz Harrosh
2011-10-26 5:25 ` Benny Halevy [this message]
2011-10-31 17:12 ` 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=4EA799BC.5050805@tonian.com \
--to=benny@tonian.com \
--cc=bharrosh@panasas.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 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).