Re: Storage-class split objects

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

 



Hi Casey, thank you for the reply.

I was wondering, just as the placement target is in the bucket metadata in
the index, if it would not be possible to insert the storage-class
information in the metadata of the object that is in the index as well. Or
did I get it wrong and there is absolutely no type of object metadata in
the index, just a listing of the objects?

Thanks again, Marcelo.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Livre
de vírus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Em qua., 10 de fev. de 2021 às 11:43, Casey Bodley <cbodley@xxxxxxxxxx>
escreveu:

> On Wed, Feb 10, 2021 at 8:31 AM Marcelo <raxidex@xxxxxxxxx> wrote:
> >
> > Hello all!
> >
> > We have a cluster where there are HDDs for data and NVMEs for journals
> and
> > indexes. We recently added pure SSD hosts, and created a storage class
> SSD.
> > To do this, we create a default.rgw.hot.data pool, associate a crush rule
> > using SSD and create a HOT storage class in the placement-target. The
> > problem is when we send an object to use a HOT storage class, it is in
> both
> > the STANDARD storage class pool and the HOT pool.
> >
> > STANDARD pool:
> > # rados -p default.rgw.buckets.data ls
> > d86dade5-d401-427b-870a-0670ec3ecb65.385198.4_LICENSE
> >
> > # rados -p default.rgw.buckets.data stat
> > d86dade5-d401-427b-870a-0670ec3ecb65.385198.4_LICENSE
> >
> default.rgw.buckets.data/d86dade5-d401-427b-870a-0670ec3ecb65.385198.4_LICENSE
> > mtime 2021-02-09 14: 54: 14.000000, size 0
> >
> >
> > HOT pool:
> > # rados -p default.rgw.hot.data ls
> >
> d86dade5-d401-427b-870a-0670ec3ecb65.385198.4__shadow_.rmpla1NTgArcUQdSLpW4qEgTDlbhn9f_0
> >
> >
> > # rados -p default.rgw.hot.data stat
> >
> d86dade5-d401-427b-870a-0670ec3ecb65.385198.4__shadow_.rmpla1NTgArcUQdSLpW4qEgTDlbhn9f_0
> >
> default.rgw.hot.data/d86dade5-d401-427b-870a-0670ec3ecb65.385198.4__shadow_.rmpla1NTgArcUQdSLpW4qEgTDlbhn9f_0
> > mtime 2021-02-09 14: 54: 14.000000, size 15220
> >
> > The object itself is in the HOT pool, however it creates this other
> object
> > similar to an index in the STANDARD pool. Monitoring with iostat we
> noticed
> > that this behavior generates an unnecessary IO on disks that do not need
> to
> > be touched.
> >
> > Why this behavior? Are there any ways around it?
>
> this object in the STANDARD pool is called the 'head object', and it
> holds the s3 object's metadata - including an attribute that says
> which storage class the object's data is in
>
> when an S3 client downloads the object with a 'GET /bucket/LICENSE'
> request, it doesn't specify the storage class. so radosgw has to find
> its head object in a known location (the bucket's default storage
> class pool) in order to figure out which pool holds the object's data
>
> >
> > Thanks, Marcelo
> > _______________________________________________
> > 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