From: Ric Wheeler <rwheeler@redhat.com>
To: James <purpleidea@gmail.com>
Cc: Lukas Czerner <lczerner@redhat.com>,
device-mapper development <dm-devel@redhat.com>,
Paul Cuzner <pcuzner@redhat.com>,
Gluster Devel <gluster-devel@nongnu.org>
Subject: Re: [Gluster-devel] Puppet-Gluster+ThinP
Date: Sun, 20 Apr 2014 17:44:41 -0700 [thread overview]
Message-ID: <535469F9.7050605@redhat.com> (raw)
In-Reply-To: <CADCaTgogBwyr9iYPV_oAAXFD=JKNqvm=PeJAwmqLJ_ksUn1Psw@mail.gmail.com>
On 04/20/2014 05:11 PM, James wrote:
> On Sun, Apr 20, 2014 at 7:59 PM, Ric Wheeler <rwheeler@redhat.com> wrote:
>> The amount of space you set aside is very much workload dependent (rate of
>> change, rate of deletion, rate of notifying the storage about the freed
>> space).
> From the Puppet-Gluster perspective, this will be configurable. I
> would like to set a vaguely sensible default though, which I don't
> have at the moment.
This will require a bit of thinking as you have noticed, but let's start with
some definitions.
The basic use case is one file system backed by an exclusive dm-thinp target (no
other file system writing to that dm-thinp pool or contending for allocation).
The goal is to get an alert in time to intervene before things get ugly, so we
are hoping to get a sense of rate of change in the file system and how long any
snapshot will be retained for.
For example, if we have a 10TB file system (presented as such to the user) and
we write say 500GB of new data/day, daily snapshots will need that space for as
long as we retain them. If you write much less (5GB/day), it will clearly take
a lot less.
The above makes this all an effort to predict the future, but that is where the
watermark alert kicks in to help us recover from a bad prediction.
Maybe we use a default of setting aside 20% of raw capacity for snapshots and
set that watermark at 90% full? For a lot of use people, I suspect a fairly low
rate of change and that means pretty skinny snapshots.
We will clearly need to have a lot of effort here in helping explain this to
users so they can make the trade off for their particular use case.
>
>> Keep in mind with snapshots (and thinly provisioned storage, whether using a
>> software target or thinly provisioned array) we need to issue the "discard"
>> commands down the IO stack in order to let the storage target reclaim space.
>>
>> That typically means running the fstrim command on the local file system
>> (XFS, ext4, btrfs, etc) every so often. Less typically, you can mount your
>> local file system with "-o discard" to do it inband (but that comes at a
>> performance penalty usually).
> Do you think it would make sense to have Puppet-Gluster add a cron job
> to do this operation?
> Exactly what command should run, and how often? (Again for having
> sensible defaults.)
I think that we should probably run fstrim once a day or so (hopefully late at
night or off peak)? Adding in Lukas who lead a lot of the discard work.
>
>> There is also a event mechanism to help us get notified when we hit a target
>> configurable watermark ("help, we are running short on real disk, add more
>> or clean up!").
> Can you point me to some docs about this feature?
My quick google search only shows my own very shallow talk slides, so let me dig
around for something better :)
>
>> Definitely worth following up with the LVM/device mapper people on how to do
>> this best,
>>
>> Ric
> Thanks for the comments. From everyone I've talked to, it seems some
> of the answers are still in progress. The good news is, that I'm ahead
> of the curve for being ready for when this becomes more mainstream. I
> think Paul is in the same position too.
>
> James
This is all new stuff - even not with gluster on top of it - so this will mean
hitting a few bumps I fear. Definitely worth putting thought into this now and
working on the documentation,
Ric
next prev parent reply other threads:[~2014-04-21 0:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1397056420.4190.93.camel@freed>
[not found] ` <1420171478.1325442.1397081884591.JavaMail.zimbra@redhat.com>
2014-04-20 23:59 ` [Gluster-devel] Puppet-Gluster+ThinP Ric Wheeler
[not found] ` <53545F62.8060001-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-21 0:11 ` Puppet-Gluster+ThinP James
2014-04-21 0:44 ` Ric Wheeler [this message]
[not found] ` <535469F9.7050605-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-24 5:59 ` Puppet-Gluster+ThinP James
2014-04-24 12:03 ` [Gluster-devel] Puppet-Gluster+ThinP Lukáš Czerner
2014-04-22 14:30 ` David Teigland
[not found] ` <20140422143018.GA25966-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-24 5:59 ` [dm-devel] Puppet-Gluster+ThinP James
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=535469F9.7050605@redhat.com \
--to=rwheeler@redhat.com \
--cc=dm-devel@redhat.com \
--cc=gluster-devel@nongnu.org \
--cc=lczerner@redhat.com \
--cc=pcuzner@redhat.com \
--cc=purpleidea@gmail.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.