Bug 823880

Summary:	[glusterfs-3.3.0-qa42]: null gfid id is printed if symlink fails
Product:	[Community] GlusterFS	Reporter:	Raghavendra Bhat <rabhat>
Component:	protocol	Assignee:	Raghavendra Bhat <rabhat>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Turner <bturner>
Severity:	medium	Docs Contact:
Priority:	low
Version:	pre-release	CC:	bturner, gluster-bugs
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.4.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-24 18:04:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Raghavendra Bhat 2012-05-22 11:21:26 UTC

Description of problem:

In client-protocol suppose symlink fails, then in the log message null gfid is printed. We should not try to print the gfid since inode will not be containing the gfid because of the failure.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. create a volume and mount it
2. run a test where symlink is failed.
3.
  
Actual results:
null gfid is printed in the log

Expected results:
null gfid should not be printed since symlink is failed and inode will not be containing any gfid.

Additional info:
[2012-05-22 15:05:21.816002] W [client3_1-fops.c:187:client3_1_symlink_cbk] 1-mirror-client-2: remote operation failed: File name too 
long. Path: /run25872/p7/l2 (00000000-0000-0000-0000-000000000000)

Comment 1 Raghavendra Bhat 2012-06-11 11:41:58 UTC

http://review.gluster.com/3411 fixes the issue and null gfid is not printed if symlink operation fails.

Comment 3 Ben Turner 2013-02-26 19:49:39 UTC

I just tested on the 3.4qa8 and when I run ltp I am still seeing:

    85	[2013-02-22 01:37:42.155837] E [posix.c:1273:posix_symlink] 0-REPLICATED-posix: symlink of /brick1/run14488/p7/l3 --> xxxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xxxxxxxxx/xx failed: File name too long

I also see this error on the latest 3.3 qa bits.  I am assuming that you are running ltp based on the output from your error message, is that correct?  Are you also seeing errors like this in the logs or am I seeing a different issues than htis BZ was opened for?

Comment 4 Raghavendra Bhat 2013-03-08 05:04:51 UTC

I think this log is ok. This is logged by the posix xlator as the name of the symlink given for creation was larger than the posix standard. Here you can see that NULL gfid is not logged. In the earlier case, when a this kind of things happen client xlator was logging the NULL gfid apart from the name of the entry. So the logging of NULL gfid is removed now in the client xlator.

Comment 5 Ben Turner 2013-05-28 15:19:32 UTC

Verified on:

glusterfs-3.4.0.8rhs-1.el6rhs.x86_64.rpm