Re: [linux-lvm] Reserve space for specific thin logical volumes

[Gionatan Danti <g.danti@assyoma.it>]

Il 13-09-2017 01:22 matthew patton ha scritto:
>> Step-by-step example:
>  > - create a 40 GB thin volume and subtract its size from the thin
> pool (USED 40 GB, FREE 60 GB, REFER 0 GB);
>  > - overwrite the entire volume (USED 40 GB, FREE 60 GB, REFER 40 GB);
>  > - snapshot the volume (USED 40 GB, FREE 60 GB, REFER 40 GB);
> 
> And 3 other threads also take snapshots against the same volume, or
> frankly any other volume in the pool.
> Since the next step (overwrite) hasn't happened yet or has written
> less than 20GB, all succeed.
> 
>  > - completely overwrite the original volume (USED 80 GB, FREE 20 GB,
> REFER 40 GB);
> 
> 4 threads all try to write their respective 40GB. Afterall, they got
> the green-light since their snapshot was allowed to be taken.
> Your thinLV blows up spectacularly.
> 
>  > - a new snapshot creation will fails (REFER is higher then FREE).
> nobody cares about new snapshot creation attempts at this point.
> 
> 
>> When do you decide it ?  (you need to see this is total race-lend)
> 
> exactly!

I all the examples I did, the snapshot are suppose to be read-only or at 
least never written. I thought that it was implicitly clear due to ZFS 
(used as example) being read-only by default. Sorry for not explicitly 
stating that.

However, the refreservation mechanism can protect the original volume 
even when snapshots are writeable. Here we go:

# Create a 400M ZVOL and fill it
[root@localhost ~]# zfs create -V 400M tank/vol1
[root@localhost ~]# dd if=/dev/zero of=/dev/zvol/tank/vol1 bs=1M 
oflag=direct
dd: error writing ‘/dev/zvol/tank/vol1’: No space left on device
401+0 records in
400+0 records out
419430400 bytes (419 MB) copied, 23.0573 s, 18.2 MB/s
[root@localhost ~]# zfs list -t all
NAME        USED  AVAIL  REFER  MOUNTPOINT
tank        416M   464M    24K  /tank
tank/vol1   414M   478M   401M  -

# Create some snapshots (note how the USED value increased due to the 
snapshot reserving space for all "live" data in the ZVOL)
[root@localhost ~]# zfs set snapdev=visible tank/vol1
[root@localhost ~]# zfs snapshot tank/vol1@snap1
[root@localhost ~]# zfs snapshot tank/vol1@snap2
[root@localhost ~]# zfs list -t all
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank              816M  63.7M    24K  /tank
tank/vol1         815M   478M   401M  -
tank/vol1@snap1     0B      -   401M  -
tank/vol1@snap2     0B      -   401M  -

# Clone the snapshot (to be able to overwrite it)
[root@localhost ~]# zfs clone tank/vol1@snap1 tank/cvol1
[root@localhost ~]# zfs list -t all
NAME              USED  AVAIL  REFER  MOUNTPOINT
tank              815M  64.6M    24K  /tank
tank/cvol1          1K  64.6M   401M  -
tank/vol1         815M   479M   401M  -
tank/vol1@snap1     0B      -   401M  -
tank/vol1@snap2     0B      -   401M  -

# Writing to the cloned ZVOL fails (after only 66 MB written) *without* 
impacting the original volume
[root@localhost ~]# dd if=/dev/zero of=/dev/zvol/tank/cvol1 bs=1M 
oflag=direct
dd: error writing ‘/dev/zvol/tank/cvol1’: Input/output error
64+0 records in
63+0 records out
66060288 bytes (66 MB) copied, 25.9189 s, 2.5 MB/s

After the last write, the cloned cvol1 is clearly corrputed, but the 
original volume has not problem at all.

Now, I am *not* advocating switching thinp to a ZFS-like things (ie: 
note the write speed, which is low even for my super-slow notebook HDD). 
However, a mechanism with which we can tell LVM "hey, this volume should 
have all its space as reserved, don't worry about preventing snapshots 
and/or freezing them when free space runs out".

This was more or less the case with classical, fat LVM: a snapshot 
runnig out of space *will* fail, but the original volume remains 
unaffected.

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8