Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Symlinks are not healed (during entry creation) if it has a pending metadata heal #4064

Open
rafikc30 opened this issue Mar 21, 2023 · 0 comments · May be fixed by #4065
Open

Symlinks are not healed (during entry creation) if it has a pending metadata heal #4064

rafikc30 opened this issue Mar 21, 2023 · 0 comments · May be fixed by #4065

Comments

@rafikc30
Copy link
Member

rafikc30 commented Mar 21, 2023

Description of problem:
An entry heal fails when the directory contains a symlink with pending metadata heal marked on the source. It seems like a regression caused by the change #2627. We are actually overloading the newentry mark flag to choose between soft link recreate as well as the creation of a hard link of a soft link.

The exact command to reproduce the issue:

  • create a file foo.txt
  • Kill a brick
  • create a soft link to the file foo.txt
  • Perform an ownership change to the softlink using chown -h
  • Start the brick
  • The heals will forever be stuck

We can also reproduce the same by running an extract of Linux tarball while a brick is down. After completing the extraction, start the brick and let the heal start. The heal info will report that the directory /linux-6.3-rc2/arch/arm//boot/dts/ is not completing the heals.

The full output of the command that failed:

  • Kill a brick
  • cd to gluster mount
  • tar -xvf
  • start the brick
  • give me some time to start the heal
  • check the heal status

Expected results:

Heal should complete

Mandatory info:
- The output of the gluster volume info command:

  • a replicate volume

- The output of the gluster volume status command:

- The output of the gluster volume heal command:

**- Provide logs present on following locations of client and server nodes -
/var/log/glusterfs/

**- Is there any crash ? Provide the backtrace and coredump

Additional info:

- The operating system / glusterfs version:

Note: Please hide any confidential data which you don't want to share in public like IP address, file name, hostname or any other configuration

rafikc30 added a commit to rafikc30/glusterfs that referenced this issue Mar 21, 2023
While an entry heal is on going, if there is a pending
metadata set on the source dentry, then the recreation
of soft link will fail to create on the destination.

This patch introduce a new flag and avoid overloading
the newentry mark flag

Change-Id: I862ab8d4318746ef2b15823ef5ad2272bff8aed7
fixes: gluster#4064
Signed-off-by: Mohammed Rafi KC <rafi.kavungal@iternity.com>
@rafikc30 rafikc30 linked a pull request Mar 21, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant