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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
