From: Xen <list@xenhideout.nl>
To: Linux lvm <linux-lvm@redhat.com>
Subject: [linux-lvm] about the lying nature of thin
Date: Fri, 29 Apr 2016 00:37:23 +0200 [thread overview]
Message-ID: <75be777705b8abc643a67ca9b90d7b1b@dds.nl> (raw)
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@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.
next reply other threads:[~2016-04-28 22:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 22:37 Xen [this message]
2016-04-29 8:44 ` [linux-lvm] about the lying nature of thin Marek Podmaka
2016-04-29 10:06 ` Gionatan Danti
2016-04-29 13:16 ` Xen
2016-04-29 22:32 ` Xen
2016-04-30 4:46 ` Mark Mielke
2016-05-03 13:03 ` Xen
2016-04-29 11:53 ` Xen
2016-04-29 20:37 ` Chris Friesen
2016-05-10 21:47 ` [linux-lvm] thin disk -- like overcomitted/virtual memory? (was Re: about the lying nature of thin) Linda A. Walsh
2016-05-10 23:58 ` Xen
[not found] <1714078834.3820492.1461944731537.JavaMail.yahoo.ref@mail.yahoo.com>
2016-04-29 15:45 ` [linux-lvm] about the lying nature of thin matthew patton
2016-05-02 13:18 ` Mark H. Wood
2016-05-03 11:57 ` Xen
[not found] <1093625508.5537728.1462283037119.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-03 13:43 ` matthew patton
2016-05-03 17:42 ` Xen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75be777705b8abc643a67ca9b90d7b1b@dds.nl \
--to=list@xenhideout.nl \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.