Documentation/admin-guide/device-mapper/dm-init.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/device-mapper/dm-init.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/device-mapper/dm-init.rst
Extension
.rst
Size
4724 bytes
Lines
134
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

================================
Early creation of mapped devices
================================

It is possible to configure a device-mapper device to act as the root device for
your system in two ways.

The first is to build an initial ramdisk which boots to a minimal userspace
which configures the device, then pivot_root(8) in to it.

The second is to create one or more device-mappers using the module parameter
"dm-mod.create=" through the kernel boot command line argument.

The format is specified as a string of data separated by commas and optionally
semi-colons, where:

 - a comma is used to separate fields like name, uuid, flags and table
   (specifies one device)
 - a semi-colon is used to separate devices.

So the format will look like this::

 dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]

Where::

	<name>		::= The device name.
	<uuid>		::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
	<minor>		::= The device minor number | ""
	<flags>		::= "ro" | "rw"
	<table>		::= <start_sector> <num_sectors> <target_type> <target_args>
	<target_type>	::= "verity" | "linear" | ... (see list below)

The dm line should be equivalent to the one used by the dmsetup tool with the
`--concise` argument.

Target types
============

Not all target types are available as there are serious risks in allowing
activation of certain DM targets without first using userspace tools to check
the validity of associated metadata.

======================= =======================================================
`cache`			constrained, userspace should verify cache device
`crypt`			allowed
`delay`			allowed
`era`			constrained, userspace should verify metadata device
`flakey`		constrained, meant for test
`linear`		allowed
`log-writes`		constrained, userspace should verify metadata device
`mirror`		constrained, userspace should verify main/mirror device
`raid`			constrained, userspace should verify metadata device
`snapshot`		constrained, userspace should verify src/dst device
`snapshot-origin`	allowed
`snapshot-merge`	constrained, userspace should verify src/dst device
`striped`		allowed
`switch`		constrained, userspace should verify dev path
`thin`			constrained, requires dm target message from userspace
`thin-pool`		constrained, requires dm target message from userspace
`verity`		allowed
`writecache`		constrained, userspace should verify cache device
`zero`			constrained, not meant for rootfs
======================= =======================================================

If the target is not listed above, it is constrained by default (not tested).

Examples
========
An example of booting to a linear array made up of user-mode linux block

Annotation

Implementation Notes