[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: reserve fields in inode for parent ptr and alloc policy
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Thu, 11 Apr 2013 08:54:20 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130411030057.GF10481@dastard>
References: <20130410182438.268267840@xxxxxxx> <20130411030057.GF10481@dastard>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 04/10/13 22:00, Dave Chinner wrote:
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?

Then you might want to bump the pad size.

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)

As I stated, the hard links will use extended attribute entries.

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

Per the 2005 XFS features meeting, the inode and directory offset will uniquely describe a link - (thank-you to Glen Overby for that observation). The concept code just using one link verifies this fact. Using the inode/offset as the identifier is compact and also gives information to the file name.

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


yep, read it, studied it, plan to use parts of it but only where needed.

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.

According to Geoffrey's notes, the hybrid approach was discussed too. The single link case will save all the EA operations for the majority of the inodes.

Release early, release often?

No, trust but verify.

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.




<Prev in Thread] Current Thread [Next in Thread>