From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: How to handle non-local renames? Date: Thu, 28 Sep 2006 11:02:23 +0100 Message-ID: <20060928100223.GY29920@ftp.linux.org.uk> References: <1158597517.6297.10.camel@lade.trondhjem.org> <1158883241.5535.7.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: trond.myklebust@fys.uio.no, dhowells@redhat.com, linux-fsdevel@vger.kernel.org Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:31919 "EHLO ZenIV.linux.org.uk") by vger.kernel.org with ESMTP id S1751783AbWI1KC1 (ORCPT ); Thu, 28 Sep 2006 06:02:27 -0400 To: Miklos Szeredi Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Sep 22, 2006 at 08:22:19AM +0200, Miklos Szeredi wrote: > > I'm thinking something along the lines of the following patch on top of > > David's d_materialise_dentry(), which is already in the 2.6.18-mm > > kernels. Still untested (I'm working on that), but it attempts to do > > what you were proposing: > > > > 1) If instantiating a directory, check for aliases > > 2) If an alias is found in the dcache, attempt to rename the > > existing dentry instead of instantiating the alias. > > 3) Return ELOOP if the alias turns out to be a parent. > > What I'm still worried about is that by moving the alias across > directories without holding the rename mutex, you are violating a > premise in the cross directory rename locking rules: > > (2) if cross-directory rename holds the lock on filesystem, order will not > change until rename acquires all locks. (Proof: other cross-directory > renames will be blocked on filesystem lock and we don't start changing > the order until we had acquired all locks). > > Possible solution: > > - if lookup is being called for last components in rename then > s_vfs_rename_mutex is already held, we are OK. But currently we > don't know if lookup is called from rename. > > - otherwise trylock on s_vfs_rename_mutex, if succeeds then OK. > > - if fails, then alias can't be moved, make the inode bad (which > also unhashes it) and get a new inode, which will now be > unaliased. > > Also need to trylock i_mutex on alias->d_parent->i_inode after having > acquired s_vfs_rename_mutex for similar reasons. > > However it's getting rather ugly, and I'd rather have something > simpler. Simpler: if alias and our dentry share the parent, it's locked and we can rename without s_vfs_rename_mutex. If they do not, walk the tree under alias, unhash all non-directories and kill all directories. We keep local renames, we keep renames within directory and cross-directory rename on server ends up with invalidation when client notices it. We don't _care_ if lookup() is not from rename. That's OK.