Description of problem: I tested this both on versions 2.03.05 and 2.03.06(2)-git (latest from git repo) and I get the same result. LVM2 is built with internal writecache support: ---------- $ sudo lvconvert --version LVM version: 2.03.06(2)-git (2019-06-15) Library version: 1.02.165-git (2019-06-15) Driver version: 4.39.0 Configuration: ./configure --with-writecache=internal ---------- And when I try to enable writecache (per lvmcache(7) instructions), I get the following output: ---------- $ sudo lvconvert --type writecache --cachepool fast vg-cache/slow-2 Command does not accept option: --type writecache. ---------- My LVs/VG are as follows: ---------- $ sudo lvs vg-cache -o+devices LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices fast vg-cache -wi-a----- 10.00g /dev/nvme0n1(0) slow vg-cache -wi-a----- 5.93t /dev/sda(0) slow-2 vg-cache -wi-a----- <37.27g /dev/sdd(0) ---------- Version-Release number of selected component (if applicable): 2.03.05 and 2.03.06(2)-git and using a Linux 5.0+ kernel. How reproducible: 100%. Every time. Steps to Reproduce: 1. Create a VG consisting of two or more PVs. 2. Create an LV from a faster PV (i.e. SSD). 3. Create an LV from a slower PV (i.e. HDD). 4. lvconvert the two LVs into a writecache cachepool LV. Actual results: A writecache volume is not created. Expected results: A writecache volume should be created. Additional info: ---------- Here is the excerpt from lvmcache(7): or dm-writecache: $ lvconvert --type writecache --cachepool fast vg/main
Hi ATM --type writecache works with --cachevol only. --type cache work with --cachepool & --cachevol So it works as currently designed as there are some difference between them... But clearly it is somewhat confusing for users.
Zdenek, Hello and thank you very much for the quick reply. If that is indeed the case, then the "bug" should be to update the documentation (e.g. the manpage) to reflect that inconsistency. Thank you. I did notice however, and I can easily open a new bug for it (unless this is as designed) but when I run direct I/O via fio, the cache volume seems to not support the opening of the file descriptor with O_DIRECT. Thoughts?
(In reply to Petros Koutoupis from comment #2) > Zdenek, > > Hello and thank you very much for the quick reply. If that is indeed the > case, then the "bug" should be to update the documentation (e.g. the > manpage) to reflect that inconsistency. Thank you. > > I did notice however, and I can easily open a new bug for it (unless this is > as designed) but when I run direct I/O via fio, the cache volume seems to > not support the opening of the file descriptor with O_DIRECT. Thoughts? Forget about this last comment. This was my fault. I didn't realize that I never reactivated the logical volume and therefore was writing to a file on top of devfs. I figured it out. O_DIRECT works just fine.
so the confusion seems to come in when using: "--type writecache --cachepool fast" instead of: "--type writecache --cachevol fast" perhaps some improvements to the warning message...
The generic command matching code matches what the user types to a particular command definition (syntax). lvm does not know what the actual command is at that stage (that's what it's trying to figure out), so it can't just look for particular option mix ups like this. What it should do is recognize similar commands and recommend the closest command definition to what the user typed. Some poorly defined commands throw a wrench into the command matching code because they end up matching many syntax errors for other commands. The unfortunate "match" prevents lvm from making a helpful suggestion because the command fails at the point where it looks at unaccepted options set by the user rather than failing when looking for required options. A good command definition will have a unique, unambiguous combination of command name, required option name(s) and position args. In this case, the command being typed is successfully matching this command definition (which is a bad command because it has nothing unique about it, and actually has different meanings in different cases): $ lvconvert --cachepool LV The command typed by the user matches all the required parameters for that command definition. Once lvm matches that command definition, it then sees that "--type writecache" is not one of the accepted optional parameters, so it fails with the correct message that the option is not accepted. I've fixed this in the command-matching code by treating '--type' specially, since it is generally a more important/definitive option than others. Now, if the user specifies '--type foo' (which is the recommended form of most commands), then only the command defs with a matching '--type foo' will be considered. This prevents lvm from matching successfully based on other less important options. It should generally result in better error messages like we do now with this command: $ lvconvert --type writecache --cachepool fast foo/main No command with matching syntax recognised. Run 'lvconvert --help' for more information. Nearest similar command has syntax: lvconvert --type writecache --cachevol LV LV_linear_striped_raid Attach a writecache to an LV, converts the LV to type writecache. pushed to master https://sourceware.org/git/?p=lvm2.git;a=commit;h=570676488516b60ea3132b5010e7aef5d5cb1549
David, this is wonderful. There should also be a correction in the man page lvmcache(7) where: ---------- or dm-writecache: $ lvconvert --type writecache --cachepool fast vg/main ---------- Should instead read: ---------- or dm-writecache: $ lvconvert --type writecache --cachevol fast vg/main ---------- Alongside anything else referencing dm-writecache. Again, thank you for the quick replies and the quick patching.