[linux-lvm] Clarification (and limitation) of the kernel feature I proposed

[Xen]

Zdenek, you will believe in below email that I am advocating for max 
snapshot size.

I was not.

Only kernel feature I was suggesting was making judgement about when or 
how to refuse allocation for new chunks. Nothing else. Not based on 
consumed space, unique space consumed by volumes or snapshots.

Based only on FREE SPACE metric, not USED SPACE metric (which can be 
more complex).

When you say that freezing allocation has same effect as error target, 
you could be correct.

I will not respond to individual remarks but rewrite here below as 
summary:

- call collection of all critical volumes C.

- call C1 and C2 members of C.

- each Ci ∈ C has a number FE(Ci) for the number of free (unallocated) 
extents of that volume
- each Ci ∈ C has a fixed number RE(Ci) for the number of reserved 
extents.

Observe that FE(Ci) may be smaller than RE(Ci). E.g. a volume may have 
1000 reserved extents (RE(Ci)) but 500 free extents (FE(Ci)) at which 
point it has more reserved extents than it can use.

Therefore in our calculations we use the smaller of those two numbers 
for the effective reserved extents (ERE(Ci)).

ERE(Ci) = min( FE(Ci), RE(Ci) )

Now the total number of effective reserved extents of the pool is the 
total effective number of reserved extents of collection C.

ERE(POOL) = ERE(C) = ∑ ERE(Ci)

This number is dependent on the live number of free extents of each 
critical volume Ci.

Now the critical equation that each time will be evaluated when a chunk 
is being requested for allocation, is:

ERE(POOL) < FE(POOL)

As long as the Effective Reserved Extents of the entire pool is smaller 
than the number of Free Extents in the entire pool, nothing is the 
matter.

However, when

ERE(POOL) >= FE(POOL) we enter a critical 'fullness' situation.

This may be likened to a 95% threshold.

At this point you will start 'randomly' denying not only write requests 
for regular volumes, or writeable snapshots, but also regular read-only 
snapshots can see their allocation requests (for CoW) denied.

This would of course immediately invalidate those snapshots, if the 
write request was caused by a critical volume (Ci) that is still being 
serviced.

If you say this is not much different from replacing the volumes by 
error targets, I would agree.

As long as pool fullness is maintained, this 'denial of service' is not 
really random but consistent. However if something was done to e.g. drop 
a snapshot, and space would be freed, then writes would continue after.