Bug 1540619
| Summary: | VDO should use a persistent name for backing device | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jakub Krysl <jkrysl> |
| Component: | vdo | Assignee: | Ken Raeburn <raeburn> |
| Status: | CLOSED ERRATA | QA Contact: | Jakub Krysl <jkrysl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.5 | CC: | awalsh, bgurney, coughlan, jkrysl, lherbolt, limershe, lmiksik, mvollmer, raeburn, rhandlin |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 6.1.1.83 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 09:38:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
It is possible for the user to specify the persistent identifier at creation time. Here's an example of me creating a VDO volume with the persistent identifier pointing to /dev/nvme0n1:
# vdo create --name=vdo1 --device=/dev/disk/by-id/nvme-nvme.8086-50484d42373432363030473234383044474e-494e54454c2053534450454431443438304741-00000001 --vdoLogicalSize=4T
Creating VDO vdo1
Starting VDO vdo1
Starting compression on VDO vdo1
VDO instance 2 volume is ready at /dev/mapper/vdo1
# cat /etc/vdoconf.yml
####################################################################
# THIS FILE IS MACHINE GENERATED. DO NOT EDIT THIS FILE BY HAND.
####################################################################
config: !Configuration
vdos:
vdo1: !VDOService
_operationState: finished
ackThreads: 1
activated: enabled
bioRotationInterval: 64
bioThreads: 4
blockMapCacheSize: 128M
blockMapPeriod: 16380
compression: enabled
cpuThreads: 2
deduplication: enabled
device: /dev/disk/by-id/nvme-nvme.8086-50484d42373432363030473234383044474e-494e54454c2053534450454431443438304741-00000001
hashZoneThreads: 1
indexCfreq: 0
indexMemory: 0.25
indexSparse: disabled
indexThreads: 0
logicalBlockSize: 4096
logicalSize: 4T
logicalThreads: 1
name: vdo1
physicalSize: 468851544K
physicalThreads: 1
readCache: disabled
readCacheSize: 0M
slabSize: 2G
writePolicy: sync
version: 538380551
I assume the VDO UUID and blkid changes haven't propagated enough by this point for us to be able to just point to /dev/disk/by-uuid/a1b2c3d4-5678-... as the storage device, identifying it by the UUID in the label we put there ourselves... I think that's probably the right thing down the road, but the support isn't quite there yet. What does "propagated enough" mean? Included in RHEL 7.5; publicly released if we care about people testing VDO from GitHub being able to use it; deployed on our testing machines (which AFAIK are still RHEL 7.4). I could implement it using the VDO UUID with a fallback in case blkid doesn't recognize VDO volumes, but automated testing would then require that we have some test machines with the blkid support and some without. If the new blkid is in 7.5, and we can deploy it to the test machines, maybe we can get away without the fallback path, which will keep things simpler. (In reply to Ken Raeburn from comment #5) > If the new blkid is in 7.5, and we can deploy it to the test machines, maybe > we can get away without the fallback path, which will keep things simpler. It is in 7.5. [root@75Beta ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 19G 0 part ├─rhel-root 253:0 0 17G 0 lvm / └─rhel-swap 253:1 0 2G 0 lvm [SWAP] vdb 252:16 0 20G 0 disk └─vdo0 253:2 0 16G 0 vdo [root@75Beta ~]# dmsetup info vdo0 Name: vdo0 State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 0 Event number: 0 Major, minor: 253, 2 Number of targets: 1 UUID: VDO-161d5026-c2b6-42cd-9f46-2b34ebf93e3c [root@75Beta ~]# ls -l /dev/disk/by-uuid/161d5026-c2b6-42cd-9f46-2b34ebf93e3c lrwxrwxrwx. 1 root root 9 Feb 1 20:21 /dev/disk/by-uuid/161d5026-c2b6-42cd-9f46-2b34ebf93e3c -> ../../vdb Product Management has reviewed and declined this request. You may appeal this decision by reopening this request. *** Bug 1547090 has been marked as a duplicate of this bug. *** Reproducer from duplicate BZ 1547090: # vdo create --name vdo0 --device /dev/vgroup0/lvol0 # lvrename vgroup lvol0 lvol1 (/dev/mapper/vdo0 keeps working) # vdo stop --name vdo0 # vdo start --name vdo0 Starting VDO vdo0 vdo: ERROR - Could not set up device mapper for vdo0 vdo: ERROR - vdodumpconfig: Failed to make FileLayer from '/dev/vgroup0/lvol0' with No such file or directory I think a warning in the 7.5 documentation along the lines: "if you use a non-persistent device name, then VDO may fail to startup properly in the future if the device name changes. It is recommended that you use a persistent device name." With an example. (If you agree, open a new BZ against the Storage Admin. Guide.) Out of curiosity, in the longer-term (7.6+), will you accept whatever device name the user enters, and replace it in the config file with the VDO UUID? Whatever the change in behavior in 7.6, it may need to be documented. Do we also need to tell people how to check, and repair, their old config file? (Probably appropriate in a kbase, for CEE.) Tom Yes, I think that sounds good. I will open a BZ against the storage admin guide, And yes, I believe the intent is to end up allowing both a device and a UUID in the configuration, to allow for backwards compatibility. We generally advise that it is super dangerous to hand-edit the config file, but there are a couple of situations where it is necessary. This is one of those. (In reply to Andy Walsh from comment #16) > And yes, I believe the intent is to end up allowing both a device and a UUID > in the configuration, to allow for backwards compatibility. And if the user provides a non-persistent device name, will you convert it to a UUID before writing it to the config. file? (Perhaps with a message displayed, indicating that the conversion has been done, and why?) (I have no idea whether this is appropriate or feasible in this context, but it seems quite important to me to avoid non-persistent device names in the config. file.) Tom Tested on:
RHEL-7.6-20180626.0
kernel-3.10.0-915.el7
kmod-vdo-6.1.1.99-1.el7
vdo-6.1.1.99-2.el7
# vdo create --name vdo --device /dev/mapper/vg-lv0 --verbose
Creating VDO vdo
grep MemAvailable /proc/meminfo
pvcreate -qq --test /dev/mapper/vg-lv0
modprobe kvdo
vdoformat --uds-checkpoint-frequency=0 --uds-memory-size=0.25 /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
vdodumpconfig /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
Starting VDO vdo
dmsetup status vdo
grep MemAvailable /proc/meminfo
modprobe kvdo
vdodumpconfig /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
dmsetup create vdo --uuid VDO-07e1894c-6327-40fb-b8d2-a2944c38f4e2 --table '0 4278400280 vdo /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum 4096 disabled 0 32768 16380 on auto vdo ack=1,bio=4,bioRotationInterval=64,cpu=2,hash=1,logical=1,physical=1'
dmsetup status vdo
Starting compression on VDO vdo
dmsetup message vdo 0 compression on
dmsetup status vdo
VDO instance 4 volume is ready at /dev/mapper/vdo
# lvrename vg lv0 lv1
Renamed "lv0" to "lv1" in volume group "vg"
# vdo stop --name vdo
Stopping VDO vdo
# vdo start --name vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 5 volume is ready at /dev/mapper/vdo
/var/log/messages:
[165080.993051] kvdo4:dmsetup: starting device 'vdo'
[165081.017817] kvdo4:dmsetup: underlying device, REQ_FLUSH: not supported, REQ_FUA: not supported
[165081.060621] kvdo4:dmsetup: Using write policy sync automatically.
[165081.088289] kvdo4:dmsetup: zones: 1 logical, 1 physical, 1 hash; base threads: 5
[165081.297119] kvdo4:journalQ: VDO commencing normal operation
[165081.322760] kvdo4:dmsetup: uds: kvdo4:dedupeQ: creating index: dev=/dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum offset=4096 size=2781704192
uds: kvdo4:dedupeQ: Using 6 indexing zones for concurrency.
[165081.421903] Setting UDS index target state to online
[165081.445848] kvdo4:dmsetup: device 'vdo' started
[165081.466724] kvdo4:dmsetup: resuming device 'vdo'
[165081.487901] kvdo4:dmsetup: device 'vdo' resumed
[165081.528959] kvdo4:packerQ: compression is enabled
[165110.624257] kvdo4:dmsetup: suspending device 'vdo'
[165110.649965] kvdo4:dmsetup: device 'vdo' suspended
[165110.675696] kvdo4:dmsetup: stopping device 'vdo'
[165110.699564] kvdo4:dmsetup: uds: kvdo4:dedupeQ: index_0: beginning save (vcn 4294967295)
[165110.736062] Setting UDS index target state to closed
[165110.953293] kvdo4:dmsetup: device 'vdo' stopped
[165116.217691] kvdo5:dmsetup: starting device 'vdo'
[165116.240626] kvdo5:dmsetup: underlying device, REQ_FLUSH: not supported, REQ_FUA: not supported
[165116.285253] kvdo5:dmsetup: Using write policy sync automatically.
[165116.314339] kvdo5:dmsetup: zones: 1 logical, 1 physical, 1 hash; base threads: 5
[165116.539228] kvdo5:journalQ: VDO commencing normal operation
[165116.565959] kvdo5:dmsetup: uds: kvdo5:dedupeQ: loading or rebuilding index: dev=/dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum offset=4096 size=2781704192
uds: kvdo5:dedupeQ: Using 6 indexing zones for concurrency.
[165116.674778] Setting UDS index target state to online
[165116.699149] kvdo5:dmsetup: device 'vdo' started
[165116.720776] kvdo5:dmsetup: resuming device 'vdo'
[165116.742984] kvdo5:dmsetup: device 'vdo' resumed
[165116.790438] uds: kvdo5:dedupeQ: kvdo5:packerQ: compression is enabled
[165116.821317] read index page map, last update 0
[165116.843876] uds: kvdo5:dedupeQ: index_0: loaded index from chapter 0 through chapter 0
# cat /etc/vdoconf.yml
####################################################################
# THIS FILE IS MACHINE GENERATED. DO NOT EDIT THIS FILE BY HAND.
####################################################################
config: !Configuration
vdos:
vdo: !VDOService
_operationState: finished
ackThreads: 1
activated: enabled
bioRotationInterval: 64
bioThreads: 4
blockMapCacheSize: 128M
blockMapPeriod: 16380
compression: enabled
cpuThreads: 2
deduplication: enabled
device: /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
hashZoneThreads: 1
indexCfreq: 0
indexMemory: 0.25
indexSparse: disabled
indexThreads: 0
logicalBlockSize: 4096
logicalSize: 2139200140K
logicalThreads: 1
name: vdo
physicalSize: 2097164M
physicalThreads: 1
readCache: disabled
readCacheSize: 0M
slabSize: 2G
writePolicy: auto
version: 538380551
VDO now uses more persistent name by finding the /dev/disk/by-id and operating with that name.
note: other from /dev/disk/by-* work too:
# vdo create --name vdo --device /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 6 volume is ready at /dev/mapper/vdo
# vdo create --name vdo --device /dev/disk/by-path/ip-10.37.151.6\:3260-iscsi-iqn.2001-05.com.equallogic\:0-af1ff6-6db5d9bd9-f7c9f42596f59bfb-vdo-general-lun-0
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 7 volume is ready at /dev/mapper/vdo
*** Bug 1612781 has been marked as a duplicate of this bug. *** 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 |
Description of problem: VDO now uses path given by uses to identify the device. This path is usually something like '/dev/sdc'. This gets saved in '/etc/vdoconf.yml' nad from here it is used to identify the device. This is not the best idea as this path ('/dev/sdc') can change after reboot. VDO should use more persistent identifier, one from '/dev/disk/*/'. Version-Release number of selected component (if applicable): vdo-6.1.0.124-14 How reproducible: 100% Steps to Reproduce: 1. vdo create --name vdo --device /dev/sdc 2. cat /etc/vdoconf.yml Actual results: # cat /etc/vdoconf.yml #################################################################### # THIS FILE IS MACHINE GENERATED. DO NOT EDIT THIS FILE BY HAND. #################################################################### config: !Configuration vdos: vdo: !VDOService _operationState: finished ackThreads: 1 activated: enabled bioRotationInterval: 64 bioThreads: 4 blockMapCacheSize: 128M blockMapPeriod: 16380 compression: enabled cpuThreads: 2 deduplication: enabled device: /dev/sdc hashZoneThreads: 1 indexCfreq: 0 indexMemory: 0.25 indexSparse: disabled indexThreads: 0 logicalBlockSize: 4096 logicalSize: 5846172208K logicalThreads: 1 name: vdo physicalSize: 5860522584K physicalThreads: 1 readCache: disabled readCacheSize: 0M slabSize: 2G writePolicy: auto version: 538380551 Expected results: # cat /etc/vdoconf.yml --snip-- device: /dev/disk/by-id/ata-ST6000NM0024-1HT17Z_S4D0CGX9 --snip-- Additional info: