From: Boaz Harrosh <bharrosh@panasas.com>
To: Peng Tao <bergwolf@gmail.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
<linux-nfs@vger.kernel.org>, Benny Halevy <bhalevy@tonian.com>
Subject: Re: [PATCH v2 2/3] NFSv4.1: Always clear the NFS_INO_LAYOUTCOMMIT in layoutreturn
Date: Thu, 21 Mar 2013 23:59:28 +0200 [thread overview]
Message-ID: <514B82C0.2020401@panasas.com> (raw)
In-Reply-To: <20130321170614.GA4581@X61>
On 03/21/2013 07:06 PM, Peng Tao wrote:
> On Thu, Mar 21, 2013 at 10:13:00AM -0400, Trond Myklebust wrote:
> <snip>
>> @@ -1458,7 +1479,6 @@ static void pnfs_ld_handle_write_error(struct nfs_write_data *data)
>> dprintk("pnfs write error = %d\n", hdr->pnfs_error);
>> if (NFS_SERVER(hdr->inode)->pnfs_curr_ld->flags &
>> PNFS_LAYOUTRET_ON_ERROR) {
>> - clear_bit(NFS_INO_LAYOUTCOMMIT, &NFS_I(hdr->inode)->flags);
> Hi Trond and Boaz,
>
> If object layout requires layout being committed before returned (as fixed in
> the 3/3 patch), is it a potential problem to directly return layout here as
> well? e.g., if one lseg is successfully written and pending layoutcommit,
> then another lseg of the same file failed read/write, then layout will be
> returned w/o layoutcommit. For blocklayout, it is a potential data corruption
> and that's why block layout doesn't set PNFS_LAYOUTRET_ON_ERROR bit. So
> I'm wondering if object will suffer from the same issue?
>
Hi Tao
No, not at all. The objects layout has error reported as part of the
layout_return OPT. With exact devices that failed and why. In fact the
data should not be "committed" per ce, but a recovery process must be
preformed because we know that not all data of a stripe was committed
including parity, and the raid5 check-some is surly wrong. This is why
there is an error bit in layout_commit OPT to denote that this is not
a true commit and that there is an Error report on the way, for those
clients that must always lo_commit before lo_return even on Error.
(I know that 4.2 has plans for error-report RETURNs for other layout
types as well, this is part of why)
> Thanks,
> Tao
>
Cheers
Boaz
next prev parent reply other threads:[~2013-03-21 21:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 14:12 [PATCH v2 1/3] NFSv4.1: Fix a race in pNFS layoutcommit Trond Myklebust
2013-03-21 14:13 ` [PATCH v2 2/3] NFSv4.1: Always clear the NFS_INO_LAYOUTCOMMIT in layoutreturn Trond Myklebust
2013-03-21 14:13 ` [PATCH v2 3/3] NFSv4.1: Add a helper pnfs_commit_and_return_layout Trond Myklebust
2013-03-21 14:33 ` [PATCH v2 2/3] NFSv4.1: Always clear the NFS_INO_LAYOUTCOMMIT in layoutreturn Myklebust, Trond
2013-03-21 17:06 ` Peng Tao
2013-03-21 21:59 ` Boaz Harrosh [this message]
2013-03-22 1:28 ` Peng Tao
2013-03-21 14:32 ` [PATCH v2 1/3] NFSv4.1: Fix a race in pNFS layoutcommit Myklebust, Trond
2013-03-21 17:18 ` Peng Tao
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=514B82C0.2020401@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bergwolf@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox