From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: save path to a file Date: Thu, 04 Jun 2009 15:23:34 -0600 Message-ID: <20090604212334.GO9002@webber.adilger.int> References: <12d708830906041305u7964737el1bdd1a5b1c214315@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org To: Alberich de megres Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:56666 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbZFDVXr (ORCPT ); Thu, 4 Jun 2009 17:23:47 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n54LNl3j007752 for ; Thu, 4 Jun 2009 14:23:47 -0700 (PDT) Content-disposition: inline Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKQ00600GIQEZ00@fe-sfbay-10.sun.com> for linux-fsdevel@vger.kernel.org; Thu, 04 Jun 2009 14:23:47 -0700 (PDT) In-reply-to: <12d708830906041305u7964737el1bdd1a5b1c214315@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 04, 2009 22:05 +0200, Alberich de megres wrote: > I got one questiong about saving file path to an inode. The idea is to > have some data on inode that allows me to get path ( or one of the > paths ) to this file ( whithout using d_find_alias, well i don't know > any other way since an inode could have many paths ). > > If i save full path to an inode ( on the same inode using xattr ), > this works fine since i got full path to a file but of course if i > change mount point for this partition. We have implemented an attribute for Lustre that stores an array of (the Lustre equivalent of) {parent inode, filename}[] tuples as an extended attribute on each inode. There need to be multiple entries in case of hard links to the file. Using the parent inode number(s) allows reconstructing the full pathname(s) in O(num_links) for each file, without significant overhead. While this attribute needs to be updated for rename/link/unlink, the inode itself has to be dirtied due to ctime/nlinks updates, and if the attribute is stored inside the inode itself (in the most common nlinks==1 case) there are no additional seeks. Implementing this for ext4 would be fairly interesting, and would allow e2fsck to recover from e.g. complete destruction of the directory tree, so long as the inode tables are intact. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.