Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

[Mike Snitzer]

On Wed, Jul 31 2013 at  1:08pm -0400,
Chris Murphy <lists at colorremedies.com> wrote:

> 
> On Jul 31, 2013, at 8:32 AM, Mike Snitzer <snitzer at redhat.com> wrote:
> 
> > But on the desktop the fedora
> > developers need to provide sane policy/defaults.
> 
> Right. And the concern I have (other than a blatant bug), is the F20
> feature for the installer to create thinp LVs; and to do that the
> installer needs to know what sane default parameters are. I think
> perhaps determining those defaults is non-obvious because of my
> experience in this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=984236

Hmm, certainly a strange one.  But some bugs can be.  Did you ever look
to see if CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is enabled?  Wouldn't
explain any dmeventd memleak issues but could help explain slowness
associated with mkfs.btrfs ontop of thinp.  Anyway, to be continued in
the BZ...

> If I'm going to use thinP mostly for snapshots, then that suggests a
> smaller chunk size at thin pool creation time; whereas if I have no
> need for snapshots but a greater need for provisioning then a larger
> chunk size is better. And asking usage context in the installer, I
> think is a problem.

It is certainly less than ideal but we haven't come up with an
alternative yet.  As Zdenek mentioned in comment#13 of the BZ you
referenced, we're looking to do is establish default profiles for at
least these 2 use-cases you mentioned.  lvm2 has recently grown profile
support.  We just need to come to terms with what constitutes
sufficiently small and sufficently large thinp block sizes.

We're doing work to zero in on the best defaults... so ultimately this
is still up in the air.

But my current thinking for these 2 profiles is:
* for performance, use data device's optimal_io_size if > 64K.
  - this will yield a thinp block_size that is a full stripe on RAID[56]
* for snapshots, use data device's minimum_io_size if > 64K.

If/when we have the kernel REQ_RESERVE support to prealloc space in the
thin-pool it _could_ be that we make the snapshots profile the default;
and anything that wanted more performance could use fallocate().  But it
is a slippery slope because many apps could overcompensate to always use
fallocate()... we really don't want that.  So some form of quota might
need to be enforced on a cgroup level (once cgroup's reservation quota
is exceeded fallocate()'s REQ_RESERVE bio pass down will be skipped).
Grafting in cgroup-based policy into DM is a whole other can of worms,
but doable.

Open to other ideas...

Mike