[linux-lvm] thin handling of available space

[Xen]

I was talking about the idea to communicate to a filesystem the amount 
of available blocks.

I noticed https://bugzilla.redhat.com/show_bug.cgi?id=1189215 named "LVM 
Thin: Handle out of space conditions better" which was resolved by 
Zdenek Kabelac (hey Zdenek) and which gave rise to (apparently) the new 
warning you get when you overprovision.



But this warning when overprovisioning does not solve any problems in a 
running system.

You /still/ want to overprovision AND you want a better way to handle 
out of space conditions.

A number of items were suggested in that bug:

1) change the default "resize thin-p at 100%" setting in lvm.conf
2) warn users that they have insufficient space in a pool to cover a 
fully used thinLV
3) change default wait time from 60sec after an out-of-space condition 
to something longer

Corey Marthaler suggested that only #2 was implemented, and this bug (as 
mentioned) was linked in an errata mentioned at the end of the bug.


So since I have already talked about it here with my lengthy rambling 
post ;-) I would like to at least here "formally" suggest a #4 and ask 
whether I should comment on that bug or supply/submit a new one about 
it?


So my #4 would be:

4) communicate and dynamically update a list of free blocks being sent 
to the filesystem layer on top of a logical volume (LV) such that the 
filesystem itself is aware of shrinking free space.

Logic implies:
- any thin LV seeing more blocks being used causes the other filesystems 
in that thin pool to be updated with new available blocks (or numbers) 
if this amount becomes less than the filesystem normally would think it 
had

- any thin LV that sees blocks being discarded by the filesystem causes 
the other filesystems in that thin pool to be updated with newly 
available blocks (or numbers) op to the moment that the real available 
space agrees once more with the virtual available space (real free >= 
virtual free)

Meaning that this feedback would start happening for any thin LV when 
the real available space in the thin pool cq. volume group (depending on 
how that works at that point in that place in that configuration) 
becomes less then the virtual available space for the thin volume (LV)

This would mean that the virtual available space would in effect 
dynamically shrink and grow with the real available space as an 
envelope.

The filesystem may know this as an adjusted total available space 
(number of blocks) or as an adjusted number of unavailable blocks. It 
would need to integrate this in its free space calculation. For a user 
tool such as "df" there are 3 ways to update this changing information:

1. dynamically adjust the total available blocks
2. dynamically adjust the amount of free blocks
3. introduce a new field of "unavailable"

Traditional "df" is "total = used + free", the new one would be "total = 
used + free + unavailable".

For any user tool not working in blocks but simply available space 
(bytes) likely only the amount of free space being reported, would 
change.

One may choose to hide the information in "df" and introduce a new flag 
that shows unavailable as well?

Then only the amount of free blocks reported, would change, and the 
numbers just don't add up visibly.

It falls along the line of the "discard" family of communications that 
were introduced in 2008 (https://lwn.net/Articles/293658/).

I DO NOT KNOW if this already exists but I suppose it doesn't. I do not 
know a lot about the filesystem system. I just took the liberty to ask 
Jonathan Corwell erm Corbet whether this is possible :p.

Anyway, hopefully I am not being too much of a pain here. Regards.