Bug 492911 - tar off gfs2 broken - truncated symbolic links
tar off gfs2 broken - truncated symbolic links
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
low Severity urgent
: rc
: ---
Assigned To: Steve Whitehouse
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2009-03-30 13:20 EDT by Everett Bennett
Modified: 2009-09-02 05:02 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 05:02:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Original report from Manager of ImE product team. (2.20 KB, text/plain)
2009-03-30 13:20 EDT, Everett Bennett
no flags Details
Proposed patch (360 bytes, patch)
2009-03-31 12:10 EDT, Steve Whitehouse
no flags Details | Diff
Version which applies against the RHEL kernel (443 bytes, patch)
2009-03-31 12:30 EDT, Steve Whitehouse
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 04:53:34 EDT

  None (edit)
Description Everett Bennett 2009-03-30 13:20:19 EDT
Created attachment 337234 [details]
Original report from Manager of ImE product team.

Description of problem:

Symbolic links are truncated and have size of 0 characters within gfs2 file system.

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

Name       : gfs2-utils
Arch       : x86_64
Version    : 0.1.53

How reproducible:

Create tar ball and then check using command such as:

Steps to Reproduce:

ime1/root> gtar zcf a.tgz app/oracle/product/11.1.0/db_1/bin/
ime1/root> gtar ztvf a.tgz|grep -F " ->"
lrwxrwxrwx oracle/oinstall        0 2009-03-26 12:19:45 app/oracle/product/11.1.0/db_1/bin/lbuilder -> /
ime1/root> ls -ld app/oracle/product/11.1.0/db_1/bin/lbuilder
lrwxrwxrwx 1 oracle oinstall 0 Mar 26 12:19 app/oracle/product/11.1.0/db_1/bin/lbuilder -> /dcs/appl01/app/oracle/product/11.1.0/db_1/nls/lbuilder/lbuilder

Actual results:

lrwxrwxrwx oracle/oinstall        0 2009-03-26 12:19:45 app/oracle/product/11.1.0/db_1/bin/lbuilder -> /

Expected results:

lrwxrwxrwx 1 oracle oinstall 0 Mar 26 12:19 app/oracle/product/11.1.0/db_1/bin/lbuilder -> /dcs/appl01/app/oracle/product/11.1.0/db_1/nls/lbuilder/lbuilder

Additional info:
Comment 1 Steve Whitehouse 2009-03-31 10:38:11 EDT
How were the links with zero size created? In particular were they pre-existing on a gfs1 filesystem which was converted, or created by some script or process?

I cannot reproduce the issue here at the moment, so I'm wonder what I might be doing differently. Roughly what % of the links are affected? ?Maybe I haven't created enough of them to see the issue yet...
Comment 2 Steve Whitehouse 2009-03-31 11:37:37 EDT
I think I might have found the issue....

if when you have some zero length symlinks on a gfs2 filesystem, you umount and then remount again, so the sizes suddenly become correct again? I'm working on a patch at the moment.
Comment 3 Steve Whitehouse 2009-03-31 12:10:03 EDT
Created attachment 337329 [details]
Proposed patch

This is the patch which will go upstream.
Comment 4 Steve Whitehouse 2009-03-31 12:30:54 EDT
Created attachment 337336 [details]
Version which applies against the RHEL kernel
Comment 5 Steve Whitehouse 2009-03-31 12:36:40 EDT
Patch posted to rhkernel-list.

Possible workarounds in the mean time:

1. umount/remount
2. Use the drop caches feature (via sysfs) which should mean that inodes (including symlinks) will be reread from disk.
Comment 7 Everett Bennett 2009-03-31 12:52:57 EDT
Can you provide a specific example on how to use vm.drop_caches ?

Especially with regards to "gfs2" ?

I found this link:  

 - http://www.linuxinsight.com/proc_sys_vm_drop_caches.html
Comment 8 Steve Whitehouse 2009-03-31 14:42:47 EDT
The link has the correct info. I'm afraid there is no way to make that filesystem specific, it will affect all the mounted filesystems and the effect will be to lower performance as the caches are refilled.

So its not in any way an ideal solution, but it might be the kind of thing which could be used in the short term if you just want to make an occasional back up of a directory tree or something along those lines.
Comment 9 Steve Whitehouse 2009-03-31 15:23:42 EDT
I should have also added that the echo 2 line is the one to use, since its the inodes that we wish to have reread.

The reproducer that I found was like this (for the benefit of qe):

mkdir -p a/b/c/d/e/f
touch a/b/c/d/e/f/g
ln -s a/b/c/d/e/f/g foo && stat foo

If the stat reveals a zero sized inode, than thats the bug. If nothing happens to cause the link's inode to be read before the system disposes of it (after the creation - and that doesn't take very long) then the link size will be set correctly so that the "stat foo" has to occur right away in order to show up the issue.
Comment 11 Don Zickus 2009-04-06 17:18:07 EDT
in kernel-2.6.18-138.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 14 Everett Bennett 2009-04-16 12:23:18 EDT
The issue appears to have been resolved.  Thanks.
Comment 16 errata-xmlrpc 2009-09-02 05:02:42 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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