All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark H. Wood" <mwood@IUPUI.Edu>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] about the lying nature of thin
Date: Mon, 2 May 2016 09:18:12 -0400	[thread overview]
Message-ID: <20160502131812.GA1949@IUPUI.Edu> (raw)
In-Reply-To: <1714078834.3820492.1461944731537.JavaMail.yahoo@mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Fri, Apr 29, 2016 at 03:45:31PM +0000, matthew patton wrote:
> > ~35GB each, meaning 35000 GB is available and 25000 is 
> > in use, then it is not a lie to say to any individual customer: you can 
> > use 50GB if you want.
> 
> If enough of your so-called customers decide to use the space you promised them AND THAT THEY PAID FOR and instead they get massive data loss and outages, you can bet your hiney they'll sue you silly.

Executive summary:  you shouldn't just take a wild guess and then turn
your back on a thin-provisioned setup; you must understand your
consumers and monitor your resources.

It's reasonable in certain circumstances for a service provider to
over-subscribe his hardware.  He would be well advised to monitor
actual allocation closely, to keep some cash or ready credit on hand
for quick expansion of his real hardware, and to respond promptly by
adding capacity when usage nears real hardware limits.  He is taking a
risk, betting that most customers won't max out their promised
storage, and should manage that risk.  Indeed, he should first gather
statistics to understand the behavior of typical customers and
determine whether he would be taking a *foolish* risk.

Failure to adequately manage resources to redeem contracted promises
is the provider's lie, not LVM's.  Failure to plan is planning to
fail.

If that's too scary, don't use thin provisioning.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2016-05-02 13:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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
2016-04-28 22:37 Xen
2016-04-29  8:44 ` 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

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=20160502131812.GA1949@IUPUI.Edu \
    --to=mwood@iupui.edu \
    --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.