Hide Forgot
Allow LVM to utilize dm-cache (or other in-kernel caching implementations) to create logical volumes that are hierarchical in nature, with a small fast device performing as a cache to larger slower device or devices. This bug shall cover the minimum requirements: 1) Be able to create a cache LV. 2) Be able to remove a cache LV 3) Be able to convert an existing LV to a cached LV 4) Be able to display via 'lvs' the type and characteristics of cache type LVs 5) Be able to rename cache type LVs 6) Man page updates for the above The following restrictions apply to this bug. 1) Any cache mode beyond 'writethrough' will be a separate bug. 2) Any cache policy other than default will be a separate bug. 3) Changing either cache mode or policy without removing and recreating the cache will be a separate bug. 4) Changing the size of the cache w/o removing and recreating the cache will be a separate bug.
Pull request: -3) Be able to convert an existing LV to a cached LV +3a) Be able to convert an existing LV to a cached LV +3b) and back to non-cached LV
We are planning for this to be a Tech. Preview in 7.0.
Would it also help to add that the following commands are not currently allowed on cache logical volumes: - pvmove: will skip over any cache LVs - lvresize/lvreduce/lvextend: cache LVs cannot be resized currently - vgsplit: splitting a VG is not allowed when cache LVs exist in it
Absolutely. Both the book and the doc text field are updated. Thank you!
This doesn't appear to be in the latest lvm rpms. 3.10.0-90.el7.x86_64 lvm2-2.02.105-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 lvm2-libs-2.02.105-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 lvm2-cluster-2.02.105-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 device-mapper-1.02.84-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 device-mapper-libs-1.02.84-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 device-mapper-event-1.02.84-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 device-mapper-event-libs-1.02.84-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 device-mapper-persistent-data-0.2.8-4.el7 BUILT: Fri Jan 24 14:28:55 CST 2014 cmirror-2.02.105-8.el7 BUILT: Thu Feb 27 07:35:52 CST 2014 [root@harding-03 ~]# lvcreate -L 10G -n OriginLV VG /dev/sdb1 Logical volume "OriginLV" created [root@harding-03 ~]# lvcreate -L 1G -n CacheDataLV VG /dev/sdb2 Logical volume "CacheDataLV" created [root@harding-03 ~]# lvcreate -L 10M -n CacheMetaLV VG /dev/sdb2 Rounding up size to full physical extent 12.00 MiB Logical volume "CacheMetaLV" created [root@harding-03 ~]# lvconvert --type cache-pool --poolmetadata VG/CacheMetaLV VG/CacheDataLV WARNING: Unrecognised segment type cache-pool [root@harding-03 ~]# lvconvert --type cache --cachepool VG/CachePoolLV VG/OriginLV WARNING: Unrecognised segment type cache [root@harding-03 ~]# lvcreate --type cache-pool -L 1G -n my_lv_cachepool VG /dev/sdb7 WARNING: Unrecognised segment type cache-pool Unable to create LV with unknown segment type cache-pool. Run `lvcreate --help' for more information. [root@harding-03 ~]# lvcreate --type cache -L 1G -n my_lv_cachepool VG /dev/sdb7 WARNING: Unrecognised segment type cache Unable to create LV with unknown segment type cache. Run `lvcreate --help' for more information. [root@harding-03 ~]# lsmod | grep cache dm_cache 43291 0 dm_persistent_data 61844 1 dm_cache dm_bio_prison 15501 1 dm_cache dm_mod 102999 22 dm_log,dm_persistent_data,dm_mirror,dm_cache,dm_bufio
Was '--with-cache=internal' used to configure?
(In reply to Jonathan Earl Brassow from comment #15) > Was '--with-cache=internal' used to configure? Sigh. Nope, will need to add that!
Should be ready now: lvm2-2.02.105-9.el7.
*** Bug 984716 has been marked as a duplicate of this bug. ***
Marking verified (SanityOnly). Cache testing and cache test development is still ongoing, however the basic test cases for tech preview listed in comment #0 pass with the only current issue found being bug 1086426. Also, the ability to convert a cached LV back to a "normal" LV is not documented anywhere in the man page, so I'm not sure how that is supposed to happen. 3.10.0-116.el7.x86_64 lvm2-2.02.105-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 lvm2-libs-2.02.105-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 lvm2-cluster-2.02.105-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 device-mapper-1.02.84-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 device-mapper-libs-1.02.84-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 device-mapper-event-1.02.84-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 device-mapper-event-libs-1.02.84-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014 device-mapper-persistent-data-0.3.0-1.el7 BUILT: Fri Mar 28 07:42:24 CDT 2014 cmirror-2.02.105-14.el7 BUILT: Wed Mar 26 08:29:41 CDT 2014
(In reply to Corey Marthaler from comment #19) > Also, the ability to convert a cached LV back to a "normal" LV is not > documented anywhere in the man page, so I'm not sure how that is supposed to > happen. See `man 8 lvm`: Removing Cache Logical Volumes If you wish to remove all logical volumes associated with a cache LV, you must remove both top-level, user-visible devices. The cache meta‐ data LV and cache data LV cannot be removed directly. If only the cache pool LV is specfied for removal, any cached blocks not yet on the origin LV will be flush, the cache pool LV will be removed, and the now un-cached origin LV will remain. If the user specifies a cache LV for removal, then the origin LV is removed and only the cache pool LV will remain. The cache pool LV can then be used to create another cache LV with a different origin LV if desired. When users intend to remove all logical volumes associated with a cache LV, it is generally better to start with the origin LV and then remove the cache pool LV. If the operations are performed in the reverse order, the user will have to wait for the contents of the cache pool LV to be flushed before the origin LV is removed. This could take some time.
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.