Bug 1520882 - [GSS]shard files present even after deleting vm from the rhev
Summary: [GSS]shard files present even after deleting vm from the rhev
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: sharding
Version: rhgs-3.2
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: RHGS 3.4.z Batch Update 2
Assignee: Krutika Dhananjay
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On: 1568521
Blocks: 1503143 1522624 1568758
TreeView+ depends on / blocked
 
Reported: 2017-12-05 11:46 UTC by Abhishek Kumar
Modified: 2019-10-16 02:59 UTC (History)
12 users (show)

Fixed In Version: glusterfs-3.12.2-27
Doc Type: Bug Fix
Doc Text:
Previously, when a file with a large number of shards was deleted, the shard translator synchronously sent unlink operations on all the shards simultaneously. This caused replicate translator to acquire locks on the .shard directory. Hence, when a huge number of locks got accumulated in locks translator, the search for a possible matching lock got slower. This caused timeouts which lead to disconnects and subsequent failure of file deletion, leading to stale shards being left in the .shard directory. With this fix, the deletion file operation is inclusive and the cleanup of shards is moved to the background. Irrespective of how big a sharded file is,its deletion operation will return immediately, and the space consumed by the associated shards to be deleted will be reclaimed eventually.
Clone Of:
: 1522624 1568521 (view as bug list)
Environment:
Last Closed: 2018-12-17 17:07:02 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3827 None None None 2018-12-17 17:07:17 UTC

Description Abhishek Kumar 2017-12-05 11:46:00 UTC
Description of problem:

ghost shard files present even after deleting vm from the rhev resulting more space utilized than it should actually have.

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

glusterfs-3.8.4-18.6.el7rhgs.x86_64 


How reproducible:

Customer environment


Actual results:

shard files available even after deleting vm

Expected results:

shard files should have deleted after vm deletion.

Additional info:

Comment 23 Anjana KD 2018-12-04 10:48:02 UTC
Updated Doctext field. Kindly review for technical accuracy.

Comment 24 Krutika Dhananjay 2018-12-05 11:33:24 UTC
(In reply to Anjana from comment #23)
> Updated Doctext field. Kindly review for technical accuracy.

Hi,

The doc itself looks good.
But I just wanted to highlight that this won't be a known issue once RHGS-3.4 Batch Update 2 is rolled out, which is where it is being fixed.

My understanding is that if this doc text is going to make it to the "known issues" section of batch update 2, then this won't be necessary as it is going to be fixed there.

-Krutika

Comment 26 Sahina Bose 2018-12-06 08:40:41 UTC
Changed doc-type.

Comment 27 Krutika Dhananjay 2018-12-10 05:51:01 UTC
Changed the doc text in CCFR format.

-Krutika

Comment 28 SATHEESARAN 2018-12-10 12:12:45 UTC
Verified with glusterfs-3.12.2-31.el7rhgs and RHV 4.2.7-1

1. Created a 2 TB disk on the gluster SD backed with 64MB sharded gluster volume
2. Created a filesystem on the disk and populated data almost around 2TB.
3. Deleted the VM image from RHV storage domain.

Observed that there are no hangs, no issues with SD or hosts, all the shards are deleted.
No ghost shards left behind.

Comment 29 errata-xmlrpc 2018-12-17 17:07:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3827


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