[linux-lvm] about the lying nature of thin

Xen list at xenhideout.nl
Thu Apr 28 22:37:23 UTC 2016


You know mr. Patton made the interesting allusion that thin provisioning 
is designed to lie and is meant to lie, and I beg to differ.

Under normal operating conditions any thin volume should be allowed to 
grow to its maximum V-size provided not everyone is doing that at the 
same time.


There is nowhere in the thin contract something that says "this space I 
have available to you, you don't have to share it".

That is like saying the basement container room used as bike and motor 
space in my apartment complex is a like because if I were to fill it up, 
other people couldn't use it again anymore.

The visuals clearly indicate available physical space, but I know that 
if I use it, others won't be able to. It's called sharing.

In practical matters a thin volume only starts to lie when "real space" 
< "virtual space" -- a condition you are normally trying to avoid.

So I would not even say that by definition a thin volume or thin volume 
manager lies.

It only starts "lying" the moment real available space goes below 
virtual available space, something you would normally be trying to 
avoid.

Since your guarantee to your customers (for instance) is that this space 
IS going to be available, you're actually lying to them by not informing 
them of the condition that this guarantee can not actually be met in 
some instance of time.

Thin pools do not lie by default. They lie when they cannot fulfill 
their obligations, and this is precisely the reason for the idea I 
suggested: to stop the lie, to be honest.

It was said (by Marek Podmaka) that you don't want customers / users to 
know about the reality behind the thin pool, in some or many use cases 
(liberally interpreted). That there are use cases where you don't want 
the client to know about the thin nature.

But if you don't do your job right and the thin pool does start to fill 
up, that starts to sound like lying to your client and saying 
"everything is all right" while behind the scenes everyone is in 
calamity mode.

"Is something wrong? No no, not at all".

You're usually aware that you're being lied to ;-) if you are talking to 
a real human.

So basically:
* either you do your job right and nothing is the matter
* you don't do your job right but you don't tell anyone
* you don't do your job right and you own up.

Saying that thin pools habitually lie is not right. The question is not 
what happens or what you do while the system is functioning as intended. 
The question is what you do when that is no longer the case:

* do you inform the guest system?
* do you keep silent until shit breaks loose?

IF you had an autoextend mechanism present you could also equally well 
decide to not "inform" clients as long as that was the case. After all, 
if you have automatic extending configured and it is operational, then 
the "real size" is actually larger than what you currently have.

In that case "virtual size < real size" does not hold or does not 
happen, and there is no need to communicate anything. This is also a 
question about ethics, perhaps.

Personally I like to be informed. I don't know what you do or want.

But I can think of any number of analogies or life situations where I 
would definitely choose to be informed instead of being lied to.

Thin LVM does not lie by default. It may only start to lie when 
conditions are no longer met.

Regards, Xen.




More information about the linux-lvm mailing list