client: don't request lookup parent if ino is root

[renhwztetecs]

Signed-off-by: huanwen ren ren.huanwen@zte.com.cn

[renhwztetecs]

lookup_parent exit(1) = -22 when ino is 1

2016-12-13 19:21:34.696287 7f4a20949480 3 client.3835100 lookup_ino exit(1) = 0
2016-12-13 19:21:34.696293 7f4a20949480 3 client.3835100 lookup_parent enter(1) =
2016-12-13 19:21:34.696297 7f4a20949480 15 inode.get on 0x7f49fc0164a0 1.head now 5
2016-12-13 19:21:34.696303 7f4a20949480 10 client.3835100 choose_target_mds resend_mds specified as mds.0
2016-12-13 19:21:34.696309 7f4a20949480 20 client.3835100 mds is 0
2016-12-13 19:21:34.696313 7f4a20949480 10 client.3835100 send_request rebuilding request 3 for mds.0
2016-12-13 19:21:34.696316 7f4a20949480 20 client.3835100 encode_cap_releases enter (req: 0x7f4a2b39bae0, mds: 0)
2016-12-13 19:21:34.696319 7f4a20949480 20 client.3835100 send_request set sent_stamp to 2016-12-13 19:21:34.696318
2016-12-13 19:21:34.696329 7f4a20949480 10 client.3835100 send_request client_request(unknown.0:3 lookupparent #1 2016-12-13 19:21:34.696300) v3 to mds.0
2016-12-13 19:21:34.696357 7f4a20949480 20 client.3835100 awaiting reply|forward|kick on 0x7fffd40ee610
2016-12-13 19:21:34.696375 7f4a0affd700 10 client.3835100 put_inode on 1.head(faked_ino=0 ref=5 ll_ref=2 cap_refs={} open={} mode=40777 size=0/0 mtime=2016-12-13 16:20:59.000000 caps=pAsLsXsFs(0=pAsLsXsFs) has_dir_layout 0x7f49fc0164a0)
2016-12-13 19:21:34.696414 7f4a0affd700 15 inode.put on 0x7f49fc0164a0 1.head now 4
2016-12-13 19:21:34.696421 7f4a0affd700 10 client.3835100 put_inode on 1.head(faked_ino=0 ref=4 ll_ref=2 cap_refs={} open={} mode=40777 size=0/0 mtime=2016-12-13 16:20:59.000000 caps=pAsLsXsFs(0=pAsLsXsFs) has_dir_layout 0x7f49fc0164a0)
2016-12-13 19:21:34.696448 7f4a0affd700 15 inode.put on 0x7f49fc0164a0 1.head now 3
2016-12-13 19:21:34.696693 7f4a0affd700 20 client.3835100 handle_client_reply got a reply. Safe:1 tid 3
2016-12-13 19:21:34.696698 7f4a0affd700 10 client.3835100 insert_trace from 2016-12-13 19:21:34.696318 mds.0 is_target=0 is_dentry=0
2016-12-13 19:21:34.696710 7f4a0affd700 10 client.3835100 insert_trace -- no trace
2016-12-13 19:21:34.696714 7f4a0affd700 20 client.3835100 handle_client_reply signalling caller 0x7fffd40ee610
2016-12-13 19:21:34.696728 7f4a0affd700 20 client.3835100 handle_client_reply awaiting kickback on tid 3 0x7f4a0affb8f0
2016-12-13 19:21:34.696749 7f4a20949480 20 client.3835100 sendrecv kickback on tid 3 0x7f4a0affb8f0
2016-12-13 19:21:34.696756 7f4a20949480 20 client.3835100 lat 0.000437
2016-12-13 19:21:34.696760 7f4a20949480 3 client.3835100 lookup_parent exit(1) = -22

[jcsp]

@renhwztetecs what was the old behaviour? If it was doing something bad (like crashing) could you open a tracker ticket an reference it from the commit please

[gregsfortytwo]

Do you have a specific reason to not include the inode? In general we need this and I think the reasons still apply to a lookup_parent — the inode whose parent we're looking up might have migrated and need to be searched out, amongst other things.

[renhwztetecs]

@gregsfortytwo thanks for your reviews
It's cleanup.
I don't see the transfer from the client to the server side of the INO, will be used in the server handle_client_lookup_ino () function, at the same time, the inode whose parent can use "CInode *in = mdcache->get_inode(ino)" get it from the Server::handle_client_lookup_ino().
do not know I understand the right，if not, please correct me，thanks.

[jcsp]

Looks correct to me: inode is only used in build_client_request if the path is unset, so setting both was redundant.

[renhwztetecs]

@jcsp
thank you, using the command "ceph-client-debug 1" can repetition.
I think if client can judge ino is not parent，why to want to the server to judge.
Server side have judged，so it's no abnormal

[jcsp]

Looks correct to me: inode is only used in build_client_request if the path is unset, so setting both was redundant.