xfs
[Top] [All Lists]

Re: Don't use d_alloc_anon for open_by_handle

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Don't use d_alloc_anon for open_by_handle
From: Greg Banks <gnb@xxxxxxxxxxxxxxxxx>
Date: Mon, 05 May 2008 13:51:00 -0700
Cc: Niv Sardi <xaiki@xxxxxxx>, xfs-dev@xxxxxxx, xfs@xxxxxxxxxxx, gnb@xxxxxxx
In-reply-to: <20080505184424.GA25933@xxxxxxxxxxxxx>
Organization: File Serving Technologies ; Silicon Graphics Inc.
References: <20080501070244.GH108924158@xxxxxxx> <1209693339-4861-1-git-send-email-xaiki@xxxxxxx> <20080502060654.GA23912@xxxxxxxxxxxxx> <ncczlr5b6pt.fsf@xxxxxxx> <20080505095316.GA23934@xxxxxxxxxxxxx> <20080505184424.GA25933@xxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.12 (X11/20060911)
Christoph Hellwig wrote:
> On Mon, May 05, 2008 at 05:53:16AM -0400, Christoph Hellwig wrote:
>   
>> It shouldn't be slow.  You'd do the equivalent no_subtree check export
>> without parent fh, so what we do is call the fh_to_dentry method
>> and then call find_acceptable_alias to check if there's already an
>> dentry around and if yes use that one.  That latter part is what should
>> fix your problem.  If you want to be lazy you could just copy
>> find_acceptable_alias into the xfs code and call it directly and let me
>> clean up the mess later..
>>     
>
> Sorry, this was written before my cup of tea in the morning.
> find_acceptable_alias is of course a no-op in the no_subtree_check case,
> and thus it's identical to what we're currently doing in the handle
> code.  So any problem you see here will also be seen in an nfs
> environment with no_subtree_check, which is the sensible choise 
Agreed.
> and
> I think even the default these days.
I believe so.  We also use that as default on our shipping NAS servers
anyway.
>   So we'd better fix the lacking
> expiry in the core code. 
Mmm, sounds like fun.
>  Cc'ing Greg as he's been fighting this code
> quite a bit in the past.
>
>   
Thanks.  I'm on xfs-dev now so I've been lurking while you guys
discussed this :-)

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.


<Prev in Thread] Current Thread [Next in Thread>