From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751185Ab1A0FS3 (ORCPT ); Thu, 27 Jan 2011 00:18:29 -0500 Received: from mail-wy0-f174.google.com ([74.125.82.174]:65364 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835Ab1A0FS2 (ORCPT ); Thu, 27 Jan 2011 00:18:28 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J3kRGsjw8zLwrZ+0b0/FJjzhD4pgVjzEmTkzkSolUJxKdlgtADJvJu/emGdrddRr+z GgzvskEDQ8qzv1zx7sW7UNweAzpWf+OA99qqUb41LCDys6n9kgEoU2aXy560O9mUEvUB C+1X2vXdPhx2mBmQ20lQ/bfc25SIVWfNobvls= MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 27 Jan 2011 16:18:25 +1100 Message-ID: Subject: Re: [PATCH 17/46] fs: Use rename lock and RCU for multi-step operations From: Nick Piggin To: Yehuda Sadeh Weinraub Cc: Nick Piggin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Sage Weil , ceph-devel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 26, 2011 at 9:10 AM, Yehuda Sadeh Weinraub wrote: > On Wed, Jan 19, 2011 at 2:32 PM, Nick Piggin wrote: >> On Thu, Jan 20, 2011 at 9:27 AM, Yehuda Sadeh Weinraub >> wrote: >>> On Tue, Jan 18, 2011 at 2:42 PM, Nick Piggin 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. >> > > I guess that it's a bit late for -rc2, should we assume that it'll be on -rc3? Yeah, I'm sorry I've been travelling and a bit disconnected. NFS folk are having a similar problem and looks like similar proposed fix will do it. http://marc.info/?l=linux-fsdevel&m=129599823927039&w=2 So I think it is the best way to go to restore behaviour back to what filesystems already expect, to avoid more surprises in future. Thanks, Nick