How to force a snapshot status to valid when I know very well it's valid?

How to force a snapshot status to valid when I know very well it's valid?

[Greg Stark]

I have a snapshot whose cow table became full. I understand full well
why snapshots become invalid at this point but the source volume was
not mounted anywhere and hasn't been written to. I can add more space
to the cow table now but is there any way to force the status to be
valid again?

-- 
greg

Re: How to force a snapshot status to valid when I know very well it's valid?

[Frederick Grose]

[-- Attachment #1.1: Type: text/plain, Size: 462 bytes --]

On Fri, Dec 21, 2012 at 10:31 AM, Greg Stark <stark@mit.edu> wrote:

> I have a snapshot whose cow table became full. I understand full well
> why snapshots become invalid at this point but the source volume was
> not mounted anywhere and hasn't been written to. I can add more space
> to the cow table now but is there any way to force the status to be
> valid again?
>
> --
> greg


See
https://fedoraproject.org/wiki/LiveOS_image#Overlay_recovery

    --Fred

[-- Attachment #1.2: Type: text/html, Size: 913 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: How to force a snapshot status to valid when I know very well it's valid?

[Greg Stark]

> See
> https://fedoraproject.org/wiki/LiveOS_image#Overlay_recovery

THANK YOU. That was enormously helpful and saved my bacon big time.
The lvm snapshot is active and the filesystem is back.

For future reference what I actually did was find the cow dm device
for the invalid lvm snapshot from dmsetup which was the device with
the same name as the snapshot plus "-cow":

# dmsetup status
vg_root-lv_u01_dev: 0 4724490240 snapshot Invalid
vg_root-lv_u01_dev-cow: 0 1048576000 linear

Then I ran the command from that doc to set the valid bit:
# echo $'\x01' | dd of=/dev/mapper/vg_root-lv_u01_dev-cow bs=1 count=1
seek=4 conv=notrunc
1+0 records in
1+0 records out
1 byte (1 B) copied, 2.9e-05 seconds, 34.5 kB/s

Then I didn't know how to reload the dm state so I rebooted the
machine. This caused a bit of a scare because loading the lvm volumes
took about 30 minutes. I don't know why or what happened there. But it
eventually did come up. Then I ran fsck a a few times, the third time
it found no problems (the first time actually seemed to corrupt the
filesystem!).

So actually a few things didn't work as expected. Firstly the lvm
snapshot expiring actually made one of the pv's in the vg invalid:
  --- Physical volume ---
  PV Name               unknown device
  VG Name               vg_root

This caused a lot of confusion since it looked like a hardware
problem. There were no hardware errors and after rebooting that device
seems fine so I think this was caused by dm.

Then rebooting after the bit was twiddled rebooting froze for a very
long time on this step in the redhat boot process:
Setting up Logical Volume Management:
It was about 30 minutes before this appeared:
Setting up Logical Volume Management:   4 logical volume(s) in volume
group "vg_root"

I don't know what could possibly have caused that. It wasn't even
mounting anything at this stage.  I actually went for a drink at this
point sure that I had corrupted the snapshot data structures in some
weird way. One catch is I had done lvextend already -- does the
snapshot dm need to initialize all the blocks of the newly extended
cow table?

-- 
greg

Re: How to force a snapshot status to valid when I know very well it's valid?

[Alasdair G Kergon]

On Fri, Dec 21, 2012 at 10:54:21PM +0000, Greg Stark wrote:
> took about 30 minutes. I don't know why or what happened there. But it

Big snapshots take a long time to load - the whole cow area has to be
scanned to generate the list of blocks represented on it.

(Large thin snapshots don't have this shortcoming.)

Alasdair

Re: How to force a snapshot status to valid when I know very well it's valid?

[Greg Stark]

On Fri, Dec 21, 2012 at 11:13 PM, Alasdair G Kergon <agk@redhat.com> wrote:
> On Fri, Dec 21, 2012 at 10:54:21PM +0000, Greg Stark wrote:
>> took about 30 minutes. I don't know why or what happened there. But it
>
> Big snapshots take a long time to load - the whole cow area has to be
> scanned to generate the list of blocks represented on it.

Hm. I didn't remember this happening previously but I had just doubled
the size of the cow and I might be wrong about it too.

I have another question while I'm here and people are being so
helpful. Is there a way to grow the size of the actual snapshot
device? Not the cow table but the device that the snapshot is
presenting? If I change the size of the underlying device I don't
think it changes the size of the snapshot and if I extend the snapshot
it just changes the size of the cow table. It seems like it should be
possible to add another dm mapping for the added space using a simple
linear mapping.

[btw Alasdair, Hi! We met at FOSDEM and discussed filesystem/dm synchronization
primitives that would help Postgres have more lightweight checkpoints]

-- 
greg

Re: How to force a snapshot status to valid when I know very well it's valid?

[Alasdair G Kergon]

On Fri, Dec 21, 2012 at 11:35:31PM +0000, Greg Stark wrote:
> I have another question while I'm here and people are being so
> helpful. Is there a way to grow the size of the actual snapshot
> device? Not the cow table but the device that the snapshot is
> presenting? If I change the size of the underlying device I don't
> think it changes the size of the snapshot and if I extend the snapshot
> it just changes the size of the cow table. It seems like it should be
> possible to add another dm mapping for the added space using a simple
> linear mapping.
 
We discused this sort of thing but never implemented it.

Perhaps we will offer more resizing options with the new thin snapshots.

Alasdair