Bug 765391 (GLUSTER-3659)
Summary: | hardlinks fail to self-heal | ||
---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | Joe Julian <joe> |
Component: | replicate | Assignee: | Pranith Kumar K <pkarampu> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Shwetha Panduranga <shwetha.h.panduranga> |
Severity: | low | Docs Contact: | |
Priority: | urgent | ||
Version: | 3.2.3 | CC: | aavati, az9901, gluster-bugs, jhughes, purpleidea, vijay |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | glusterfs-3.4.0 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-07-24 17:55:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 817967 |
Description
Joe Julian
2011-09-28 21:18:49 UTC
Create a volume test1: gluster volume create replica 2 test1 server1:/data/test1 server2:/data/test1 Mount the volume: mount -t glusterfs server1:test1 /mnt/test1 Create a file: cd /mnt/test1 echo asdf > foo Create hardlinks: ln foo bar ln foo baz ls -li 5767174 -rw-r--r-- 3 root root 5 Sep 28 16:59 bar 5767174 -rw-r--r-- 3 root root 5 Sep 28 16:59 baz 5767174 -rw-r--r-- 3 root root 5 Sep 28 16:59 foo Unmount and stop everything: umount /mnt/test1 (on both servers) service glusterd stop service glusterfsd stop Wipe out a share directory to simulate a drive replacement: (server2) rm -rf /data/test1 mkdir /data/test1 Start the server, mount and stat the files to start a self-heal: (on both servers) service glusterd start (one machine) mount -t glusterfs server1:test1 /mnt/test1 cd /mnt/test1 stat * ls -l total 16 -rw-r--r-- 1 root root 0 Sep 28 17:02 bar -rw-r--r-- 1 root root 0 Sep 28 17:02 baz -rw-r--r-- 1 root root 5 Sep 28 16:59 foo (note the 0-sized files) On the backend, server1: getfattr -m . -d -e hex * # file: bar trusted.afr.test1-client-0=0x000000000000000000000000 trusted.afr.test1-client-1=0x000000000000000000000000 trusted.gfid=0x8f3a01d1ee1c4dbe8f851a43f8b19567 # file: baz trusted.afr.test1-client-0=0x000000000000000000000000 trusted.afr.test1-client-1=0x000000000000000000000000 trusted.gfid=0x8f3a01d1ee1c4dbe8f851a43f8b19567 # file: foo trusted.afr.test1-client-0=0x000000000000000000000000 trusted.afr.test1-client-1=0x000000000000000000000000 trusted.gfid=0x8f3a01d1ee1c4dbe8f851a43f8b19567 ls -li total 24 2883587 -rw-r--r-- 3 root root 5 Sep 28 16:59 bar 2883587 -rw-r--r-- 3 root root 5 Sep 28 16:59 baz 2883587 -rw-r--r-- 3 root root 5 Sep 28 16:59 foo On the backend, server2: getfattr -m . -d -e hex * # file: bar trusted.gfid=0x8f3a01d1ee1c4dbe8f851a43f8b19567 # file: baz trusted.gfid=0x8f3a01d1ee1c4dbe8f851a43f8b19567 # file: foo trusted.afr.test1-client-0=0x000000000000000000000000 trusted.afr.test1-client-1=0x000000000000000000000000 trusted.gfid=0x8f3a01d1ee1c4dbe8f851a43f8b19567 ls -li total 16 2883588 -rw-r--r-- 1 root root 0 Sep 28 17:02 bar 2883589 -rw-r--r-- 1 root root 0 Sep 28 17:02 baz 2883590 -rw-r--r-- 1 root root 5 Sep 28 16:59 foo Really? This can easily result in data loss. (In reply to comment #2) > Really? This can easily result in data loss. It is a P1 enhancement as the code changes involved are not trivial. My idea was to use the sticky-bit pointers to simulate hardlinks. The actual file would still need some sort of pointer back to the sticky, then, probably an extended attribute. Renames would have to go back to all the pointers and update them to the new filename. Deletes would probably just trigger a rename to one of the stickies, which would then have to update all the stickies to the new filename. (In reply to comment #4) > My idea was to use the sticky-bit pointers to simulate hardlinks. The actual > file would still need some sort of pointer back to the sticky, then, probably > an extended attribute. > > Renames would have to go back to all the pointers and update them to the new > filename. Deletes would probably just trigger a rename to one of the stickies, > which would then have to update all the stickies to the new filename. We're introducing a solid framework (gfid filehandles) to address hardlinks and rename self-heals in 3.4. Some of the framework code can be found in https://github.com/avati/glusterfs/commits/iops. It is best to await this "right" fix in 3.4 than kludgy patchwork. Avati *** Bug 764393 has been marked as a duplicate of this bug. *** CHANGE: http://review.gluster.com/2841 (cluster/afr: Hardlink Self-heal) merged in master by Vijay Bellur (vijay) CHANGE: http://review.gluster.com/3056 (cluster/afr: Fix frame leak in hardlink self-heal) merged in master by Vijay Bellur (vijay) Could someone please clarify the status of hardlinks working correctly in the latest stable gluster? Can these be used properly? Is there a workaround in case of node failures? Would be much appreciated. James Verified the bug on 3.3.0qa43. Bug is fixed. is this change, 3.3.0qa43, part of the released 3.3.0-1 standard RPMS or is it to be rolled into a future version? It is part of 3.3.0 |