[linux-lvm] thin handling of available space

[Xen]

Zdenek Kabelac schreef op 29-04-2016 13:23:

> I'm not going to add much to this thread - since there is nothing
> really useful for devel.  But let me strike out few important moments:

If you like to keep things short now I will give short replies. Also 
other people have responded and I haven't read everything yet.

> it's still the admin who creates thin-volume and gets WARNING if VG is 
> not big enough when
> all thin volumes would be fully provisioned.

That is just what we could call insincere or that beautiful strange word 
that I cannot remember.

The opposite of innocuous. Disingenuous (thank you dictionary).

You know perfectly well that this warning doesn't do much of anything 
when all people approach thin from the view point of wanting to 
overprovision.

That is like saying "Don't enter this pet store here, because you might 
buy pets, and pets might scratch your arm. Now what can we serve you 
with?".

It's those insincere warnings many business or ideas give to people to 
supposedly warn them in advance of what they want to do anyway. "I told 
you it was a bad idea, now what can we do for you? :) :) :) :)". It's a 
way of being politically correct mostly.

You want to do it anyway. But now someone tells you it might be a bad 
idea even if both of you want it.


> So you try to design  'another btrfs' on top of thin provisioning?

Maybe I am. At least you recognise that I am trying to design something, 
many people would just throw it in the wastebasket with "empty 
complains".

That in itself.... ;-)

speaks some volumes.

But let's talk about real volumes now :p.

There's nothing bad about btrfs except that it usurps everything, 
doesn't separate any layers, and just overall means the end and death of 
a healthy filesystem system. It wants to be the monopoly.

> With 'thinp' you  want simplest  filesystem with robust metadata -  so
> in theory  -  'ext4' or  XFS without all 'improvements for rotational
> hdd that has accumulated over decades of their evolution.

I agree. I don't even use ext4, I use ext3. I feel ext4 may have some 
benefits but they are not really worth anything.

> You miss the 'key' details.
> 
> Thin pool is not constructing  'free-maps'  for each LV all the time -
> that's why tools like  'thin_ls'  are meant to be used from the
> user-space.
> It IS very EXPENSIVE operation.
> 
> So before you start to present your visions here, please spend some
> time with reading doc and understanding all the technology behind it.

Sure I could do that. I could also allow myself to die without ever 
having contributed to anything.

>> Even with a perfect LVM monitoring tool, I would experience a 
>> consistent
>> lack of feedback.
> 
> Mistake of your expectations

It is nothing to do with expectations. Things and feeling that keep 
creeping up to you and keep annoying you have nothing to do with 
expectations.

That is like being thoroughly annoyed about something for years and 
expecting it to go away by itself, is the epitome of sanity.

For example: monitor makes buzzing noise when turned off. Deeply 
frustrating, annoying, downright bad. Gives me nightmares even. You say 
"You have bad expectations of hardware, hardware just does that thing, 
you have to live with it." I go to shop, shop says "Yeah all hardware 
does that (so we don't need to pay you anything back)".

That has nothing to do with bad expectations.

> If you are trying to operate  thin-pool near 100% fullness - you will
> need to write and design completely different piece of software -
> sorry thinp
> is not for you and never will...

I am not trying to operate near 100% fullness.

Although it wouldn't be bad if I could manage that.

That would not be such a bad thing at all. If the tools where there to 
actually do it, and the mechanisms. Wouldn't you agree? Regardless of 
what is possible or even what is to be considered "wise" here, wouldn't 
it be beneficial in some way?

> 
>> 
>> Just a simple example: I can adjust "df" to do different stuff. But 
>> any
>> program reporting free diskspace is going to "lie" to me in that 
>> sense. So
>> yes I've chosen to use thin LVM because it is the best solution for me
>> right now.
> 
> 'df'  has nothing in common with  'block' layer.

A clothing retailer has nothing in common with a clothing manufacturer 
either, but they are just both in the same business.

> But if you've never planned to buy 10TB - you should have never allow
> to create such big volume in the first place!

So you are like saying the only use case of thin is a growth scenario 
that can be met.

> So don't do it - and don't plan to use it - it's really that simple.

What I was saying was that it would be possible to maintain the contract 
that any individual volume at any one time would be able to grow to max 
size as long as other volumes don't start acting aberrant. If you manage 
all those volumes of course you would be able to choose this.

The purpose of the thin system is to maintain the situation that all 
volumes can reach their full potential without (auto)extending, in that 
sense.

If you did actually make a 1TB volume for a single client with a 10TB 
V-size, you would be a very bad contractor. Who says it is not going to 
happen overnight? How will you be able to respond.

The situation where you have a 10TB volume and you have 20 clients with 
1TB each, is very different.

I feel the contract should be that the available real space should 
always be equal to or greater than the available on any one filesystem 
(volume).

So: R >= max(A(1), A(2), A(3), ..., A(n))

Of course it is pleasant not having to resize the filesystem but would 
you really do that for yourself? Make a 10TB filesystem on a 1TB disk as 
you expect to buy more disks in the future?

I mean you could. But in this sense resizing the filesystem (growing it) 
is not a very expensive operation, usually.

I would only want to do that if I could limit the actual usage of the 
filesystem in a real way.

Any runaway process causing my volume to drop...... NOT a good thing.

> Actually it's the core principle!
> It lies (or better say uses admin's promises) that there is going to
> be a disk space. And it's admin responsibility to fulfill it.

The admin never comes into it. What the admin does or doesn't do, what 
the admin thinks or doesn't think. These are all interpretations of 
intents.

Thinp should function regardless of what the admin is thinking or not. 
Regardless of what his political views are.

You are bringing morality into the technical system.

You are saying /thinp should work/ because /the admin should be a good 
person/.

When the admin creates the system, no "promise" is ever communicated to 
the hardware layer, OR the software layer. You are turning the correct 
operation of the machine into a human problem in the way of saying 
"/Linux is a great system and everyone can use it, but some people are 
just too stupid to spend a few hours reading a manual on a daily basis, 
and we can't help that/".

These promises are not there in the system. Someone might be using the 
system for reasons you have not envisioned. But the system is there and 
it can be used for it. Now if things go wrong you say "You you had the 
wrong use case" but a use case is just a use case, it has no morality to 
it.

If you build a waterway system that only functions as long as it doesn't 
rain (overflowing the channels) then you can say "Well my system is 
perfect, it is just God who is a bitch and messes things up".

No you have to take account of real life human beings, not those ideal 
pictures of admins that you have.

Stop the idealism you know. Admins are humans and they can be expected 
to be humans.

It is you who have wrong expectations of people.

If people mess up they mess up but it is part of the human agenda and 
you design for that.


> If you know in front you will need quickly all the disk space - then
> using thinp and expecting miracle is not going to work.

Nobody ever said anything of that kind.