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
