linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Reasonable amount of snapshots
@ 2017-11-01 11:04 ST
  2017-11-01 11:17 ` Qu Wenruo
  0 siblings, 1 reply; 5+ messages in thread
From: ST @ 2017-11-01 11:04 UTC (permalink / raw)
  To: linux-btrfs

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?
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?

Thank you!


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Reasonable amount of snapshots
  2017-11-01 11:04 Reasonable amount of snapshots ST
@ 2017-11-01 11:17 ` Qu Wenruo
  2017-11-01 11:31   ` ST
  0 siblings, 1 reply; 5+ messages in thread
From: Qu Wenruo @ 2017-11-01 11:17 UTC (permalink / raw)
  To: ST, linux-btrfs


[-- Attachment #1.1: Type: text/plain, Size: 1418 bytes --]



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.

Thanks,
Qu

> 
> Thank you!
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Reasonable amount of snapshots
  2017-11-01 11:17 ` Qu Wenruo
@ 2017-11-01 11:31   ` ST
  2017-11-01 12:07     ` Qu Wenruo
  0 siblings, 1 reply; 5+ messages in thread
From: ST @ 2017-11-01 11:31 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs

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!


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Reasonable amount of snapshots
  2017-11-01 11:31   ` ST
@ 2017-11-01 12:07     ` Qu Wenruo
  2017-11-01 12:13       ` Hans van Kranenburg
  0 siblings, 1 reply; 5+ messages in thread
From: Qu Wenruo @ 2017-11-01 12:07 UTC (permalink / raw)
  To: ST; +Cc: linux-btrfs


[-- Attachment #1.1: Type: text/plain, Size: 1482 bytes --]



On 2017年11月01日 19:31, ST wrote:
> 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!

No way to limit, unfortunately.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Reasonable amount of snapshots
  2017-11-01 12:07     ` Qu Wenruo
@ 2017-11-01 12:13       ` Hans van Kranenburg
  0 siblings, 0 replies; 5+ messages in thread
From: Hans van Kranenburg @ 2017-11-01 12:13 UTC (permalink / raw)
  To: Qu Wenruo, ST; +Cc: linux-btrfs

On 11/01/2017 01:07 PM, Qu Wenruo wrote:
> 
> 
> On 2017年11月01日 19:31, ST wrote:
>> 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!
> 
> No way to limit, unfortunately.

Well, it can obviously be "limited" by just not using cp --reflink all
over the place and by not running dedupe on everything. The filesystem
won't just start doing that by its own. ;]


-- 
Hans van Kranenburg

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-11-01 12:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-01 11:04 Reasonable amount of snapshots ST
2017-11-01 11:17 ` Qu Wenruo
2017-11-01 11:31   ` ST
2017-11-01 12:07     ` Qu Wenruo
2017-11-01 12:13       ` Hans van Kranenburg

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).