To go one step further, I'd even have Device Mapper (DM) as it own, major subject, say 355 - (or renumerate and make it 351).
35x Advanced Device Mapper 35x.1 - Advanced LVM (aka DM-LVM2, at least since kernel 2.4+) 35x.2 - Multipath I/O (aka DM-MPIO) 35x.y - Other/Future Device Mapper facilities There are various Device Mapper solutions out there, expanding more every day in the Upstream. As those solutions mature, they can be added. Examples, for starters? - Stratis, which is an Upstream project built around largely DM that adds what a lot of Red Hat installations have long asked for - - the ability to better 'manage' storage. This may catch on with many distributions over time (it's in RHEL8, still trying to get it back ported to RHEL7). - LVM-integrated Raid - - not the old 'dm-raid,' but the newer, but little known, Device Mapper RAID that actually uses the Multi Disk (MD) subsystem to manage the blocks, but the meta-data/"container" is in DM-LVM2. It solves the long-standing, old problem with old 'dm-raid' (which some distros still use for firmware/fake RAID - - yikes!) that cannot rebuild, whereas MD can. Understanding kernel Device Mapper is really what both LVM and MPIO are built around. -- Sent from my Essential PH-1, please excuse any typos Bryan J Smith - http://linkedin.com/in/bjsmith On Mon, Apr 1, 2019, 15:53 Bryan Smith <[email protected]> wrote: > On Mon, Apr 1, 2019, 04:11 Fabian Thorns <[email protected]> wrote: > >> I just wanted to point out that there is an updated version of the >> LPIC-305 objectives draft... The following changes were made compared to >> the initial version of the draft: >> * cLVM was dropped from 352.1 >> > > So, this one is where I'd like to focus on. I don't think we can do > everything that, say RH436, does. But I think there are some very > necessary 'identification/knowledge' (weight 1) that should be included. > > Understand that Cluster LVM (CLVM, and the daemon, clvmd) enables a lot of > multi-host communication, and introduces a lot of extensions. E.g., if you > ever read my work, you'll see I have "vgchange -al[ny]" and "lvchange > -al[ny]". The first thing people ask me is, "what does 'l' mean?" > > There is also the fact that pvmove, among other operations, works > differently for clustered LVM, basically using cluster mirroring. I.e., it > has to mirror an extent as it does a pvmove, then break it after the move, > and that means cluster mirroring is involved. > > Pacemaker is also heavily involved in managing these services as well. > > So, again, I don't know if we need to cover everything, but the concepts > of local v. clustered LVM identification, and what functions of Pacemaker > are used to manage things like the CLVM and the Distributed Lock Manager > (DLM) so people don't mess with them, might be a good > 'identification/knowledge' level weight (1). > > If anything, to save my sanity, as I catch people not realizing what that > little 'c' flag means when they run 'vgs.' > >
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
