save path to a file

save path to a file

[Alberich de megres]

Hi everyone!

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.

Any tip for this?

thanks!!

Re: save path to a file

[Andreas Dilger]

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.

Re: save path to a file

[Andreas Dilger]

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@sun.com> 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.