Hide Forgot
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:
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