As always ... when in doubt, I'd put the primary (not necessarily the sole, but primary) focus on any toolchain that leverage the kernel's own facilities, with few exceptions. [1]
In the case of anything storage, that means the kernel's (version 2.6+) inherent, 0 overhead, DeviceMapper facility that maps storage allocations. I.e., even partitions are a map, so whether it's a partition, a Logical Volume of Physical Extents in Logical Volume Manager v2 (DM-LVM2), a Device Mapper Multipath I/O (DM-MPIO), etc..., it's the same, wire/storage-speed. [2] So we're talking knowledge of the cryptsetup command for dm-setup, which includes LUKS. And that means more than just identification, but also setup, mount, including boot-time static mount, changing the passphrase, maybe even order and commands when extending atop of LVM, etc... Anything else should be justified based on popularity, although identification requires the least justification (and corresponding weight). As always ... just my very opinionated view. ;) -- bjs [1] In storage, one exception would be to include mdadm and dmraid, given the latter does not often have rebuild capabilities. The disadvantage of mdadm is that not all Fake RAID vendors have assisted in implementation of their rebuild algorithm (only Intel, SNIA standard, and a few other meta-data formats), so DeviceMapper-based storage organization (without rebuid) is the only option for many (especially legacy). There are some newer solutions for DeviceMapper-based RAID in DM-LVM2, whereby the LVM meta-data holds the container (SNIA standard meta-data I think, I need to check), which then leverages mdadm for rebuild. I.e., DM-LVM2 based mapping, access, etc..., while using mdadm userspace for rebuild. But those are not compatible with most Fake RAID vendors. [2] Wire/storage-speed is the case with kernel 2.6+ DeviceMapper-based solutions, not to be confused with non-kernel/non-DeviceMapper fuctions in earlier kernels (e.g., kernel 2.4-era LVM v1, which _did_ have overhead). The only time it's not wire/storage-speed is when other features are being called to support added functionality. E.g., DM-LVM2 copy-on-write (snapshots) require additional overhead, userspace calls to check paths are up in DM-MPIO can be overhead (unless there is some off-load/auto-reporting by the SAN infrastructure, long story), etc... But the access to storage areas does not incur any overhead, despite popular myth (from the pre-DM days of LVM v1). On Wed, Jul 8, 2015 at 6:57 AM, Martin Møller Skarbiniks Pedersen <[email protected]> wrote: > Hi, > > The current objective 203.3 under "Key Knowledge Areas" says: > Basic feature knowledge of encrypted filesystems. > > I think that is too weak because nothing is mention under "Term and > Utilities" and > currently these very different filesystems ext4, fsf2,zfs, ntfs, encfs, > ecryptfs, dm-crypt (luks) all > supports encryption, but still have a lot of different features. > > Maybe this objective should focus on encfs and luks encryption under "Term > and Utilities" ? > > Regards > Martin M. S. Pedersen > Instructor at SuperUsers A/S, Denmark > > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev -- -- Bryan J Smith - http://www.linkedin.com/in/bjsmith _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
