On Jun 05, 2009 23:21 +0200, Alberich de megres wrote:
> first of all, sorry to bother you with some newbie questions.. but i
> got some doubts:
> for each inode you store all the lists of parent inode - filename, or
> only the inmediate parent dir?
Only the immediate {parent directory inode number, filename}, NOT the
whole pathname. It is possible to reconstruct the full pathname by
using the filename, and then following the parent directory inodes
upward and extracting their filename + parent directory inode, ..., root.
> If the first one, how you menage when you change partition mount point?
> if seconde one, how about disc overhead?
For ext3/4 the {parent inode number, filename} struct is (for average
sized files) about 48 bytes. If you format the filesystem with large
inodes (this is default in ext4, but possible with ext3 also) you can
store several hard link names into the inode itself with no cost, or
up to a hundred or so hard links into an external block in the very
rare case (< 0.01%) of files with multiple hard links.
> On 6/4/09, Andreas Dilger <adilger@xxxxxxx> wrote:
> > 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.
> >
> >
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
