Yeah, yeah, this has gotten buried several times and better get out on
the list for discussion before it gets buried yet again.
Parent inode support allow XFS to quickly derive a file name and
path from the mount point. This can aid in directory/path policies
and can help relocate items during filesystem shrink.
1) Representation of a parent inode entry:
There are several ways to represent the parent inode entry.
A 2005 XFS meeting came up with the following ideas:
1) Storing the parent inode# list inside the inode with a separate field
separate fork
2) Storing the parent inode# list in EA names with null values
EA: <name=inode#, value=NULL>
3) As in (2) but store the 1st parent inode# in a field in the inode
first-parent-ptr + <name=inode#, value=NULL>
4) As in (2) but store the hardlink names as EA values
EA: <name=inode#, value=fname>
5) As in (2) but store the EAs on directories as well as leaf files
EAs on directories.
6) Storing the parent inode# + directory offset in EA names with null values
EA: <name=inode#diroffset, value=NULL>
7) (kind of (4) + (6))
EA: <name=inode#diroffset, value=filename>
The preferred method was #6. Using directory and the entry offset into the
directory has turned out to be a very good idea. Directory growth and
contractions and xfs_repair does not compromise the encoding. The offset
can be gotten while doing the directory code. It is compact and easy the
parent inode / offset allows quick access to the filename information.
2) In the inode core or not?
Since we have new inode, adding the first link into the inode core
makes things very convenient. I implemented and tested both ways,
and prefer adding the first link in the inode core. One less fork
to worry about on single linked entries, like directories. xfs_create
and xfs_symlink do not need extended attribute calls, and simplifies the
parent path creation.
This implementation of the code uses 12 bytes of the inode padding for
parent pointers and places the first link in the inode core..
3) To lock between directory and attribute changes.
On one hand, the vfs mutex will keep the directory and attribute changes
in sync.
On the other hand keeping the directory and extended attribute in one
transaction should keeping the changes atomic when the filesystem
is forced down between the directory and attribute changes. Despite
all the gore (see below) of doing the directory and attribute changes
in one transaction, I think it is the correct thing to do.
The gore of keeping the directory and attribute operations in one transaction:
1) The attribute code was not written to be embedded in other functions.
The attribute code can commit and trans_dup another transaction
(xfs_trans_roll and xfs_bmapi_finish). The attribute operations have
to be done last in the transactions and even then a terrible hack has
to be done to figure out if the transaction was commited in an earlier
attribute operation so we could add the inode back into the transaction.
2) xfs_rename is log space reservation expensive.
The log_count:
xfs_rename 2
xfs_attr_set 3 and that does not add any extra for the embedded
xfs_bmap_add_attrfork()
xfs_attr_remove 3 and we can have 2 of these in a rename.
3) xfs_rename() with no allocated space reserve blocks can cause
hanging. I disabled the code in xfs_rename that:
error = xfs_trans_reserve(tp, &M_RES(mp)->tr_rename, spaceres, 0);
#ifdef HERE
if (error == ENOSPC) {
spaceres = 0;
error = xfs_trans_reserve(tp, &M_RES(mp)->tr_rename, 0, 0);
}
#endif
...
----
The enclosed RFC sample code does NOT keep the directory and attribute in
the same transaction and this code is simpler than the embedded version.
It comes with the following patches:
----- kernel space bits -----
get the offset patches:
01-pptr-retrieve-info-from-directory.patch
02-pptr-add-to_xfs_dir_removename.patch
03-pptr-add-to_xfs_dir_replace.patch
add the incompatability bit and the parent test:
04-pptr-add-xfs_sb_version_hasparent.patch
add the parent flags to the attribute files:
05-pptr-add-xfs_parent-files.patch
add the inode parent / offset to the inode:
06-pptr-add-inode-incore.patch
add the support to the differ routines:
07-pptr-add-to-xfs_create.patch
08-pptr-add-to-xfs_symlink.patch
09-pptr-add-to_xfs_link.patch
10-pptr-add-to_xfs_remove.patch
11-pptr-add-incore-to-rename.patch
xfs_rename is the most complex. I tried to add to the inode entries first
and then keep the number of extended attribute operations down. The single
transaction xfs_rename is even more complicated than this code.
add the ioctl to get the paths. SGI may want to add the inode generation
field to the output and offset information can be dropped. Minor stuff:
12-pptr-add-incore-to-getparentpaths_by_handle.patch
----- user space bits -----
The user space stuff is include for anyone who want to
kick the tires. Parent pointer requires a v5 super block
(-m crc=1") and "-i parent=1". xfstests 114 indicated that
the parent option belongs on the "-i" option.
01-xfsprogs-add-parent-pointers.patch
The xfs_repair change is there to prevent the attribute to be
thrown away because the name as corrupt. Much more xfs_repair
(and xfs_db) work is needed:
02-xfsprogs-pptr-fix-namecheck.patch
Tiny xfs_db code to list the parent/offset information:
03-xfsprogs-pptr-add-to-xfs_db.patch
Added the ioctl support. Fixed xfs_io parent -p and -c commands
With xfs_io a person can dump the parent pointer information by
path and do a consistency check. xfstest xfs/114 will run correctly.
The output will fail since I export the parent's offset instead of
the inode's generation. As mentioned above, that will probably changed:
04-xfsprogs-pptr-xfs_io-getparentpaths_by_handle.c
Add the XFS_GEOM for xfs_repair/xfs_info:
05-xfsprogs-pptr-add-to-xfs_info.patch
--Mark
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
