From: ST <smntov@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Reasonable amount of snapshots
Date: Wed, 01 Nov 2017 13:31:44 +0200 [thread overview]
Message-ID: <1509535904.1662.93.camel@gmail.com> (raw)
In-Reply-To: <fb1522f7-ffbe-cc5c-8a1d-bb3812b2e0f0@gmx.com>
On Wed, 2017-11-01 at 19:17 +0800, Qu Wenruo wrote:
>
> On 2017年11月01日 19:04, ST wrote:
> > Hello,
> >
> > I read in different places that one should keep amount of snapshots low
> > - around 15-20. My question - is this limitation on total number of
> > snapshots on the system or only on related (parent<->child) chain of
> > snapshots?
>
> Independent subvolume doesn't count, and it's filesystem based.
>
> So only snapshots (with source exists, and still shares a lot of trees
> with source) counts.
>
> And if you have multiple btrfs fses, then the count should be based on
> each fs.
>
> > What I want to do is the following: create (and then rotate) last 7
> > daily snapshots (and maybe 4 weekly) for each user in his /home dir.
> > For
> > around 100 users. So if limitation is only on related snapshots then I'm
> > OK since only each 7 (or maybe 7+4) of them are related which is well
> > under the 15-20 limit. However in total there could be 700 snapshots. So
> > what is true?
>
> You're OK since independent subvolumes won't cause too much stress for
> backref walk.
>
> The only thing you may need to consider is to limit the ability to
> reflink data between subvolumes.
> Like cp --reflink or even offline dedupe.
Thank you very much! How can I limit this ability? (I'm on Debian9)
All the best!
next prev parent reply other threads:[~2017-11-01 11:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 11:04 Reasonable amount of snapshots ST
2017-11-01 11:17 ` Qu Wenruo
2017-11-01 11:31 ` ST [this message]
2017-11-01 12:07 ` Qu Wenruo
2017-11-01 12:13 ` Hans van Kranenburg
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=1509535904.1662.93.camel@gmail.com \
--to=smntov@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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.