From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] lustre treatment of dentry->d_name Date: Tue, 21 Oct 2014 22:17:10 +0100 Message-ID: <20141021211710.GV7996@ZenIV.linux.org.uk> References: <20141021011346.GP7996@ZenIV.linux.org.uk> <20141021040210.GR7996@ZenIV.linux.org.uk> <01AC4DD5-3DA1-4C98-BED3-B009AAF8C951@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Hammond, John" , "linux-fsdevel@vger.kernel.org" , "Dilger, Andreas" To: "Drokin, Oleg" Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58846 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933014AbaJUVRN (ORCPT ); Tue, 21 Oct 2014 17:17:13 -0400 Content-Disposition: inline In-Reply-To: <01AC4DD5-3DA1-4C98-BED3-B009AAF8C951@intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Oct 21, 2014 at 01:34:57PM +0000, Drokin, Oleg wrote: > I think it makes sense indeed. > The "get rid of duplicate mountpoint checks" patch has a hunk at ll_link > that looks like it belongs to "kill ll_link_generic()" patch, > otherwise the intermediate result is somewhat strange. Thanks; fixed and force-pushed. > > Another question: what's wrong with d_splice_alias() or d_materialise_unique()? > > I.e. why do we need ll_splice_alias()? I have patches in local queue > > We used to need it to also find and reuse invalid aliases, so that the dentry > cache does not get out of control with constant dentry invalidations we have. > > I checked the code and now that d_splice_alias is calling __d_find_any_alias > that seems to just pick the first alias off the list, we should be fine ITYM "the one and only". That's pretty much what d_splice_alias() is about - we do not allow more than one dentry (be it hashed or not) for a directory inode, so d_add() variant that can run into directory inode already with a dentry _must_ use that existing dentry instead of what it's been given. That's why we need it to be able to move a preexisting dentry in place of the one it's been given and return a new reference to that preexisting dentry. For non-directories and for directories that have no aliases it's just d_add() and return NULL. > with just using generic d_splice_alias. BTW, mind if we kill ll_umode_t? This kind of compat wrappers is the wrong way - it should be "supply an equivalent of more recent kernel stuff when builds on older kernels".