Re: [PATCH 14/24] pnfs_submit: use fsdata to pass lseg

Benny Halevy
2010-06-10T12:45:25Z

On 06/10/2010 01:33 PM, Fred Isaman wrote:
>
> On Jun 9, 2010, at 8:08 AM, Fred Isaman wrote:
>
>> On Wed, Jun 9, 2010 at 6:38 AM, Benny Halevy <bhalevy@panasas.com> wrote:
>>> Fred, how does that patch interact with
>>> 285052f pnfs_post_submit: Restore "pnfs: pnfs_do_flush"
>>> and the latter patches that depend on it?
>>>
>>> Benny
>>>
>>
>> They will have to be modified. I'll look at that today.
>>
>> Fred
>
> OK, this is a general git question. How in the world do I send in these modifications?
>
> Basically, because of the way we have pnfs-submit in the middle of our tree, I have a branch that looks like:
>
> A->B->C->D
>
> I've inserted my new patch F between And B, which requires a rebase of the subsequent patches:
>
> A->F->B'->C'->D'
>
> But that rebase is non-trivial, in particular for patch C (a block-layout patch), and I want to communicate the modifications I made.
>
> The best I have been able to come up with is to do the minimal obvious rebase, just sufficient to remove all the conflict markers,
> then add a following modification patch, so I would have something like:
>
> A->F->B'->C'->C''->D'
>
> and I could send in C''. But this seems less than ideal, especially when you consider I have ~10 patches which would require this handling.
>

You can either send your a patchset based on C and I can
rebase parts of it onto A and B or just send the clean rebased
patches from B and C and we can review the diff (B vs. B' and
C vs. C')

Benny

> Fred
>
>
>>
>>> On Jun. 08, 2010, 7:19 +0300, Fred Isaman <iisaman@netapp.com> wrote:
>>>> Preparing for LAYUTGET invocation in nfs_write_begin to be the
>>>> only invocation in the write path.
>>>>
>>>> It isn't used at all yet, but it should be properly referenced/dereferenced
>>>>
>>>> Signed-off-by: Fred Isaman <iisaman@netapp.com>
>>>> ---
>>>> fs/nfs/file.c | 16 +++++++++++++---
>>>> 1 files changed, 13 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
>>>> index 03601d2..fde6cb5 100644
>>>> --- a/fs/nfs/file.c
>>>> +++ b/fs/nfs/file.c
>>>> @@ -420,6 +420,8 @@ static int nfs_write_begin(struct file *file, struct address_space *mapping,
>>>> file->f_path.dentry->d_name.name,
>>>> mapping->host->i_ino, len, (long long) pos);
>>>>
>>>> + pnfs_update_layout(mapping->host, NULL, NFS4_MAX_UINT64, 0, IOMODE_RW,
>>>> + (struct pnfs_layout_segment **) fsdata);
>>>> start:
>>>> /*
>>>> * Prevent starvation issues if someone is doing a consistency
>>>> @@ -428,11 +430,13 @@ start:
>>>> ret = wait_on_bit(&NFS_I(mapping->host)->flags, NFS_INO_FLUSHING,
>>>> nfs_wait_bit_killable, TASK_KILLABLE);
>>>> if (ret)
>>>> - return ret;
>>>> + goto out;
>>>>
>>>> page = grab_cache_page_write_begin(mapping, index, flags);
>>>> - if (!page)
>>>> - return -ENOMEM;
>>>> + if (!page) {
>>>> + ret = -ENOMEM;
>>>> + goto out;
>>>> + }
>>>> *pagep = page;
>>>>
>>>> ret = nfs_flush_incompatible(file, page);
>>>> @@ -447,6 +451,11 @@ start:
>>>> if (!ret)
>>>> goto start;
>>>> }
>>>> + out:
>>>> + if (ret) {
>>>> + put_lseg(*fsdata);
>>>> + *fsdata = NULL;
>>>> + }
>>>> return ret;
>>>> }
>>>>
>>>> @@ -486,6 +495,7 @@ static int nfs_write_end(struct file *file, struct address_space *mapping,
>>>>
>>>> unlock_page(page);
>>>> page_cache_release(page);
>>>> + put_lseg(fsdata);
>>>>
>>>> if (status < 0)
>>>> return status;
>>>
>>> --
>>> 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
>>>
>
> --
> 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