I am posting to get wider review/feedback on this draft design. In support of
the RBD mirroring feature [1], a new client-side journaling class will be
developed for use by librbd. The implementation is designed to carry opaque
journal entry payloads so it will be possible to be re-used in oth
On Tue, Jun 2, 2015 at 8:11 AM, Jason Dillaman wrote:
> I am posting to get wider review/feedback on this draft design. In support
> of the RBD mirroring feature [1], a new client-side journaling class will be
> developed for use by librbd. The implementation is designed to carry opaque
> jou
On 02/06/2015 16:11, Jason Dillaman wrote:
I am posting to get wider review/feedback on this draft design. In support of
the RBD mirroring feature [1], a new client-side journaling class will be
developed for use by librbd. The implementation is designed to carry opaque
journal entry paylo
> > In contrast to the current journal code used by CephFS, the new journal
> > code will use sequence numbers to identify journal entries, instead of
> > offsets within the journal.
>
> Am I misremembering what actually got done with our journal v2 format?
> I think this is done — or at least we
> > A new journal object class method will be used to submit journal entry
> > append requests. This will act as a gatekeeper for the concurrent client
> > case. A successful append will indicate whether or not the journal is now
> > full (larger than the max object size), indicating to the clien
On Wed, Jun 3, 2015 at 9:13 AM, Jason Dillaman wrote:
>> > In contrast to the current journal code used by CephFS, the new journal
>> > code will use sequence numbers to identify journal entries, instead of
>> > offsets within the journal.
>>
>> Am I misremembering what actually got done with our
> >> >A successful append will indicate whether or not the journal is now full
> >> >(larger than the max object size), indicating to the client that a new
> >> >journal object should be used. If the journal is too large, an error
> >> >code
> >> >responce would alert the client that it needs to w
On Thu, Jun 4, 2015 at 8:08 AM, Jason Dillaman wrote:
>> >> >A successful append will indicate whether or not the journal is now full
>> >> >(larger than the max object size), indicating to the client that a new
>> >> >journal object should be used. If the journal is too large, an error
>> >> >co
> >> ...Actually, doesn't *not* forcing a coordinated move from one object
> >> set to another mean that you don't actually have an ordering guarantee
> >> across tags if you replay the journal objects in order?
> >
> > The ordering between tags was meant to be a soft ordering guarantee (since
> >
On Thu, Jun 4, 2015 at 5:36 PM, Jason Dillaman wrote:
>> >> ...Actually, doesn't *not* forcing a coordinated move from one object
>> >> set to another mean that you don't actually have an ordering guarantee
>> >> across tags if you replay the journal objects in order?
>> >
>> > The ordering betwee
> I must not be being clear. Tell me if this scenario is possible:
>
> * Client A writes to file foo many times and it is journaled to object set 1.
> * Client B writes to file bar many times and it starts journaling to
> object set 1, but hits the end and moves on to object set 2.
> * Client A hi
On Tue, Jun 9, 2015 at 12:08 PM, Jason Dillaman wrote:
>> I must not be being clear. Tell me if this scenario is possible:
>>
>> * Client A writes to file foo many times and it is journaled to object set 1.
>> * Client B writes to file bar many times and it starts journaling to
>> object set 1, bu
12 matches
Mail list logo
