From: Boaz Harrosh <bharrosh@panasas.com>
To: "William A. (Andy) Adamson" <androsadamson@gmail.com>
Cc: bhalevy@panasas.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/16] pnfs-submit fix layout allocation and reference counting
Date: Mon, 12 Jul 2010 18:33:41 +0300 [thread overview]
Message-ID: <4C3B35D5.7050003@panasas.com> (raw)
In-Reply-To: <AANLkTim1mQiVIum5X4YPUYx3KYaN6WMiXhTL9Oyb-WDE@mail.gmail.com>
On 07/08/2010 07:14 PM, William A. (Andy) Adamson wrote:
> On Thu, Jul 8, 2010 at 6:16 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> On 07/08/2010 01:34 AM, andros@netapp.com wrote:
>>
>> Why don't we allocate this at inode allocation.
>
> We don't know if we need it at inode allocation. Remember, GFS2 only
> uses RO layouts.
right! optimize for a specific File System (broken at that).
I don't mind if you leave the current code placement and allocate
layout_type on first layout-request (first call to _pnfs_update_layout)
Then deallocate at inode destruction.
The few places that couple the destruction of all layout segments
and return them, with the layout_type structure deallocation should just
be de-coupled. Don't mix up between the allocation/deallocation of
layout_type and destruction of layout-segments.
> Plus, the protocol allows a file system to use more
> than one layout type and each layout type has a different private
> portion of the layout structure.
We don't support that, now, for other reasons. Lets not go there.
>
>
> Actually this is not true. pnfs_destroy_layout is not only called a
> inode destruction - it is also called in pnfs_reclaim_layout (state
> reclaim after reboot)
>
> In this case, the layout will be destroyed while the inode continues on.
>
You mean the layout-segments. But the layout_type can stay, why deallocate
it? it will be needed again.
> The use and implementation of pnfs_reclaim_layout needs a review.
>
> The question is, when should the nfs_inode->layout be freed when the
> inode is not? These are candidates.
> - reclaim state after server reboot (current code does this)
> - reclaim state after a network partition (current code does this)
> - file system migration
> - switching to a different file system replica
> - CB_LAYOUTRECALL FSID
> - CB_LAYOUTRECALL ALL
>
None of the above. These are all related to on-the-line layouts which
are layout-segments in our code. The governing structure is just an
inode-thing/per-layout-type.
If we follow my simple rules then you see that all these run-away pnfs
flags and states that where put back into nfsi can return to ->layout.
Boaz
prev parent reply other threads:[~2010-07-12 15:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 22:34 [PATCH 0/16] pnfs-submit fix layout allocation and reference counting andros
2010-07-07 22:34 ` [PATCH 01/16] SQUASHME pnfs-submit: add state flag for layoutcommit_needed andros
2010-07-07 22:34 ` [PATCH 02/16] SQUASHME: pnfs-submit: move pnfs_layout_suspend back to nfs_inode andros
2010-07-07 22:34 ` [PATCH 03/16] SQUASHME pnfs-submit embed pnfs_layout_type andros
2010-07-07 22:34 ` [PATCH 04/16] SQUASHME pnfs-submit: filelayout: use new alloc/free_layout API andros
2010-07-07 22:34 ` [PATCH 05/16] SQUASHME pnfs-submit: rewrite layout allocation andros
2010-07-07 22:34 ` [PATCH 06/16] SQUASHME pnfs-submit; fix pnfs_update_layout reference counting andros
2010-07-07 22:34 ` [PATCH 07/16] SQUASHME pnfs_submit: don't get a reference on boundary calculation andros
2010-07-07 22:34 ` [PATCH 08/16] SQUASHME pnfs-submit: don't reference the layout in init_lseg andros
2010-07-07 22:34 ` [PATCH 09/16] SQUASHME pnfs-submit: pnfs_update_layout always references the lseg andros
2010-07-07 22:34 ` [PATCH 10/16] SQUASHME pnfs-submit: reference the layout when inserted into segs list andros
2010-07-07 22:34 ` [PATCH 11/16] SQUASHME pnfs-submit: rename put_layout to put_layout_locked andros
2010-07-07 22:34 ` [PATCH 12/16] SQUASHME pnfs-submit: reference layout across layoutcommit andros
2010-07-07 22:34 ` [PATCH 13/16] SQUASHME pnfs-submit: reference layout for layoutreturn andros
2010-07-07 22:34 ` [PATCH 14/16] SQUASHME pnfs-submit: remove put_layout from pnfs_free_layout andros
2010-07-07 22:34 ` [PATCH 15/16] SQUASHME pnfs-submit: do not reference a layout in destroy_layout andros
2010-07-07 22:34 ` [PATCH 16/16] SQUASHME pnfs-submit: remove grab_current_layout andros
2010-07-12 17:19 ` [PATCH 12/16] SQUASHME pnfs-submit: reference layout across layoutcommit Benny Halevy
2010-07-12 18:27 ` William A. (Andy) Adamson
[not found] ` <AANLkTil1wUQUTht0QP7_Ttaagw0-LXef2J8wU6wSFUWG-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-12 18:29 ` Benny Halevy
2010-07-13 13:50 ` William A. (Andy) Adamson
2010-07-12 17:25 ` Boaz Harrosh
2010-07-12 18:09 ` William A. (Andy) Adamson
[not found] ` <AANLkTilWfV86wpO7vFho3FmL9y9Y6Sx9_-knKq7T-snu-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-12 18:27 ` Benny Halevy
2010-07-12 18:28 ` William A. (Andy) Adamson
[not found] ` <AANLkTilrcKirEQLe5mhtYNAnaJBSn6q4edC3TlXJd1rm-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-12 19:54 ` Benny Halevy
2010-07-12 9:13 ` [PATCH 09/16] SQUASHME pnfs-submit: pnfs_update_layout always references the lseg Benny Halevy
2010-07-12 8:30 ` [PATCH 05/16] SQUASHME pnfs-submit: rewrite layout allocation Benny Halevy
2010-07-13 13:39 ` William A. (Andy) Adamson
[not found] ` <AANLkTilb6ePL7s6H4TbhGfJt05Yw7Gc24V0C8cPHC22K-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-13 14:04 ` Benny Halevy
2010-07-12 16:32 ` [PATCH 04/16] SQUASHME pnfs-submit: filelayout: use new alloc/free_layout API Boaz Harrosh
2010-07-12 16:29 ` [PATCH 03/16] SQUASHME pnfs-submit embed pnfs_layout_type Boaz Harrosh
2010-07-12 17:05 ` Benny Halevy
2010-07-12 17:38 ` William A. (Andy) Adamson
2010-07-12 17:34 ` William A. (Andy) Adamson
[not found] ` <AANLkTikTMLQJwj1PeW2Y0dfmRcVFdNr6sasxJtaAiMg4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-12 17:43 ` Boaz Harrosh
2010-07-12 18:33 ` William A. (Andy) Adamson
2010-07-07 22:57 ` [PATCH 0/16] pnfs-submit fix layout allocation and reference counting Gilliam, PaulX J
2010-07-08 10:16 ` Boaz Harrosh
2010-07-08 16:14 ` William A. (Andy) Adamson
2010-07-12 15:33 ` Boaz Harrosh [this message]
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=4C3B35D5.7050003@panasas.com \
--to=bharrosh@panasas.com \
--cc=androsadamson@gmail.com \
--cc=bhalevy@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 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.