RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1572640 - vdo create --force overwrites existing vdo using same device
Summary: vdo create --force overwrites existing vdo using same device
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vdo
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Joe Shimkus
QA Contact: Jakub Krysl
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-27 13:35 UTC by Joe Shimkus
Modified: 2019-03-06 01:25 UTC (History)
6 users (show)

Fixed In Version: 6.1.1.115
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 09:39:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3094 0 None None None 2018-10-30 09:40:09 UTC

Description Joe Shimkus 2018-04-27 13:35:01 UTC
Description of problem:
After creating a vdo on a particular device creating another vdo on the same device using the --force option overwrites the existing vdo.

How reproducible:
100%

Steps to Reproduce:
1. vdo create --device=/dev/dm-0 --name=vdo0
2. vdo create --device=/dev/dm-0 --name=vdo1 --force

Actual results:
Second create succeeds.  Multiple configuration entries referencing the device.

Expected results:
Rejection of the second create as the vdo configuration indicates there already exists a vdo using the device.

Additional info:
My interpretation of the addition of the --force option to create is that it was added to handle the situation where a device was left with vdo layout cruft such that the attempt to format it would be rejected.  That is a reasonable use case.

When, however, there exists in the configuration the indication that a device is in use for a particular vdo any subsequent attempt to create a new vdo using that device should be rejected regardless of --force.  

The situation where the configuration is in error (due to some other failure scenario) can be rectified by performing 'vdo remove --name=<name> --force'.  A subsequent create using the device in question will then succeed.

Comment 2 Jakub Krysl 2018-05-03 07:59:18 UTC
I always though '--force' is a flag to say: "I know what I am doing, let me shot myself".
Even manpage says VDO should overwrite existing formatted VDO volume with '--force'.
create Creates a VDO volume and its associated index and makes it available. If --activate=disabled is specified the VDO volume is created but not made available. Will not overwrite an existing file system or formatted VDO volume unless --force is given.

What happens if you create a VDO, remove the disk, remove the VDO with --force, reattach the disk and try to create a new VDO on it? There would still be all VDO data and '--force' will not work with this change, so user will have to use stuff like dd. Is my assumption correct here?

Comment 3 Joe Shimkus 2018-05-03 11:22:32 UTC
If --force is interpreted as "let me shot[sic] myself" then there's a bug in vdo manager in not removing the existing configuration referencing the device, unless we agree that is acceptable as part of shooting oneself; which I think is incorrect.

As to the question related to removing the disk, etc. that will successfully work with --force.  It's the presence of an existing entry in the config file referencing the device that overrides the effect of --force.  If there is no referencing entry, --force would act to allow the reuse of the device.

Comment 4 Joe Shimkus 2018-05-03 11:25:23 UTC
P.S. This issue gives more support to getting rid of the config file (or, until such time, making it non-specifiable) to avoid the cross-config file scenario of this issue.

Comment 6 Jakub Krysl 2018-07-09 11:35:40 UTC
# vdo create --name vdo --device /dev/sdb
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 0 volume is ready at /dev/mapper/vdo
# vdo create --name vdo --device /dev/sdb --verbose
Creating VDO vdo
vdo: ERROR - VDO volume vdo already exists
# vdo create --name vdo2 --device /dev/sdb --verbose
Creating VDO vdo2
vdo: ERROR - Device /dev/sdb already configured for VDO use
# vdo create --name vdo2 --device /dev/sdb --verbose --force
Creating VDO vdo2
vdo: ERROR - Device /dev/sdb already configured for VDO use

So VDO no longer allows overwriting VDO device with another VDO using --force. But there is still sentence in vdo manpage that suggests it should be able to do it:
'Will not overwrite an existing filesystem or formatted VDO volume unless --force is given.'

Can you please fix it in this BZ or should I create a new one?

Comment 7 Joe Shimkus 2018-07-09 14:37:10 UTC
I don't see the need for a new BZ; it should have been addressed as part of this one.
Send it back.

Comment 8 Joe Shimkus 2018-07-10 12:39:07 UTC
Updated man page.

Comment 9 Jakub Krysl 2018-07-23 11:54:56 UTC
Giving back as per discussion to more clearly state that using --force will not work if VDO is already running on the device (checked in /etc/vdoconf.yml)

Comment 10 Joe Shimkus 2018-07-23 19:27:40 UTC
Alright...everyone's supposedly happy with the man page as just changed (at least in relation to this question :-)).  It now specifies that for an 'in use' device (config file contains a vdo using the device) that even --force will not make us use it.

Comment 11 Jakub Krysl 2018-08-23 12:55:44 UTC
man vdo:
"If the specified device is already in use by a VDO volume (as determined from the configuration file) the create will always be rejected, even if --force is specified.  If the device  is  not so in use but is formatted as a VDO volume or contains an existing file system the create will be rejected unless --force is given."

# vdo create --name vdo --device /dev/sda
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 1 volume is ready at /dev/mapper/vdo

# vdo create --name vdo1 --device /dev/sda                                                                                                                                                   
Creating VDO vdo1
vdo: ERROR - Device /dev/sda already configured for VDO use

# vdo create --name vdo1 --device /dev/sda --force
Creating VDO vdo1
vdo: ERROR - Device /dev/sda already configured for VDO use

Comment 13 errata-xmlrpc 2018-10-30 09:39:31 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:3094


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