[dm-devel] DM_snapshot_cow filesystem (dmsetup create snapshot)

Fri Dec 2 17:42:54 UTC 2011

On Fri, Dec 2, 2011 at 3:46 AM, Alasdair G Kergon <agk at redhat.com> wrote:

> On Thu, Dec 01, 2011 at 09:44:53PM -0600, Douglas McClendon wrote:
> > The commandline to do the 'edit' was requested for users like Fred, and
> > because I guess one day I might find myself wanting to do the same.
>
> This is unsupported, but if you want to try:
> You need to flip the 5th byte of the 'cow' device from 0 to 1 (when
> the snapshot is not active).  (But you might have lost the most recent
> changes if they weren't flushed out when it filled up.)
>
> Something like this:
>
> # lvs
>  LV    VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
>  lvol0 vg2  owi-a- 10.00m
>  lvol1 vg2  Swi-I- 10.00m lvol0  100.00
>
> # dmsetup table vg2-lvol1-cow
> 0 20480 linear 7:0 22528
>
> # lvchange -an vg2/lvol0
>
> # dmsetup create tmp-vg2-lvol1-cow --table "0 20480 linear 7:0 22528"
>
> # hexdump -C /dev/mapper/tmp-vg2-lvol1-cow | head -1
> 00000000  53 6e 41 70 00 00 00 00  01 00 00 00 08 00 00 00
>  |SnAp............|
>
> Flip byte 5, e.g. copy to file, edit that bit, copy back.
>  # dd if=/dev/mapper/tmp-vg2-lvol1-cow of=/tmp/cow-start bs=512 count=1
>  # vim -b /tmp/cow-start   (and/or xxd)
>  # dd if=/tmp/cow-start of=/dev/mapper/tmp-vg2-lvol1-cow
>
> # dmsetup remove tmp-vg2-lvol1-cow
>
> # lvchange -ay vg2/lvol0
>
> # lvs
>  LV    VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
>  lvol0 vg2  owi-a- 10.00m
>  lvol1 vg2  swi-a- 10.00m lvol0   10.08
>
> # hexdump -C /dev/mapper/vg2-lvol1-cow | head -1
> 00000000  53 6e 41 70 01 00 00 00  01 00 00 00 08 00 00 00
>  |SnAp............|
>
> Alasdair
>

Thank you Alasdair and Douglas for your attention to this matter,
the recovery succeeded on my simple test case.

Some reports follow:

I edited the 'exhausted', 100 MiB overlay file from my F16-Live test
case, which had been made Invalid by attempting to write beyond its
capacity.

After
# dmsetup create item --table "0 8388608 snapshot 7:1 7:2 P 8" --readonly

# dmsetup status
item: 0 8388608 snapshot 202336/204800 800

# mount /dev/dm-0 /mnt/b/
mount: block device /dev/mapper/item is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/item,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# dmesg |tail
[  772.461469] EXT4-fs (dm-0): INFO: recovery required on readonly
filesystem
[  772.461476] EXT4-fs (dm-0): write access unavailable, cannot proceed

# e2fsck -n /dev/dm-0

e2fsck 1.41.14 (22-Dec-2010)
Warning: skipping journal recovery because doing a read-only filesystem
check.
_Fedora-16-x86_6 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 17442 was part of the orphaned inode list.  IGNORED.
Deleted inode 156288 has zero dtime.  Fix? no

Inode 162164 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(129696--129702) -(555921--557003)
-(557006--557016) -(557020--557050) -557058 -(557632--557663) -559125
-560586 -(565664--565759) -(566784--566911) -(566973--566991)
-(567016--567023) -(567032--567039) -(567044--567051) -(567068--567159)
-567164 -(567168--567183) -(567188--567189) -(567200--567279)
-(567284--567285) -(567288--567406) -(567408--567677) -(567680--567798)
-(567800--567807) -567839 -(567856--567912) -(567916--567919) -567960
-567967 -580765 -(580909--580911) -580920 -(580990--580991)
-(581024--581036) -(581040--581127) -592079 -606092 -(608256--608261)
-608264 -608290 -(608313--608314) -608317 -(608320--608322) -608361 -608376
-608400 -608421 -608767 -(608770--608773) -608775 -608777 -608779
-(608783--608784) -(608797--608807) -608809 -608813 -608816
-(608825--608831) -608895 -608914 -(608932--608943) -609054 -609077 -609147
-609167 -609195 -609203 -609223 -(609322--609323) -(609542--609543)
-(609558--609567) -(609584--609586) -(609666--609711) -609716
-(609718--609730) -(609736--609939) -609965 -(640485--640556)
Fix? no

Free blocks count wrong (381446, counted=375520).
Fix? no

Inode bitmap differences:  -17442 -156288 -162164
Fix? no

Free inodes count wrong (165564, counted=165454).
Fix? no

_Fedora-16-x86_6: ********** WARNING: Filesystem still has errors **********

_Fedora-16-x86_6: 96580/262144 files (0.3% non-contiguous), 667130/1048576
blocks

After removing and recreating the snapshot as read-write,

# e2fsck -f -y /dev/dm-0

e2fsck 1.41.14 (22-Dec-2010)
_Fedora-16-x86_6: recovering journal
Clearing orphaned inode 162164 (uid=0, gid=0, mode=0100644, size=10898776)
Clearing orphaned inode 17442 (uid=0, gid=0, mode=0100755, size=27520)
Clearing orphaned inode 156288 (uid=0, gid=0, mode=0100755, size=291672)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

_Fedora-16-x86_6: ***** FILE SYSTEM WAS MODIFIED *****
_Fedora-16-x86_6: 96688/262144 files (0.3% non-contiguous), 672875/1048576
blocks

# e2fsck -p /dev/dm-0

_Fedora-16-x86_6: clean, 96688/262144 files, 672875/1048576 blocks

# dmsetup status

item: 0 8388608 snapshot 202424/204800 800

Subsequent mounting (read-only for safety) succeeded in showing the
preexisting content.

I agree with Douglas that there is a significant class of non-technical
Live USB users who would benefit from a fail safe mechanism for their
content based in overlays of a read-only origin.

For example, students and teachers using the Sugar on a Stick Spin,

http://spins.fedoraproject.org/soas/

have been frustrated when their portfolio of work has been 'lost'
after a couple of months of classwork.

We are working to provide better file system support, viz.,

http://wiki.sugarlabs.org/go/LiveOS_image

and any Device-mapper support would be much appreciated!

       --Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20111202/1c8e1bde/attachment.htm>