David Spisla
2019-Jun-17 10:15 UTC
[Gluster-users] Pending heal status when deleting files which are marked as to be healed
Hello Gluster Community, my newest observation concerns the self heal daemon: Scenario: 2 Node Gluster v5.5 Cluster with Replica 2 Volume. Just one brick per node. Access via SMB Client from a Win10 machine How to reproduce: I have created a small folder with a lot of small files and I copied that folder recursively into itself for a few times. Additionally I copied three big folders with a lot of content into the root of the volume. Note: There was no node down or something else like brick down, etc.. So the whole volume was accessible. Because of the recursively copy action all this copied files whre listed as to be healed (via gluster heal info). Now I set some of the effected files ReadOnly (they get WORMed because worm-file-level is enabled). After this I tried to delete the parent folder of that files. Expected: All files should be healed Actually: All files, which are Read-Only, are not healed. heal info shows permanently that this files has to be healed. glustershd log throws error and brick log (with level DEBUG) permanently throws a lot of messages which I don't understand. See the attached file which contains all informations, also heal info and volume info, beside the logs Maybe some of you know whats going on there? Since we can reproduce this scenario, we can give more debug information if needed. Regards David Spisla -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190617/81b477d3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: pending_heal.tar.gz Type: application/x-gzip Size: 111809 bytes Desc: not available URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190617/81b477d3/attachment.gz>
Ravishankar N
2019-Jun-19 16:06 UTC
[Gluster-users] Pending heal status when deleting files which are marked as to be healed
On 17/06/19 3:45 PM, David Spisla wrote:> Hello Gluster Community, > > my newest observation concerns the self heal daemon: > Scenario: 2 Node Gluster v5.5 Cluster with Replica 2 Volume. Just one > brick per node. Access via SMB Client from a Win10 machine > > How to reproduce: > I have created a small folder with a lot of small files and I copied > that folder recursively into itself for a few times. Additionally I > copied three big folders with a lot of content into the root of the > volume. > Note: There was no node down or something else like brick down, etc.. > So the whole volume was accessible. > > Because of the recursively copy action all this copied files whre > listed as to be healed (via gluster heal info).This is odd. How did you conclude that writing to the volume (i.e. recursive copy) was the reason for the files to be needing heal? Did you check if there were any gluster messages about disconnects in the smb client logs?> Now I set some of the effected files ReadOnly (they get WORMed because > worm-file-level is enabled). After this I tried to delete the parent > folder of that files. > > Expected: All files should be healed > Actually: All files, which are Read-Only, are not healed. heal info > shows permanently that this files has to be healed.Does disabling read-only let the files to be healed?> > glustershd log throws error and brick log (with level DEBUG) > permanently throws a lot of messages which I don't understand. See the > attached file which contains all informations, also heal info and > volume info, beside the logs > > Maybe some of you know whats going on there? Since we can reproduce > this scenario, we can give more debug information if needed.Is it possible to? script the list of steps to reproduce this issue? Regards, Ravi> > Regards > David Spisla > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190619/6b5fd089/attachment.html>