On Sat, Oct 21, 2017 at 1:41 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Thu, Oct 19, 2017 at 07:11:50AM +0300, Amir Goldstein wrote: >> On Thu, Oct 19, 2017 at 1:55 AM, Allison Henderson >> <allison.henderson@xxxxxxxxxx> wrote: >> > Hi all, >> > >> > This is the third version of parent pointer attributes for xfs. >> > I've integrated the suggestions made since v2, mostly moving the >> > attr buffers in the xfs_attr_log_item to pointers that point to >> > xfs_attr_item. I've also implementing the recovery routines for >> > the xfs_attr_log_format. If I missed anything please point it >> > out. As always, comments and feedback are appreciated. Thank >> > you! >> > >> >> A minor comment about the cover letter. >> All designated reviewers must know exactly what "parent pointers" are for, >> but it could be useful to add some context in the cover letter about the purpose >> of this work for the sake of other readers on the list. Useful to refer to the >> upcoming scrub support patches. >> >> BTW, not sure if this was mentioned in the previous lifetime of those >> patches, but parent pointers can be used to implement exportfs operation >> xfs_fs_fh_to_parent() for "non-connectable" file handles (FILEID_INO32_GEN) >> and to implement xfs_fs_get_name(), which would make reconnect_path() >> *much* more efficient. > > However, XFS only uses FILEID_INO32_GEN for directories > because they have known parents. For them, we implement ->get_parent() > and that means reconnect_path just does ->lookup("..") to find the > parents and doesn't need anything special. > > We use FILEID_INO32_GEN_PARENT for all other types of files to > encode the ino # + generation of the parent inode into the handle. > That means for any non-dir file handle, our implemention of > ->fh_to_parent will get us the parent info as efficiently as > possible. We only encode FILEID_INO32_GEN_PARENT when we are asked for a "connectable" file handle, which is NOT the case with name_to_handle_at(2) and is the case with nfsd on when NFS share is exported with subtree_check options, which AFAIK, is the less common case. The question is, when we encode a non-connectable file handle (FILEID_INO32_GEN), will nfsd benefit from getting a connected file handle after decode? (result may always be connected if dentry is already in cache). > > IOWs, parent pointers won't actually speed up filehandle -> > dentry reconnection on XFS at all because we already encode parent > pointers into the filehandles that need them.... Look at default implementation of ->get_name() in expfs.c and you will see why I wrote that xfs_fs_get_name() would make reconnect_path() *much* more efficient, even for directories. Cheers, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html