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:
http://oss.sgi.com/archives/xfs/2009-01/msg01068.html
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.
Cheers,
Dave.
--Mark
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
