[PATCH] xfs: reserve fields in inode for parent ptr and alloc policy

[Dave Chinner]

On Wed, Apr 10, 2013 at 01:24:24PM -0500, Mark Tinguely wrote:
> Reserve fields in new inode layout for parent pointer and
> allocation policy.

Not without a design review - there is no way we are going to
blindly reserve space in any on-disk structure without first having
a solid design, published proof-of-concept code and agreement that
the format changes being proposed are the right way to proceed.

Where are the design docs/code for these features?

> 		----
> The inode will hold the parent information for the first
> link to a file. Information for the other links will be
> held in extended attribute entries.
> 
> The "di_parino" is the inode of the parent directory. The
> directory information for this entry is located the parent
> directory with "di_paroff" offset. 
> 
> The di_parino/di_paroff concept code is running.

How does it handle hard links? (i.e. multiple parents)

Also, inode number is not enough for unique identification of the
parent - generation number is also required.

FWIW, lets go back to the (was almost finished) parent pointer
code from 2009:

http://oss.sgi.com/archives/xfs/2009-01/msg01068.html

That uses xattrs to store parent information - inode #, generation
#, and a counter - for each parent. It requires a counter because
you can have the same inode hard linked into the same parent
directory multiple times:

typedef struct xfs_parent_eaname_rec {
       __be64  p_ino;
       __be32  p_gen;
       __be32  p_cnt;
} xfs_parent_eaname_rec_t;

And a transaction appended to the the inode create, link, rename and
remove operations to manage the xattrs so all cases involving hard
links work just fine.

Indeed, the single di_parino/di_paroff concept was one of the
original designs considered because of it's simplicity, but it was
rejected because of that very simplicity - it cannot handle common
use cases involving hardlinks.

Release early, release often?

> 		----
> The "di_allocpolicy" will be used to remember the allocation
> policy associated with this inode.

This is exactly what we have padding in the inode for - so that
future additions to the on-disk inode can be added via feature bits
to indicate the fields are present. 

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com