Bug 1123643 - [RFE] Allow user to follow block disks removal operation in case "wipe after delete flag" is marked
Summary: [RFE] Allow user to follow block disks removal operation in case "wipe after ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-27 14:01 UTC by Ori Gofen
Modified: 2019-04-28 10:06 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-21 09:26:50 UTC
oVirt Team: Storage
Embargoed:
ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description Ori Gofen 2014-07-27 14:01:50 UTC
Description of problem:
Right now when creating a large block disk (the larger the disk,the larger the problem)
and marking "wipe after delete" flag as 'True',then removing this disk.
disk existence is wiped from the UI while actually,removing this kind of disk takes a lot of time(since vdsm has to fill the whole disk with zero's).
this can be very misleading to an unaware sysadmin.

for example:
Deleting two 30G disks(wipe_after_delete='True') on iscsi took almost 25 minutes
async task table reported this two assignment as being executed

engine=# SELECT step_id,action_type,task_params_class from async_tasks;
               step_id                | action_type |                     task_params_class                     
--------------------------------------+-------------+-----------------------------------------------------------
 e7c89068-df9d-4ff4-ac63-8d6e6d9bed98 |         230 | org.ovirt.engine.core.common.action.RemoveImageParameters
 c961cc72-ae3d-4d03-9463-6750e28f8228 |         230 | org.ovirt.engine.core.common.action.RemoveImageParameters
(2 rows)

lv's were activated and writable

6c65483f-5316-474a-b04b-4cb397a8a870 db7d2a45-45e7-457c-b40f-47670dda811d -wi-ao----  30.00g                                             
  7c163ea3-fe24-435f-a9e1-dcfe9093d2c0 db7d2a45-45e7-457c-b40f-47670dda811d -wi-ao----  30.00g 

and during all this time (25 minuts),UI reported on an unused ISCSI domain(with no disks or vm's on it) with 1G free space(out of 65G)

RFE is needed to help user follow the process of deleting this kind of disk

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Allon Mureinik 2014-07-27 14:48:48 UTC
What's probably needed here is some sort of introspection into VDSM's garbage collection mechanism, once one is introduced (post SPM removal).

Comment 2 Adam Litke 2015-09-08 13:41:31 UTC
Currently we report the total space and free space.  We could add another figure (eg. Total Garbage or Reclaimable) to report in the storage domain details.  This figure could be calculated and updated by engine without any vdsm intervention.

Comment 6 Doron Fediuck 2018-05-21 09:26:50 UTC
Closing old RFEs.
If relevant please re-open and explain why.


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