Re: removing/flattening a bucket without data movement?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 9/1/19 9:51 PM, Zoltan Arnold Nagy wrote:
> On 2019-09-01 05:57, Konstantin Shalygin wrote:
>> On 8/31/19 4:14 PM, Zoltan Arnold Nagy wrote:
>>> Could you elaborate a bit more? upmap is used to map specific PGs to
>>> specific OSDs
>>> in order to deal with CRUSH inefficiencies.
>>>
>>> Why would I want to add a layer of indirection when the goal is to
>>> remove the bucket
>>> entirely?
>>
>> As I understood you want to make huge CRUSH map changes without huge
>> data movement.
>>
>> Upmap can help with this, you map your current PG's to OSD's that
>> already holds this PG's.
> 
> Let's say with upmap I take the current mapping and "override" CRUSH,
> then remove the
> rack bucket and move the host directly to the root. And then what? We'd
> never, ever
> be able to go back, and what's worse, for any new expansions we'd need
> to manage the
> PG mappings manually.
> 
> Unless I'm missing something, while this would solve the problem in the
> very very short
> term, it would create horrible issues down the line, and would be
> shooting ourselves
> in the foot as far as maintainability is concerned.
> 
> As I've said we'd been rolling this cluster since at least Firefly, and
> I don't want to
> mess with it.
> 
> The solution I've outlined in my original mail works (swapping the
> bucket IDs) and seems
> more maintainable, however, I've been wondering if the bucket types are
> just labels or do
> they have any other semantic meaning?

They are just labels. Just like the names of buckets.

Everything is mapped to the IDs you'll find in the CRUSHMap. Negative
IDs for buckets and positive IDs for devices/OSDs.

upmap should be avoided in this case for exactly the reasons you already
mention: You create some kind of database which is not the solution
here. The only thing you can do with upmap is make this migration
smoother by removing upmap items in batches afterwards.

Wido

> _______________________________________________
> ceph-users mailing list -- ceph-users@xxxxxxx
> To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux