Re: About the optimization of rbd object map

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

 



On Mon, Dec 9, 2019 at 8:19 AM Li Wang <laurence.liwang@xxxxxxxxx> wrote:
>
> Hi Jason,
>   If before the first write to object, the object map is updated first
> to indicate
> the object EXIST, what happen if crash occured before the data write, and after
> the object map write, will the map wrongly indicate one object EXIST but in fact
> NOTEXIST. In other words, the map subject to the following semantics,
> if an object

That's not an issue that would result in an object leak or data
corruption. If the object-map flags the object as existing when it
doesn't due to an untimely crash, it will either do an unnecessary
read IO or delete request when removing the image.

> NOTEXIST in map, it REALLY not exist. If an object EXIST in map,
> it not necessarily exist. The read/write to such a object will return ENOENT,
> and the client will read parent/copy up from parent then write, so
> that it is not a problem.
> If the above understanding is correct, how about diff computation,
> will the wrong indication

Yes, it will be wrong for the affected object so your diff will
potentially include an extra object on the delta (but no data
corruption). The object-map can be re-built using the CLI, but there
really shouldn't be a need for such a corner case (that is just
slightly sub-optimal).

> in the map cause a problem.  And, we are wondering what is the negative impacts
> if disabling object map.
>
> Cheers,
> Li Wang
>
> Jason Dillaman <jdillama@xxxxxxxxxx> 于2019年12月6日周五 下午9:56写道:
> >
> > On Thu, Dec 5, 2019 at 11:14 PM Li Wang <laurence.liwang@xxxxxxxxx> wrote:
> > >
> > > Hi Jason,
> > >   We found the synchronous process of object map, which, as a result,
> > > write two objects
> > > every write greatly slow down the first write performance of a newly
> > > created rbd by up to 10x,
> > > which is not acceptable in our scenario, so could we do some
> > > optimizations on it,
> > > for example, batch the map writes or lazy update the map, do we need
> > > maintain accurate
> > > synchronization between the map and the data objects? but after a
> > > glimpse of the librbd codes,
> > > it seems no transactional design for the two objects (map object and
> > > data object) write?
> >
> > If you don't update the object-map before issuing the first write to
> > the associated object, you could crash and therefore the object-map's
> > state is worthless since you couldn't trust it to tell the truth. The
> > cost of object-map is supposed to be amortized over time so the first
> > writes on a new image will incur the performance hits, but future
> > writes do not.
> >
> > The good news is that you are more than welcome to disable
> > object-map/fast-diff if the performance penalty is too great for your
> > application -- it's not a required feature of RBD.
> >
> > >
> > > Cheers,
> > > Li Wang
> > >
> >
> >
> > --
> > Jason
> >
>


--
Jason
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx




[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux