From: Boaz Harrosh <bharrosh@panasas.com>
To: Benny Halevy <bhalevy@panasas.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v5 23/38] SQUASHME: pnfs-obj: use global device cache
Date: Mon, 23 May 2011 23:53:14 +0300 [thread overview]
Message-ID: <4DDAC93A.2020209@panasas.com> (raw)
In-Reply-To: <4DDA64C6.2080909@panasas.com>
On 05/23/2011 04:44 PM, Benny Halevy wrote:
> On 2011-05-23 07:52, Boaz Harrosh wrote:
>> On 05/23/2011 02:58 AM, Benny Halevy wrote:
>>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>>
>> Benny sorry but NACK on the global device cache for now
>>
>> This is to late at this stage. We have decided that first imp will
>> use the private cache and we'll postpone these cleanups for later.
>>
>> All other code was well tested for years, all this is new code, and
>
> The file layout is upstream and better be harnessed for other layout
> drivers as well. If it's inferior to the current objects layout cache
> we should fix and improve the former rather than introducing a new
> implementation.
>
>> new behaviour that we will not have time to test. I do not like the
>
> Ideally, the should already be fully tested, but last minute review-
> related changes will always require further testing that needs to be
> taken place during the -rc cycle. The whole point of having rc's is
> to stabilize the merged code to a point it can be released as a stable
> release.
>
>> code as it is. Because currently it will release the device on layout_return.
>> Where is the cache? There is much more work to do here!
>>
>
> Like I said, if there are bugs we should fix them rather introducing
> alternative code that does the same thing.
>
>> We already said not to do this in this merge why the change of heart?
>
> We discussed that again on Thursday's conference call which you did not
> attend. I decided to take a stab at it to see how a unified cache would
> look like and I rather like the outcome..
>
> Benny
>
As I suspected this is crashing all over the place. Finally I was able
to rebase a server on your latest code. (And find out what I was missing).
I'm fighting with it for two hours now. And I don't see the end of it.
Again I'm not at all against this work. I have my own version of this
in my tree. Only against the timing. Your latest code cannot go in now.
It is to new!
What do you want to do now? Postpone pnfs-objects to next Kernel. Or put
in good solid code that was tested and worked for a long time.
I'm not sleeping nights, have worked all through both weekends. Now it is
for nothing. Thanks alot!
Boaz
next prev parent reply other threads:[~2011-05-23 20:53 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-22 23:43 [PATCHSET v5 0/38] pnfs for 2.6.40 Benny Halevy
2011-05-22 23:45 ` [PATCH v5 01/38] NFSv4.1: use struct nfs_client to qualify deviceid Benny Halevy
2011-05-22 23:45 ` [PATCH v5 02/38] pnfs: resolve header dependency in pnfs.h Benny Halevy
2011-05-22 23:45 ` [PATCH v5 03/38] NFSv4.1: make deviceid cache global Benny Halevy
2011-05-22 23:46 ` [PATCH v5 04/38] NFSv4.1: purge deviceid cache on nfs_free_client Benny Halevy
2011-05-22 23:46 ` [PATCH v5 05/38] pnfs: CB_NOTIFY_DEVICEID Benny Halevy
2011-05-22 23:46 ` [PATCH v5 06/38] SQUASHME: use be32 res in nfs4_callback_devicenotify Benny Halevy
2011-05-22 23:47 ` [PATCH v5 07/38] SQUASHME: pnfs: use nfs_client to qualify deviceid for cb_notify_deviceid Benny Halevy
2011-05-22 23:47 ` [PATCH v5 08/38] SQUASHME: pnfs: use global deviceid cache for CB_NOTIFY_DEVICEID Benny Halevy
2011-05-22 23:48 ` [PATCH v5 09/38] SQUASHME: pnfs: refactor device cache _lookup_deviceid Benny Halevy
2011-05-22 23:49 ` [PATCH v5 10/38] SQUASHME: pnfs: refactor device cache _find_get_deviceid Benny Halevy
2011-05-22 23:50 ` [PATCH v5 11/38] SUNRPC: introduce xdr_init_decode_pages Benny Halevy
2011-05-22 23:51 ` [PATCH v5 12/38] pnfs: Use byte-range for layoutget Benny Halevy
2011-05-22 23:51 ` [PATCH v5 13/38] pnfs: align layoutget requests on page boundaries Benny Halevy
2011-05-22 23:52 ` [PATCH v5 14/38] pnfs: Use byte-range for cb_layoutrecall Benny Halevy
2011-05-22 23:53 ` [PATCH v5 15/38] pnfs: client stats Benny Halevy
2011-05-22 23:54 ` [PATCH v5 16/38] pnfs-obj: objlayoutdriver module skeleton Benny Halevy
2011-05-22 23:55 ` [PATCH v5 17/38] pnfs-obj: pnfs_osd XDR definitions Benny Halevy
2011-05-22 23:56 ` [PATCH v5 18/38] pnfs-obj: pnfs_osd XDR client implementation Benny Halevy
2011-05-22 23:57 ` [PATCH v5 19/38] pnfs-obj: decode layout, alloc/free lseg Benny Halevy
2011-05-22 23:57 ` [PATCH v5 20/38] pnfs: per mount layout driver private data Benny Halevy
2011-05-23 4:38 ` Boaz Harrosh
2011-05-23 13:36 ` Benny Halevy
2011-05-22 23:57 ` [PATCH v5 21/38] pnfs-obj: objio_osd device information retrieval and caching Benny Halevy
2011-05-22 23:58 ` [PATCH v5 22/38] pnfs: set/unset layoutdriver Benny Halevy
2011-05-22 23:58 ` [PATCH v5 23/38] SQUASHME: pnfs-obj: use global device cache Benny Halevy
2011-05-23 4:52 ` Boaz Harrosh
2011-05-23 13:44 ` Benny Halevy
2011-05-23 20:53 ` Boaz Harrosh [this message]
2011-05-23 21:59 ` [PATCH] SQUASHME: Bugs in new global-device-cache code Boaz Harrosh
2011-05-23 22:31 ` Boaz Harrosh
2011-05-22 23:59 ` [PATCH v5 24/38] SQUASHME: Revert "pnfs: per mount layout driver private data" Benny Halevy
2011-05-22 23:59 ` [PATCH v5 25/38] SQUASHME: Revert "pnfs: set/unset layoutdriver" Benny Halevy
2011-05-22 23:59 ` [PATCH v5 26/38] NFSv4.1: use layout driver in global device cache Benny Halevy
2011-05-23 0:00 ` [PATCH v5 27/38] pnfs: alloc and free layout_hdr layoutdriver methods Benny Halevy
2011-05-23 0:00 ` [PATCH v5 28/38] pnfs-obj: define per-inode private structure Benny Halevy
2011-05-23 0:00 ` [PATCH v5 29/38] pnfs: support for non-rpc layout drivers Benny Halevy
2011-05-23 0:01 ` [PATCH v5 30/38] SQUASHME: initialize data->task on the non-rpc io done success paths Benny Halevy
2011-05-23 4:58 ` Boaz Harrosh
2011-05-23 13:47 ` Benny Halevy
2011-05-23 0:01 ` [PATCH v5 31/38] pnfs-obj: osd raid engine read/write implementation Benny Halevy
2011-05-23 10:44 ` [PTACH] SQUASHME: pnfs-obj: Important fallout from the last rebase Boaz Harrosh
2011-05-23 13:53 ` Benny Halevy
2011-05-23 0:01 ` [PATCH v5 32/38] pnfs: layoutreturn Benny Halevy
2011-05-23 0:02 ` [PATCH v5 33/38] SQUASHME: pnfs: fix layout stateid in layoutreturn args Benny Halevy
2011-05-23 0:02 ` [PATCH v5 34/38] pnfs: layoutret_on_setattr Benny Halevy
2011-05-23 0:02 ` [PATCH v5 35/38] pnfs: encode_layoutreturn Benny Halevy
2011-05-23 0:02 ` [PATCH v5 36/38] pnfs-obj: report errors and .encode_layoutreturn Implementation Benny Halevy
2011-05-23 0:03 ` [PATCH v5 37/38] pnfs: encode_layoutcommit Benny Halevy
2011-05-23 0:03 ` [PATCH v5 38/38] pnfs-obj: objlayout_encode_layoutcommit implementation Benny Halevy
2011-05-23 0:22 ` [PATCHSET v5 0/38] pnfs for 2.6.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=4DDAC93A.2020209@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.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.