On 08/09/2018 03:01 PM, Piotr Dałek wrote:
> This introduces one big issue: it enforces COW snapshot on image,
> meaning that original image access latencies and consumed space
> increases. "Lightweight" snapshots would remove these inefficiencies -
> no COW performance and storage overhead.
Do yo
> -Original Message-
> From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of
> Simon Leinen
> Sent: 19 March 2017 17:23
> To: Gregory Farnum
> Cc: ceph-users
> Subject: Re: [ceph-users] Snapshot Costs
>
> Gregory Farnum writes:
> >
Gregory Farnum writes:
> On Tue, Mar 7, 2017 at 12:43 PM, Kent Borg wrote:
>> I would love it if someone could toss out some examples of the sorts
>> of things snapshots are good for and the sorts of things they are
>> terrible for. (And some hints as to why, please.)
> They're good for CephFS s
On 03/07/2017 04:35 PM, Gregory Farnum wrote:
Creating a snapshot generally involves a round-trip to the monitor,
which requires a new OSDMap epoch (although it can coalesce) — ie, the
monitor paxos commit and processing the new map on all the OSDs/PGs.
Destroying a snapshot involves adding the s
On Tue, Mar 7, 2017 at 12:43 PM, Kent Borg wrote:
> On 01/04/2017 03:41 PM, Brian Andrus wrote:
>>
>> Think "many objects, few pools". The number of pools do not scale well
>> because of PG limitations. Keep a small number of pools with the proper
>> number of PGs.
>
>
> I finally got it through m
On 01/04/2017 03:41 PM, Brian Andrus wrote:
Think "many objects, few pools". The number of pools do not scale well
because of PG limitations. Keep a small number of pools with the
proper number of PGs.
I finally got it through my head, seems the larger answer is: Not only
it is okay to have a
