0

I'm using device mapper snapshots.

Let's assume that /dev/sda is the read-only origin device, and /dev/sdb is the COW device. I created a persistent snapshot this way:

# cat /dev/zero > /dev/sdb # dmsetup create mysnap 0 1000000000 snapshot /dev/sda /dev/sdb P 16 ^D # ls /dev/mapper/ control mysnap #

It worked fine for a while.

After every boot, to re-attach my persistent snapshot, I was running the same command:

dmsetup create mysnap 0 1000000000 snapshot /dev/sda /dev/sdb P 16

But one day I accidentally disconnected the read-only origin device during operation (the COW device was still there). There was a kernel message like that:

device-mapper: snapshots: Invalidating snapshot: error reading/writing

After that happened, any attempt to attach the snapshot (on any machine) results in error:

device-mapper: snapshots: Snapshot is marked invalid

The mysnap device gets created, but it refuses any reads/writes with "Input/output error".

Is it possible to clear the "invalid" status on the DM snapshot and bring it up, or at least to recover the data?
I believe that this "invalid" status is fully artificial because, from my experience, persistent DM snapshots survived total system crashes.

Improve this question

1 Answer 1

Reset to default
2

The source code drivers/md/dm-snap-persistent.c says there is no way of recovering an invalid snapshot:

struct disk_header { __le32 magic; /* * Is this snapshot valid. There is no way of recovering * an invalid snapshot. */ __le32 valid;

So what options do you have?

  • figure out how to repair on-disk metadata,
  • change source code to ignore invalid states.

But it will only work if all metadata (and data itself) is fully present and intact.

In the simplest case, the valid flag just changes from 1 to 0 in the disk header.

Example of a valid snapshot:

# hexdump -C -n 8 /dev/<COW Device> 00000000 53 6e 41 70 01 00 00 00 |SnAp....| ^^^

Example of an invalid snapshot:

# hexdump -C -n 8 /dev/<COW Device> 00000000 53 6e 41 70 00 00 00 00 |SnAp....| ^^^

So you could blindly attempt to make it valid:

$ printf 'SnAp\1' | hexdump -C 00000000 53 6e 41 70 01 |SnAp.| # printf 'SnAp\1' > /dev/<COW Device>

However, this ignores all other circumstances. On a snapshot that went invalid, data consistency is not guaranteed anymore. As such the data presented could still be invalid. Furthermore with the snapshot being writable, it could also cause additional damage to the snapshot data.

In a data recovery situation, you could make a full copy first, or …try this experiment on a snapshot… haha.

Good luck?

Improve this answer
2
  • 1
    Thanks for the detailed answer! Changing the byte in the header did the trick. Snapshot attached, the filesystem seems intact. I really don't understand what's the point in marking the snapshot invalid just because of I/O error to origin device (which was caused by drive disconnect). Commented Jul 1, 2024 at 6:16
  • 1
    @melonfsck Well, you'd have to discuss this with the devs, but snapshot is ancient... see also. I'm not sure if it helps in your case, since this was a question about performance, not (in)validation handling. The only other thing I found was a patch which apparently got ignored (but it wouldn't have helped you, in any case). Commented Jul 1, 2024 at 8:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.