From: Boaz Harrosh <bharrosh@panasas.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Benny Halevy <bhalevy@panasas.com>,
Fred Isaman <iisaman@netapp.com>,
Weston Andros Adamson <dros@netapp.com>,
trond@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFS: filelayout should use nfs_generic_pg_test
Date: Wed, 01 Jun 2011 22:29:55 +0300 [thread overview]
Message-ID: <4DE69333.4020302@panasas.com> (raw)
In-Reply-To: <1306955827.3873.60.camel@lade.trondhjem.org>
On 06/01/2011 10:17 PM, Trond Myklebust wrote:
> On Wed, 2011-06-01 at 21:56 +0300, Benny Halevy wrote:
>
>> For pnfs, we need to ignore wsize, meaning we first need to try
>> to coalesce the pages and then decide if we're going the nfs_flush_multi
>> or the nfs_flush_one way, based on the coalesced length.
>
> No! Ignoring the wsize is definitely wrong... If the stripe size is
> larger than the 'maxwrite' recommended attribute, then the DS is allowed
> to do a short write, in which case we have to resend.
>
As far as I could understand the current code, desc->bsize which derives
from wsize/rsize is negotiated with the MDS. But the wsize in question
is the DS's one. So I think in pnfs it is only the layout-driver that
can check this properly against the filer in question. Only if IO is
to go through MDS the bsize check is relevant.
BTW: The BUG_ON() Andy hit, does not look like an hard bug to fix ;-)
> In any case, nfs_flush_multi and nfs_flush_one need a rewrite in order
> to deal properly with O_DIRECT writes, and so I'm expecting to get rid
> of the single nfs_page limit for the r/wsize<PAGE_SIZE case.
> Please don't make any large changes to this code at this time.
>
Amen, Good riddance
Boaz
next prev parent reply other threads:[~2011-06-01 19:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 3:18 [PATCH] NFS: filelayout should use nfs_generic_pg_test Weston Andros Adamson
2011-06-01 5:47 ` Boaz Harrosh
2011-06-01 12:14 ` Trond Myklebust
2011-06-01 13:36 ` Boaz Harrosh
2011-06-01 13:43 ` Benny Halevy
2011-06-01 14:32 ` Benny Halevy
2011-06-01 14:44 ` Weston Andros Adamson
2011-06-01 14:51 ` Benny Halevy
2011-06-01 15:36 ` Weston Andros Adamson
2011-06-01 16:01 ` Fred Isaman
2011-06-01 18:56 ` Benny Halevy
2011-06-01 19:17 ` Trond Myklebust
2011-06-01 19:29 ` Boaz Harrosh [this message]
2011-06-01 19:38 ` Trond Myklebust
2011-06-01 19:49 ` Boaz Harrosh
2011-06-01 19:52 ` Trond Myklebust
2011-06-01 18:07 ` Trond Myklebust
2011-06-01 19:13 ` Benny Halevy
2011-06-01 19:29 ` Trond Myklebust
2011-06-01 20:09 ` Benny Halevy
2011-06-06 16:47 ` William A. (Andy) Adamson
2011-06-06 18:21 ` Benny Halevy
2011-06-06 18:22 ` Myklebust, Trond
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=4DE69333.4020302@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bhalevy@panasas.com \
--cc=dros@netapp.com \
--cc=iisaman@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond@netapp.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 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.