[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimUjC8B0=nn5+yDshzp0hy6Zk1wxYHWEZbk83Tf@mail.gmail.com>
Date: Thu, 20 Jan 2011 09:32:24 +1100
From: Nick Piggin <npiggin@...il.com>
To: Yehuda Sadeh Weinraub <yehudasa@...il.com>
Cc: Nick Piggin <npiggin@...nel.dk>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Sage Weil <sage@...dream.net>,
ceph-devel@...r.kernel.org
Subject: Re: [PATCH 17/46] fs: Use rename lock and RCU for multi-step operations
On Thu, Jan 20, 2011 at 9:27 AM, Yehuda Sadeh Weinraub
<yehudasa@...il.com> wrote:
> On Tue, Jan 18, 2011 at 2:42 PM, Nick Piggin <npiggin@...il.com> wrote:
>> On Wed, Jan 19, 2011 at 9:32 AM, Yehuda Sadeh Weinraub
>
>>> There's an issue with ceph as it references the
>>> dentry->d_parent(->d_inode) at dentry_release(), so setting
>>> dentry->d_parent to NULL here doesn't work with ceph. Though there is
>>> some workaround for it, we would like to be sure that this one is
>>> really required so that we don't exacerbate the ugliness. The
>>> workaround is to keep a pointer to the parent inode in the private
>>> dentry structure, which will be referenced only at the .release()
>>> callback. This is clearly not ideal.
>>
>> Hmm, I'll have to think about it. Probably we can check for
>> d_count == 0 rather than parent != NULL I think?
>>
>
> That'll solve ceph's problem, don't know about how'd affect other
> stuff. We'll need to know whether this is the solution, or whether
> we'd need to introduce some other band aid fix.
No I think it will work fine. Basically we just need to know whether
we have been deleted, and if so then we restart rather than walking
back up the parent.
I'll send a patch in a few days. For the meantime, it's a rathe
small window for ceph to worry about. So we'll have something
before -rc2 which should be OK.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists