mirror of
https://github.com/nxp-imx/linux-imx.git
synced 2025-07-07 18:05:21 +02:00
Revert "ANDROID: dm-bow: remove dm-bow"
This reverts commit dc855f8bdf
.
Support for ext4 for userdata has been restored, so we must also restore
dm-bow
Note that since it was deprecated, a few things have changed at the dm
layer, so there are follow-on patches to fix up all the issues
aosp/3238494 enables checkpoints on ext4 in cuttlefish, get this too
With all the patches in place, run:
launch_cvd \
-userdata_format="ext4" \
--data_policy=always_create --blank_data_image_mb=16000
then run
atest vts_kernel_checkpoint_test
Test: atest vts_kernel_checkpoint_test passes
Bug: 210958368
Change-Id: I06ad3c7870b67080dfd6d72917751b20193a4fd6
Signed-off-by: Paul Lawrence <paullawrence@google.com>
This commit is contained in:
parent
a338a543b3
commit
31c501de4a
99
Documentation/device-mapper/dm-bow.txt
Normal file
99
Documentation/device-mapper/dm-bow.txt
Normal file
|
@ -0,0 +1,99 @@
|
|||
dm_bow (backup on write)
|
||||
========================
|
||||
|
||||
dm_bow is a device mapper driver that uses the free space on a device to back up
|
||||
data that is overwritten. The changes can then be committed by a simple state
|
||||
change, or rolled back by removing the dm_bow device and running a command line
|
||||
utility over the underlying device.
|
||||
|
||||
dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.
|
||||
It is only possible to go from state 0 (initial state) to state 1, and then from
|
||||
state 1 to state 2.
|
||||
|
||||
State 0: dm_bow collects all trims to the device and assumes that these mark
|
||||
free space on the overlying file system that can be safely used. Typically the
|
||||
mount code would create the dm_bow device, mount the file system, call the
|
||||
FITRIM ioctl on the file system then switch to state 1. These trims are not
|
||||
propagated to the underlying device.
|
||||
|
||||
State 1: All writes to the device cause the underlying data to be backed up to
|
||||
the free (trimmed) area as needed in such a way as they can be restored.
|
||||
However, the writes, with one exception, then happen exactly as they would
|
||||
without dm_bow, so the device is always in a good final state. The exception is
|
||||
that sector 0 is used to keep a log of the latest changes, both to indicate that
|
||||
we are in this state and to allow rollback. See below for all details. If there
|
||||
isn't enough free space, writes are failed with -ENOSPC.
|
||||
|
||||
State 2: The transition to state 2 triggers replacing the special sector 0 with
|
||||
the normal sector 0, and the freeing of all state information. dm_bow then
|
||||
becomes a pass-through driver, allowing the device to continue to be used with
|
||||
minimal performance impact.
|
||||
|
||||
Usage
|
||||
=====
|
||||
dm-bow takes one command line parameter, the name of the underlying device.
|
||||
|
||||
dm-bow will typically be used in the following way. dm-bow will be loaded with a
|
||||
suitable underlying device and the resultant device will be mounted. A file
|
||||
system trim will be issued via the FITRIM ioctl, then the device will be
|
||||
switched to state 1. The file system will now be used as normal. At some point,
|
||||
the changes can either be committed by switching to state 2, or rolled back by
|
||||
unmounting the file system, removing the dm-bow device and running the command
|
||||
line utility. Note that rebooting the device will be equivalent to unmounting
|
||||
and removing, but the command line utility must still be run
|
||||
|
||||
Details of operation in state 1
|
||||
===============================
|
||||
|
||||
dm_bow maintains a type for all sectors. A sector can be any of:
|
||||
|
||||
SECTOR0
|
||||
SECTOR0_CURRENT
|
||||
UNCHANGED
|
||||
FREE
|
||||
CHANGED
|
||||
BACKUP
|
||||
|
||||
SECTOR0 is the first sector on the device, and is used to hold the log of
|
||||
changes. This is the one exception.
|
||||
|
||||
SECTOR0_CURRENT is a sector picked from the FREE sectors, and is where reads and
|
||||
writes from the true sector zero are redirected to. Note that like any backup
|
||||
sector, if the sector is written to directly, it must be moved again.
|
||||
|
||||
UNCHANGED means that the sector has not been changed since we entered state 1.
|
||||
Thus if it is written to or trimmed, the contents must first be backed up.
|
||||
|
||||
FREE means that the sector was trimmed in state 0 and has not yet been written
|
||||
to or used for backup. On being written to, a FREE sector is changed to CHANGED.
|
||||
|
||||
CHANGED means that the sector has been modified, and can be further modified
|
||||
without further backup.
|
||||
|
||||
BACKUP means that this is a free sector being used as a backup. On being written
|
||||
to, the contents must first be backed up again.
|
||||
|
||||
All backup operations are logged to the first sector. The log sector has the
|
||||
format:
|
||||
--------------------------------------------------------
|
||||
| Magic | Count | Sequence | Log entry | Log entry | …
|
||||
--------------------------------------------------------
|
||||
|
||||
Magic is a magic number. Count is the number of log entries. Sequence is 0
|
||||
initially. A log entry is
|
||||
|
||||
-----------------------------------
|
||||
| Source | Dest | Size | Checksum |
|
||||
-----------------------------------
|
||||
|
||||
When SECTOR0 is full, the log sector is backed up and another empty log sector
|
||||
created with sequence number one higher. The first entry in any log entry with
|
||||
sequence > 0 therefore must be the log of the backing up of the previous log
|
||||
sector. Note that sequence is not strictly needed, but is a useful sanity check
|
||||
and potentially limits the time spent trying to restore a corrupted snapshot.
|
||||
|
||||
On entering state 1, dm_bow has a list of free sectors. All other sectors are
|
||||
unchanged. Sector0_current is selected from the free sectors and the contents of
|
||||
sector 0 are copied there. The sector 0 is backed up, which triggers the first
|
||||
log entry to be written.
|
||||
|
|
@ -348,6 +348,7 @@ CONFIG_DM_SNAPSHOT=y
|
|||
CONFIG_DM_UEVENT=y
|
||||
CONFIG_DM_VERITY=y
|
||||
CONFIG_DM_VERITY_FEC=y
|
||||
CONFIG_DM_BOW=y
|
||||
CONFIG_NETDEVICES=y
|
||||
CONFIG_DUMMY=y
|
||||
CONFIG_WIREGUARD=y
|
||||
|
|
|
@ -328,6 +328,7 @@ CONFIG_DM_SNAPSHOT=y
|
|||
CONFIG_DM_UEVENT=y
|
||||
CONFIG_DM_VERITY=y
|
||||
CONFIG_DM_VERITY_FEC=y
|
||||
CONFIG_DM_BOW=y
|
||||
CONFIG_NETDEVICES=y
|
||||
CONFIG_DUMMY=y
|
||||
CONFIG_WIREGUARD=y
|
||||
|
|
|
@ -689,6 +689,18 @@ config DM_AUDIT
|
|||
Enables audit logging of several security relevant events in the
|
||||
particular device-mapper targets, especially the integrity target.
|
||||
|
||||
config DM_BOW
|
||||
tristate "Backup block device"
|
||||
depends on BLK_DEV_DM
|
||||
select DM_BUFIO
|
||||
help
|
||||
This device-mapper target takes a device and keeps a log of all
|
||||
changes using free blocks identified by issuing a trim command.
|
||||
This can then be restored by running a command line utility,
|
||||
or committed by simply replacing the target.
|
||||
|
||||
If unsure, say N.
|
||||
|
||||
config DM_USER
|
||||
tristate "Block device in userspace"
|
||||
depends on BLK_DEV_DM
|
||||
|
|
|
@ -85,6 +85,7 @@ obj-$(CONFIG_DM_INTEGRITY) += dm-integrity.o
|
|||
obj-$(CONFIG_DM_ZONED) += dm-zoned.o
|
||||
obj-$(CONFIG_DM_WRITECACHE) += dm-writecache.o
|
||||
obj-$(CONFIG_SECURITY_LOADPIN_VERITY) += dm-verity-loadpin.o
|
||||
obj-$(CONFIG_DM_BOW) += dm-bow.o
|
||||
obj-$(CONFIG_DM_USER) += dm-user.o
|
||||
|
||||
ifeq ($(CONFIG_DM_INIT),y)
|
||||
|
|
1301
drivers/md/dm-bow.c
Normal file
1301
drivers/md/dm-bow.c
Normal file
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user