Bug 823880 - [glusterfs-3.3.0-qa42]: null gfid id is printed if symlink fails
[glusterfs-3.3.0-qa42]: null gfid id is printed if symlink fails
Product: GlusterFS
Classification: Community
Component: protocol (Show other bugs)
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Raghavendra Bhat
Ben Turner
Depends On:
  Show dependency treegraph
Reported: 2012-05-22 07:21 EDT by Raghavendra Bhat
Modified: 2013-07-24 14:04 EDT (History)
2 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-24 14:04:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Raghavendra Bhat 2012-05-22 07:21:26 EDT
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.
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 07:41:58 EDT
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 14:49:39 EST
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 00:04:51 EST
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 11:19:32 EDT
Verified on:


Note You need to log in before you can comment on or make changes to this bug.