[sheepdog] [PATCH v4 5/7] upgrade 'idx' in object_cache from 32bit to 64bit

[Robin Dong]

2013/11/1 Liu Yuan <namei.unix at gmail.com>

> On Fri, Nov 01, 2013 at 06:03:40PM +0800, Robin Dong wrote:
> > Change 'idx' in object cache from uint32_t to uint64_t for working
> correctly
> > on hyper volume.
> >
> > Signed-off-by: Robin Dong <sanbai at taobao.com>
> > ---
> >  include/sheepdog_proto.h |    2 +-
> >  sheep/object_cache.c     |   97
> +++++++++++++++++++++++----------------------
> >  2 files changed, 51 insertions(+), 48 deletions(-)
> >
> > diff --git a/include/sheepdog_proto.h b/include/sheepdog_proto.h
> > index 62969d2..d6337b5 100644
> > --- a/include/sheepdog_proto.h
> > +++ b/include/sheepdog_proto.h
> > @@ -419,7 +419,7 @@ static inline uint64_t vid_to_vdi_oid(uint32_t vid)
> >       return VDI_BIT | ((uint64_t)vid << VDI_SPACE_SHIFT);
> >  }
> >
> > -static inline uint64_t vid_to_data_oid(uint32_t vid, uint32_t idx)
> > +static inline uint64_t vid_to_data_oid(uint32_t vid, uint64_t idx)
> >  {
> >       return ((uint64_t)vid << VDI_SPACE_SHIFT) | idx;
> >  }
> > diff --git a/sheep/object_cache.c b/sheep/object_cache.c
> > index e1968fc..ae4a103 100644
> > --- a/sheep/object_cache.c
> > +++ b/sheep/object_cache.c
> > @@ -16,15 +16,16 @@
> >  /*
> >   * Object Cache ID
> >   *
> > - *  0 - 19 (20 bits): data object space
> > - *  20 - 27 (8 bits): object flag space
> > - *  28 - 31 (4 bits): object type indentifier space
> > + *  0 - 31 (32 bits): data object space
> > + *  32 - 51 (20 bits): reserved
> > + *  52 - 59 (8 bits): object flag space
> > + *  60 - 63 (4 bits): object type indentifier space
> >   */
> > -#define CACHE_VDI_SHIFT       31 /* if the entry is identified as VDI
> object */
> > -#define CACHE_CREATE_SHIFT    27 /* If the entry should be created at
> backend */
> > +#define CACHE_VDI_SHIFT       63 /* if the entry is identified as VDI
> object */
> > +#define CACHE_CREATE_SHIFT    59 /* If the entry should be created at
> backend */
> >
> > -#define CACHE_VDI_BIT         (UINT32_C(1) << CACHE_VDI_SHIFT)
> > -#define CACHE_CREATE_BIT      (UINT32_C(1) << CACHE_CREATE_SHIFT)
> > +#define CACHE_VDI_BIT         (UINT64_C(1) << CACHE_VDI_SHIFT)
> > +#define CACHE_CREATE_BIT      (UINT64_C(1) << CACHE_CREATE_SHIFT)
> >
> >  #define CACHE_INDEX_MASK      (CACHE_CREATE_BIT)
> >
> > @@ -39,7 +40,7 @@ struct global_cache {
> >  };
> >
> >  struct object_cache_entry {
> > -     uint32_t idx; /* Index of this entry */
> > +     uint64_t idx; /* Index of this entry */
> >       refcnt_t refcnt; /* Reference count of this entry */
> >       uint64_t bmap; /* Each bit represents one dirty block in object */
> >       struct object_cache *oc; /* Object cache this entry belongs to */
> > @@ -97,7 +98,7 @@ static inline int hash(uint64_t vid)
> >  }
> >
> >  /* We should always use this helper to get entry idx */
> > -static inline uint32_t entry_idx(const struct object_cache_entry *entry)
> > +static inline uint64_t entry_idx(const struct object_cache_entry *entry)
> >  {
> >       return entry->idx & ~CACHE_INDEX_MASK;
> >  }
> > @@ -108,15 +109,15 @@ static int object_cache_cmp(const struct
> object_cache_entry *a,
> >       return intcmp(entry_idx(a), entry_idx(b));
> >  }
> >
> > -static inline uint32_t object_cache_oid_to_idx(uint64_t oid)
> > +static inline uint64_t object_cache_oid_to_idx(uint64_t oid)
> >  {
> > -     uint32_t idx = data_oid_to_idx(oid);
> > +     uint64_t idx = data_oid_to_idx(oid);
> >       if (is_vdi_obj(oid))
> > -             idx |= 1 << CACHE_VDI_SHIFT;
> > +             idx |= 1ULL << CACHE_VDI_SHIFT;
> >       return idx;
> >  }
>
> I guess you need to handle bnode object too. For now seems to me that
> vdi_btree_obj and data objects with the same index will overwrite each
> other.
>
>
VDI_BTREE_BIT is in 60th bit, and the CACHE_VDI_SHIFT is in 63th bit, why
they will overwrite each other.


> Thanks
> Yuan
>



-- 
--
Best Regard
Robin Dong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20131104/85983ad4/attachment-0004.html>