linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: matthew patton <pattonme@yahoo.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] thin handling of available space
Date: Thu, 28 Apr 2016 13:46:03 +0000 (UTC)	[thread overview]
Message-ID: <1684768750.3193600.1461851163510.JavaMail.yahoo@mail.yahoo.com> (raw)
In-Reply-To: 1684768750.3193600.1461851163510.JavaMail.yahoo.ref@mail.yahoo.com

> > The real question you should be asking is if it increases the monitoring
> > aspect (enhances it) if thin pool data is seen through the lens of the
> > filesystems as well.

Then you want an integrated block+fs implementation. See BTRFS and ZFS. WAFL and friends.

> kernel for communication from lower fs layers to higher layers -

Correct. Because doing so violates the fundamental precepts of OS design. Higher layers trust lower layers. Thin Pools are outright lying about the real world to anything that uses it's services. That is its purpose. The FS doesn't give a damn that the block layer is lying to it, it can and does assume and rightly so that what the block layer says it has, it indeed does have. The onus of keeping the block layer ahead of the FS falls on a third party - the system admin. The system admin decided it was a bright idea to use thin pools in the first place so he necessarily signed up to be liable for the hazards and risks that choice entails. It is not the job of the FS to bail his ass out.

A responsible sysadmin who chose to use thin pools might configure the initial FS size to be some modest size well within the constraints of the actual block store, and then as the FS hit say 85% utilization to run a script that investigated the state of the block layer and use resize2fs and friends to grow the FS and let the thin-pool likewise grow to fit as IO gets issued. But at some point when the competing demands of other FS on the thin-pool were set to breach actual block availability, the script would refuse to grow the FS and thus userland would get signaled by the FS layer that it's out of space when it hit 100% util.

Another way (haven't tested) to 'signal' the FS as to the true state of the underlying storage is to have a sparse file that gets shrunk over time.

But either way if you have a sudden burst of I/O from competing interests in the thin-pool, what appeared to be a safe growth allocation at one instant of time is not likely to be true when actual writes try to get fulfilled. 

Mindless use of thin-pools is akin to crossing a heavily mined beach. Bring a long stick and say your prayers because you'r likely going to lose a limb.

       reply	other threads:[~2016-04-28 13:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1684768750.3193600.1461851163510.JavaMail.yahoo.ref@mail.yahoo.com>
2016-04-28 13:46 ` matthew patton [this message]
     [not found] <799090122.6079306.1462373733693.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-04 14:55 ` [linux-lvm] thin handling of available space matthew patton
2016-05-03 18:19 Xen
     [not found] <1614984310.1700582.1462280490763.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-03 13:01 ` matthew patton
2016-05-03 15:47   ` Xen
2016-05-04  0:56   ` Mark Mielke
     [not found] <1870050920.5354287.1462276845385.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-03 12:00 ` matthew patton
2016-05-03 14:38   ` Xen
2016-05-04  1:25   ` Mark Mielke
2016-05-04 18:16     ` Xen
     [not found] <929635034.3140318.1461840230292.JavaMail.yahoo.ref@mail.yahoo.com>
2016-04-28 10:43 ` matthew patton
2016-04-28 18:20   ` Xen
2016-04-28 18:25   ` Xen
2016-04-29 11:23     ` Zdenek Kabelac
2016-05-02 14:32       ` Mark Mielke
2016-05-03  9:45         ` Zdenek Kabelac
2016-05-03 10:41           ` Mark Mielke
2016-05-03 11:18             ` Zdenek Kabelac
2016-05-03 10:15         ` Gionatan Danti
2016-05-03 11:42           ` Zdenek Kabelac
2016-05-03 13:15             ` Gionatan Danti
2016-05-03 15:45               ` Zdenek Kabelac
2016-05-03 12:42       ` Xen
     [not found] <518072682.2617983.1461760017772.JavaMail.yahoo.ref@mail.yahoo.com>
2016-04-27 12:26 ` matthew patton
2016-04-27 21:28   ` Xen
2016-04-28  6:46     ` Marek Podmaka
2016-04-28 10:33       ` Xen
  -- strict thread matches above, loose matches on Subject: below --
2016-04-23 17:53 Xen
2016-04-27 12:01 ` 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=1684768750.3193600.1461851163510.JavaMail.yahoo@mail.yahoo.com \
    --to=pattonme@yahoo.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).