Transaction struct Op

Transaction struct Op

[Dałek, Piotr]

Hello,

In ObjectStore.h we have the following stuct:

    struct Op {
      __le32 op;
      __le32 cid;
      __le32 oid;
      __le64 off;
      __le64 len;
      __le32 dest_cid;
      __le32 dest_oid;                  //OP_CLONE, OP_CLONERANGE
      __le64 dest_off;                  //OP_CLONERANGE
      __le32 hint_type;                 //OP_COLL_HINT
      __le64 expected_object_size;      //OP_SETALLOCHINT
      __le64 expected_write_size;       //OP_SETALLOCHINT
      __le32 split_bits;                //OP_SPLIT_COLLECTION2
      __le32 split_rem;                 //OP_SPLIT_COLLECTION2
    } __attribute__ ((packed)) ;

Some of the fields (like hint_type and split_rem) are totally unused in certain ops, and they eat up space anyway. Maybe we should use unions here, and re-use some of the fields for other purposes? Right now the structure is 72 bytes in size, and for most ops, at least 32 bytes are always wasted. 


With best regards / Pozdrawiam
Piotr Dałek

Re: Transaction struct Op

[Haomai Wang]

Yes, some fields only used for special ops. But union may increase the
complexity of stuct.

And the extra memory may not a problem because "Ops"  in one
transaction should be within ten.

On Thu, Jul 2, 2015 at 10:05 PM, Dałek, Piotr
<Piotr.Dalek@ts.fujitsu.com> wrote:
> Hello,
>
> In ObjectStore.h we have the following stuct:
>
>     struct Op {
>       __le32 op;
>       __le32 cid;
>       __le32 oid;
>       __le64 off;
>       __le64 len;
>       __le32 dest_cid;
>       __le32 dest_oid;                  //OP_CLONE, OP_CLONERANGE
>       __le64 dest_off;                  //OP_CLONERANGE
>       __le32 hint_type;                 //OP_COLL_HINT
>       __le64 expected_object_size;      //OP_SETALLOCHINT
>       __le64 expected_write_size;       //OP_SETALLOCHINT
>       __le32 split_bits;                //OP_SPLIT_COLLECTION2
>       __le32 split_rem;                 //OP_SPLIT_COLLECTION2
>     } __attribute__ ((packed)) ;
>
> Some of the fields (like hint_type and split_rem) are totally unused in certain ops, and they eat up space anyway. Maybe we should use unions here, and re-use some of the fields for other purposes? Right now the structure is 72 bytes in size, and for most ops, at least 32 bytes are always wasted.
>
>
> With best regards / Pozdrawiam
> Piotr Dałek
>
>



-- 
Best Regards,

Wheat
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Transaction struct Op

[Dałek, Piotr]

> -----Original Message-----
> From: Haomai Wang [mailto:haomaiwang@gmail.com]
> Sent: Thursday, July 02, 2015 7:26 PM
> 
> Yes, some fields only used for special ops. But union may increase the
> complexity of stuct.

Not by that much, actual changes would be only in coding and encoding, rest of the code should remain the same.
 
> And the extra memory may not a problem because "Ops"  in one transaction
> should be within ten.

This equals to at least around 720 bytes that must be stored in RAM and transferred through the wire. 

With best regards / Pozdrawiam
Piotr Dałek

Re: Transaction struct Op

[Matt W. Benjamin]

I tend to support (++)

----- "Piotr Dałek" <Piotr.Dalek@ts.fujitsu.com> wrote:

> > -----Original Message-----
> > From: Haomai Wang [mailto:haomaiwang@gmail.com]
> > Sent: Thursday, July 02, 2015 7:26 PM
> > 
> > Yes, some fields only used for special ops. But union may increase
> the
> > complexity of stuct.
> 
> Not by that much, actual changes would be only in coding and encoding,
> rest of the code should remain the same.
>  
> > And the extra memory may not a problem because "Ops"  in one
> transaction
> > should be within ten.
> 
> This equals to at least around 720 bytes that must be stored in RAM
> and transferred through the wire. 
> 
> With best regards / Pozdrawiam
> Piotr Dałek
> N�����r��y���b�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w������j:+v���w�j�m��������zZ+��ݢj"��

-- 
Matt Benjamin
CohortFS, LLC.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://cohortfs.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309 
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html