RE: What should be in the next hammer/firefly release ?

[Miyamae, Takeshi]

Hi Loic,

It's not strange that you worry about that since we have committed lots of pull 
requests
into the main trunk so far.
However, we are considering each pull request already committed was either a 
bug fix or
a performance improvement, so we believe we are qualified to backport them into 
hammer.
Anyway, we tried to backport it on our local repository in order to decide 
whether it's feasible
or not and felt that it's not so difficult although we had to resolve a little 
complicated conflicts.
In addition, we could have selected only local commits in shec directory and 
avoided
changing any erasure code I/F.
Here is the result of our backport trial.

https://github.com/t-miyamae/ceph/commits/hammer

We are very glad if you could check it out and let us know your opinion after 
that.
We are testing it on our cluster for a couple of days in parallel.

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Thursday, September 10, 2015 8:12 PM
To: Miyamae, Takeshi/宮前 剛; Ceph Development
Cc: Von-Stamwitz, Paul; Toshine, Naoyoshi/利根 直佳; Shiozawa, Kensuke/塩沢 賢輔; 
Nakao, Takanori/中尾 鷹詔
Subject: Re: What should be in the next hammer/firefly release ?

Hi,

Since SHEC really is a new feature in Infernalis (because it was experimental 
before), I'll leave it to Sam and Sage to decide if it's relevant to backport 
to Hammer. Note that it depends on changes in the erasure code base that extend 
to all plugins. Backporting would unfortunately not be as simple as 
cherry-picking the commits modifying the shec directories.

Cheers

On 10/09/2015 12:57, Miyamae, Takeshi wrote:
> Hi Loic,
> 
> As the last pull request #5257 was committed into the main trunk, we 
> believe all the SHEC codes in main trunk are ready to be backported into 
> Hammer branch.
> What can we do at this moment?
> 
> Best regards,
> Takeshi Miyamae
> 
> -----Original Message-
> From: Miyamae, Takeshi/宮前 剛
> Sent: Thursday, September 3, 2015 4:09 PM
> To: 'ceph-devel-ow...@vger.kernel.org'
> Cc: Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com); Toshine, 
> Naoyoshi/利根 直佳; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔 
> (nakao.takan...@jp.fujitsu.com)
> Subject: Re: What should be in the next hammer/firefly release ?
> 
> Dear Loic,
> 
> We would like to let following two patches be backported to hammer v0.94.4.
> (And our wish is finally backporting these patches to RHCS v1.3.) Can it be 
> possible? If possible, please let us know what should be started at first.
> (Caution: #5257 has not been committed to master branch yet.)
> 
> erasure-code: shec plugin feature #5493
> https://github.com/ceph/ceph/pull/5493
> 
> erasure code: shec performance optimization by decoding cache #5257
> https://github.com/ceph/ceph/pull/5257
> 
> Best regards,
> Takeshi Miyamae
> 
> -Original Message-
> From: Loic Dachary  dachary.org>
> Subject: What should be in the next hammer/firefly release ?
> Newsgroups: gmane.comp.file-systems.ceph.devel
> Date: 2015-09-02 11:00:53 GMT (15 hours and 32 minutes ago) Hi,
> 
> I added a link to
> 
> http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO#Overview-of-
> the-backports-in-progress
> 
> to show all issues that should be in the next point release for
> 
> hammer v0.94.4 : http://tracker.ceph.com/versions/495
> firefly v0.80.11 : http://tracker.ceph.com/versions/480
> 
> Cheers
> 
> --
> Loïc Dachary, Artisan Logiciel Libre
> N r  y   b X  ǧv ^ )޺{.n +   z ]z   {ay ʇڙ ,j   f   h   z  w   
   j:+v   w j m zZ+ ݢj"  !tml=
> 

--
Loïc Dachary, Artisan Logiciel Libre

RE: shec tests failure on i386

[Miyamae, Takeshi]

Hi Loic,

Thank you for testing shec on i386 and telling us about the issue.
We will try to reproduce the issue on our own virtual machines for now.

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Tuesday, September 15, 2015 5:02 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development
Subject: shec tests failure on i386

Hi Takeshi,

http://tracker.ceph.com/issues/12936 shows that shec tests fail on i386. Before 
I investigate further, I'd like to know if you had a chance to run more tests ? 
There are not many users of i386 these days, of course ;-) But this is a good 
test to verify there are no architecture related problems.

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: Re: What should be in the next hammer/firefly release ?

[Miyamae, Takeshi]

Hi Loic,

As the last pull request #5257 was committed into the main trunk,
we believe all the SHEC codes in main trunk are ready to be backported into 
Hammer branch.
What can we do at this moment?

Best regards,
Takeshi Miyamae

-Original Message-
From: Miyamae, Takeshi/宮前 剛 
Sent: Thursday, September 3, 2015 4:09 PM
To: 'ceph-devel-ow...@vger.kernel.org'
Cc: Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com); Toshine, Naoyoshi/利根 直佳; 
Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔 (nakao.takan...@jp.fujitsu.com)
Subject: Re: What should be in the next hammer/firefly release ?

Dear Loic,

We would like to let following two patches be backported to hammer v0.94.4.
(And our wish is finally backporting these patches to RHCS v1.3.) Can it be 
possible? If possible, please let us know what should be started at first.
(Caution: #5257 has not been committed to master branch yet.)

erasure-code: shec plugin feature #5493
https://github.com/ceph/ceph/pull/5493

erasure code: shec performance optimization by decoding cache #5257
https://github.com/ceph/ceph/pull/5257

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary  dachary.org>
Subject: What should be in the next hammer/firefly release ?
Newsgroups: gmane.comp.file-systems.ceph.devel
Date: 2015-09-02 11:00:53 GMT (15 hours and 32 minutes ago) Hi,

I added a link to

http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO#Overview-of-the-backports-in-progress

to show all issues that should be in the next point release for

hammer v0.94.4 : http://tracker.ceph.com/versions/495
firefly v0.80.11 : http://tracker.ceph.com/versions/480

Cheers

--
Loïc Dachary, Artisan Logiciel Libre

RE: Erasure Code Plugins : PLUGINS_V3 feature

[Miyamae, Takeshi]

Hi Loic,

Thank you for arranging PLUGINS_V3 feature.
I had just started to review pull request #5493. Please wait just a moment.

By the way, may I ask what kind of status #5257 (decoding cache:
the last immediate request from SHEC) currently is?
https://github.com/ceph/ceph/pull/5257
Tell us if we need to rebase again.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Thursday, August 6, 2015 10:58 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
Subject: Re: Erasure Code Plugins : PLUGINS_V3 feature

Hi Takeshi,

https://github.com/ceph/ceph/pull/5493 is ready for your review. The matching 
integration tests can be found at https://github.com/ceph/ceph-qa-suite/pull/523

Cheers

On 06/08/2015 02:28, Miyamae, Takeshi wrote:
 Dear Sage,
 
 note that what this really means is that the on-disk encoding needs to 
 remain fixed.
 
 Thank you for letting us know the important notice.
 We have no plan to change shec's format at this moment, but we will 
 remember the comment for any future events.
 
 Best Regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Sage Weil [mailto:sw...@redhat.com]
 Sent: Thursday, August 6, 2015 3:45 AM
 To: Loic Dachary; Miyamae, Takeshi/宮前 剛
 Cc: Samuel Just; Ceph Development
 Subject: Re: Erasure Code Plugins : PLUGINS_V3 feature
 
 On Wed, 5 Aug 2015, Loic Dachary wrote:
 Hi Sam,

 How does this proposal sound ? It would be great if that was done 
 before the feature freeze.
 
 I think it's a good time.
 
 Takeshi, note that what this really means is that the on-disk encoding needs 
 to remain fixed.  If we decide to change it down the line, we'll have to make 
 a 'shec2' or similar so that the old format is still decodable (or ensure 
 that existing data can still be read in some other way).
 
 Sound good?
 
 sage
 
 

 Cheers

 On 29/07/2015 11:16, Loic Dachary wrote:
 Hi Sam,

 The SHEC plugin[0] has been running in the rados runs[1] in the past few 
 months. It also has a matching corpus verification which runs on every make 
 check[2] as well as its optimized variants. I believe the flag 
 experimental can now be removed. 

 In order to do so, we need to use a PLUGINS_V3 feature, in the same way we 
 did back in Giant when the ISA and LRC plugins were introduced[3]. This 
 won't be necessary in the future, when there is a generic plugin mechanism, 
 but right now that's what we need. It would be a commit very similar to the 
 one implementing PLUGINS_V2[4].

 Is this agreeable to you ? Or would you rather see another way to resolve 
 this ?

 Cheers

 [0] https://github.com/ceph/ceph/tree/master/src/erasure-code/shec
 [1]
 https://github.com/ceph/ceph-qa-suite/tree/master/suites/rados/thras
 h-erasure-code-shec [2]
 https://github.com/ceph/ceph-erasure-code-corpus/blob/master/v0.92-9
 88/non-regression.sh#L52 [3] http://tracker.ceph.com/issues/9343
 [4]
 https://github.com/ceph/ceph/commit/9687150ceac9cc7e506bc227f430d420
 7a6d7489


 --
 Loïc Dachary, Artisan Logiciel Libre



-- 
Loïc Dachary, Artisan Logiciel Libre

N�r��yb�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: Erasure Code Plugins : PLUGINS_V3 feature

[Miyamae, Takeshi]

Dear Sage,

 note that what this really means is that the on-disk encoding needs to remain 
 fixed.

Thank you for letting us know the important notice.
We have no plan to change shec's format at this moment, but we will remember the
comment for any future events.

Best Regards,
Takeshi Miyamae

-Original Message-
From: Sage Weil [mailto:sw...@redhat.com] 
Sent: Thursday, August 6, 2015 3:45 AM
To: Loic Dachary; Miyamae, Takeshi/宮前 剛
Cc: Samuel Just; Ceph Development
Subject: Re: Erasure Code Plugins : PLUGINS_V3 feature

On Wed, 5 Aug 2015, Loic Dachary wrote:
 Hi Sam,
 
 How does this proposal sound ? It would be great if that was done 
 before the feature freeze.

I think it's a good time.

Takeshi, note that what this really means is that the on-disk encoding needs to 
remain fixed.  If we decide to change it down the line, we'll have to make a 
'shec2' or similar so that the old format is still decodable (or ensure that 
existing data can still be read in some other way).

Sound good?

sage


 
 Cheers
 
 On 29/07/2015 11:16, Loic Dachary wrote:
  Hi Sam,
  
  The SHEC plugin[0] has been running in the rados runs[1] in the past few 
  months. It also has a matching corpus verification which runs on every make 
  check[2] as well as its optimized variants. I believe the flag 
  experimental can now be removed. 
  
  In order to do so, we need to use a PLUGINS_V3 feature, in the same way we 
  did back in Giant when the ISA and LRC plugins were introduced[3]. This 
  won't be necessary in the future, when there is a generic plugin mechanism, 
  but right now that's what we need. It would be a commit very similar to the 
  one implementing PLUGINS_V2[4].
  
  Is this agreeable to you ? Or would you rather see another way to resolve 
  this ?
  
  Cheers
  
  [0] https://github.com/ceph/ceph/tree/master/src/erasure-code/shec
  [1] 
  https://github.com/ceph/ceph-qa-suite/tree/master/suites/rados/thras
  h-erasure-code-shec [2] 
  https://github.com/ceph/ceph-erasure-code-corpus/blob/master/v0.92-9
  88/non-regression.sh#L52 [3] http://tracker.ceph.com/issues/9343
  [4] 
  https://github.com/ceph/ceph/commit/9687150ceac9cc7e506bc227f430d420
  7a6d7489
  
 
 --
 Loïc Dachary, Artisan Logiciel Libre
 
 

RE: teuthology timeout error

[Miyamae, Takeshi]

Hi Loic,

We rebased our teuthology/ceph-qa-suite and retried the test toward LRC on 
current master.
However, we unfortunately got the same result as before (timeout error).

[test conditions]
Target : Ceph-9.0.0-971-gd49d816
https://github.com/kawaguchi-s/teuthology
https://github.com/kawaguchi-s/ceph-qa-suite/tree/wip-10886-lrc

[teuthology log]

2015-05-25 10:18:23 # start

2015-05-25 11:59:52,106.106 INFO:teuthology.orchestra.run.RX35-1:Running: 
'adjust-ulimits ceph-coverage /home/ubuntu/cephtest/archive/coverage ceph 
status -- format=json-pretty'
2015-05-25 11:59:52,564.564 INFO:tasks.ceph.ceph_manager:no progress seen, 
keeping timeout for now
2015-05-25 11:59:52,565.565 INFO:tasks.thrashosds.thrasher:Traceback (most 
recent call last):
  File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 635, in 
wrapper
return func(self)
  File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 668, in 
do_thrash
timeout=self.config.get('timeout')
  File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 1569, in 
wait_for_recovery
'failed to recover before timeout expired'
AssertionError: failed to recover before timeout expired

Traceback (most recent call last):
  File 
/root/work/teuthology/virtualenv/lib/python2.7/site-packages/gevent/greenlet.py,
 line 390, in run
result = self._run(*self.args, **self.kwargs)
  File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 635, in 
wrapper
return func(self)
  File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 668, in 
do_thrash
timeout=self.config.get('timeout')
  File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 1569, in 
wait_for_recovery
'failed to recover before timeout expired'
AssertionError: failed to recover before timeout expired Greenlet at 
0x36cacd0: bound method Thrasher.do_thrash of tasks.ceph_manager.Thrasher 
instance at 0x36df3f8 failed with AssertionError

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Thursday, May 21, 2015 6:38 PM
To: Miyamae, Takeshi/宮前 剛; Ceph Development
Cc: Kawaguchi, Shotaro/川口 翔太朗; Imai, Hiroki/今井 宏樹; Nakao, Takanori/中尾 鷹詔; 
Shiozawa, Kensuke/塩沢 賢輔
Subject: Re: teuthology timeout error

Hi,

[sorry the previous mail was sent by accident, here is the full mail]

On 21/05/2015 10:32, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Could you please share the teuthology/ceph-qa-suite repository you 
 are using to run these tests so I can try to reproduce / diagnose the 
 problem ?
 
 https://github.com/kawaguchi-s/teuthology/tree/wip-10886
 https://github.com/kawaguchi-s/ceph-qa-suite/tree/wip-10886
 

When compared against master they show differences that indicate it would be 
good to rebase:

https://github.com/ceph/teuthology/compare/master...kawaguchi-s:wip-10886
https://github.com/ceph/ceph-qa-suite/compare/master...kawaguchi-s:wip-10886

I think the teuthology commit on top of wip-10886 is a mistake

https://github.com/kawaguchi-s/teuthology/commit/348e54931f89c9b0ae7a84eb931576f8414017b5

do you really need to modify teuthology ? It should just be necessary to use 
the latest master branch.

It looks like the

https://github.com/kawaguchi-s/ceph-qa-suite/commit/f2e3ca5d12ceef742eae2a9cf4057c436e9040c3

commit in your ceph-qa-suite is not what you intended. However

https://github.com/kawaguchi-s/ceph-qa-suite/commit/4b39d6d4862f9091a849d224e880795be406815d
https://github.com/kawaguchi-s/ceph-qa-suite/commit/d16b4b058ae118931928541a2c8acd68f9703a44

look ok :-) Instead of naming the test 4nodes16osds3mons1client.yaml it would 
be better to use the same kind of naming you see at 
https://github.com/ceph/ceph-qa-suite/tree/master/suites/rados/thrash-erasure-code/workloads.
 That is a file name made of the distinctive parameters for the shec plugin 
(the parameters that are the default can be omited).

Cheers

 Here are our teuthology/ceph-qa-suite repositories. Thanks in advance.
 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Wednesday, May 20, 2015 4:49 PM
 To: Miyamae, Takeshi/宮前 剛; Ceph Development
 Cc: Kawaguchi, Shotaro/川口 翔太朗; Imai, Hiroki/今井 宏樹; Nakao, Takanori/中尾 
 鷹詔; Shiozawa, Kensuke/塩沢 賢輔
 Subject: Re: teuthology timeout error
 
 Hi,
 
 On 20/05/2015 04:20, Miyamae, Takeshi wrote:
 Hi Loic,

 When we fixed our own issue and restarted teuthology,
 
 Great !
 
 we encountered another issue (timeout error) which occurs in case of LRC as 
 well.
 Do you have any information about that ?
 
 Could you please share the teuthology/ceph-qa-suite repository you are using 
 to run these tests so I can try to reproduce / diagnose the problem ?
 
 Thanks
 

 [error messages (in case of LRC pool)]

 2015-04-28 12:38:54,128.128 INFO:teuthology.orchestra.run.RX35-1:Running: 
 'adjust-ulimits ceph-coverage /home/ubuntu/cephtest/archive/coverage ceph 
 status --format=json-pretty'
 2015-04-28 12:38:54,516.516

RE: teuthology timeout error

[Miyamae, Takeshi]

Hi Loic,

 Could you please share the teuthology/ceph-qa-suite repository you are using 
 to run these tests
 so I can try to reproduce / diagnose the problem ?

https://github.com/kawaguchi-s/teuthology/tree/wip-10886
https://github.com/kawaguchi-s/ceph-qa-suite/tree/wip-10886

Here are our teuthology/ceph-qa-suite repositories. Thanks in advance.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Wednesday, May 20, 2015 4:49 PM
To: Miyamae, Takeshi/宮前 剛; Ceph Development
Cc: Kawaguchi, Shotaro/川口 翔太朗; Imai, Hiroki/今井 宏樹; Nakao, Takanori/中尾 鷹詔; 
Shiozawa, Kensuke/塩沢 賢輔
Subject: Re: teuthology timeout error

Hi,

On 20/05/2015 04:20, Miyamae, Takeshi wrote:
 Hi Loic,
 
 When we fixed our own issue and restarted teuthology, 

Great !

 we encountered another issue (timeout error) which occurs in case of LRC as 
 well.
 Do you have any information about that ?

Could you please share the teuthology/ceph-qa-suite repository you are using to 
run these tests so I can try to reproduce / diagnose the problem ?

Thanks

 
 [error messages (in case of LRC pool)]
 
 2015-04-28 12:38:54,128.128 INFO:teuthology.orchestra.run.RX35-1:Running: 
 'adjust-ulimits ceph-coverage /home/ubuntu/cephtest/archive/coverage ceph 
 status --format=json-pretty'
 2015-04-28 12:38:54,516.516 INFO:tasks.ceph.ceph_manager:no progress seen, 
 keeping timeout for now
 2015-04-28 12:38:54,516.516 INFO:tasks.thrashosds.thrasher:Traceback (most 
 recent call last):
   File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 632, in 
 wrapper
 return func(self)
   File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 665, in 
 do_thrash
 timeout=self.config.get('timeout')
   File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 1566, in 
 wait_for_recovery
 'failed to recover before timeout expired'
 AssertionError: failed to recover before timeout expired
 
 Traceback (most recent call last):
   File 
 /root/work/teuthology/virtualenv/lib/python2.7/site-packages/gevent/greenlet.py,
  line 390, in run
 result = self._run(*self.args, **self.kwargs)
   File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 632, in 
 wrapper
 return func(self)
   File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 665, in 
 do_thrash
 timeout=self.config.get('timeout')
   File /root/src/ceph-qa-suite_master/tasks/ceph_manager.py, line 1566, in 
 wait_for_recovery
 'failed to recover before timeout expired'
 AssertionError: failed to recover before timeout expired Greenlet at 
 0x2a7d550: bound method Thrasher.do_thrash of tasks.ceph_manager.Thrasher 
 instance at 0x2bd12d8 failed with AssertionError
 
 [ceph version]
 0.93-952-gfe28daa
 
 [teuthology, ceph-qa-suite]
 newest version at 3/25/2015
 
 [configurations]
   check-locks: false
   overrides:
 ceph:
   conf:
 global:
   ms inject socket failures: 5000
 osd:
   osd heartbeat use min delay socket: true
   osd sloppy crc: true
   fs: xfs
   roles:
   - - mon.a
 - osd.0
 - osd.4
 - osd.8
 - osd.12
   - - mon.b
 - osd.1
 - osd.5
 - osd.9
 - osd.13
   - - mon.c
 - osd.2
 - osd.6
 - osd.10
 - osd.14
   - - osd.3
 - osd.7
 - osd.11
 - osd.15
 - client.0
   targets:
 ubu...@rx35-1.primary.ceph-poc.fsc.net:
 ubu...@rx35-2.primary.ceph-poc.fsc.net:
 ubu...@rx35-3.primary.ceph-poc.fsc.net:
 ubu...@rx35-4.primary.ceph-poc.fsc.net:
   tasks:
   - ceph:
   conf:
 osd:
   osd debug reject backfill probability: 0.3
   osd max backfills: 1
   osd scrub max interval: 120
   osd scrub min interval: 60
   log-whitelist:
   - wrongly marked me down
   - objects unfound and apparently lost
   - thrashosds:
   chance_pgnum_grow: 1
   chance_pgpnum_fix: 1
   min_in: 4
   timeout: 1200
   - rados:
   clients:
   - client.0
   ec_pool: true
   erasure_code_profile:
 k: 4
 l: 3
 m: 2
 name: lrcprofile
 plugin: lrc
 ruleset-failure-domain: osd
   objects: 50
   op_weights:
 append: 100
 copy_from: 50
 delete: 50
 read: 100
 rmattr: 25
 rollback: 50
 setattr: 25
 snap_create: 50
 snap_remove: 50
 write: 0
   ops: 19
 
 Best regards,
 Takeshi Miyamae
 

-- 
Loïc Dachary, Artisan Logiciel Libre

Teuthology tests for SHEC

[Miyamae, Takeshi]

Dear Loic,

We have just let teuthology work on our local cluster at last.
If six nodes are enough to provide qualified results, we will continue the 
teuthology tests
on our cluster. How many nodes are required at least for such kind of purpose ?
And then, we will use a local branch as a test target until #4132 will be 
merged.

Best regards,
Takeshi Miyamae

RE: conditions for removing experimental feature marks

[Miyamae, Takeshi]

Dear Loic,

Thank you for your reply.
The timeline chart is really smart, and I understand what you meant perfectly.
We will prepare pull requests against master at first.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Thursday, March 19, 2015 7:07 PM
To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Kaga, Yoshihiro/加賀 芳宏; 
Kawaguchi, Shotaro/川口 翔太朗
Subject: Re: conditions for removing experimental feature marks



On 19/03/2015 09:50, Miyamae, Takeshi wrote:
 Dear Loic,
 
 Thank you for your reply, and I mostly understand what you meant about commit 
 policy.
 By the way, may I ask a question about the hammer releases ?
 Are these two releases,
 1. We are very close to the release you commented in pull request 
 #4083 and 2. backported later to hammer for the next point release 
 you mentioned below, different ?

Hopefully the following will illustrate what I meant : 
http://ceph.com/docs/master/releases/ In a short while the Hammer release 
will be published. In the same way the Firefly was released back in May 2014. 
You can see that after Firefly was released, point releases were published 
(0.80.1, 0.80.2 etc.) on a regular basis. They include bug fixes and sometime 
optimizations that make a significant difference for people running the stable 
release in production. 

I think the performance improvement you proposed is a good candidate to be 
published in the next Hammer point release.

Please let me know if that's still unclear, I'd be happy to explain. The 
release process is being documented and it's a good to verify if it actually is 
understandable ;-)

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Thursday, March 19, 2015 4:16 PM
 To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
 Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Kaga, Yoshihiro/加賀 
 芳宏; Kawaguchi, Shotaro/川口 翔太朗
 Subject: Re: conditions for removing experimental feature marks
 
 Hi,
 
 On 19/03/2015 03:20, Miyamae, Takeshi wrote:
 Dear Loic,

 We are struggling with teuthology, but we must commit SHEC's recent 
 patches including Intel sse4 optimization into Hammer before that.
 
 I'd be happy to help, do you have specific questions ?
 
 erasure code: fix shec performance/coding style issues #4083
 https://github.com/ceph/ceph/pull/4083
 
 I think we need to split this pull request in three pull requests: 
 
 * the performance optimization can go to master (and backported later 
 to hammer for the next point release)
 * the bug fix should be against hammer and be backported later to 
 hammer
 * the coding style cleanup should be against master and preferably 
 after any change that you'd like to backport to hammer because it 
 makes it a little more difficult to backport code
 
 Could you check the above pull request, please ?
 Almost all of the modifications are for SHEC plugin's file except for 
 some other document files.
 
 Cheers
 

 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Tuesday, March 10, 2015 11:25 PM
 To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
 Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Kaga, 
 Yoshihiro/加賀
 芳宏; Kawaguchi, Shotaro/川口 翔太朗
 Subject: Re: conditions for removing experimental feature marks

 Hi !

 On 10/03/2015 11:35, Miyamae, Takeshi wrote:
 Dear Loic,

 I really apologize that our reply is too late.
 Since removing experimental flag from SHEC at v0.94 is our immediate 
 hope, we should have started any actions for that earlier.

 No worries, it's never too late to do good :-)

 By the way, you mean we must add just the same workaround as 10887 
 for SHEC if our target is Hammer.
 Is my understanding correct ?

 What is needed is integration tests running during a few weeks and showing 
 the plugin behaves well. 

 Running teuthology locally is non trivial, maybe we can provide you 
 with access to the community lab so that you can run teuthology 
 suites against the existing teuthology cluster (i.e. 
 http://pulpito.ceph.com/). Would you like me to ask ?

 Thank you for your proposal.
 It would be greatly helpful if we were allowed to use it !

 Could you please connect to irc.oftc.net#sepia ? This is the IRC channel 
 where lab related matters are discussed. We can figure out the details 
 there. 

 In the meantime you can try teuthology and write a single test quite easily, 
 on your local machine. The tricky part comes where we want to run suites 
 with large number of jobs. You can adapt the instructions from 
 http://dachary.org/?p=2204 to your local environment. All you need really is 
 the ability to run two virtual machines.

 Cheers


 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Monday, February 16, 2015 6:17 PM
 To: Miyamae

RE: conditions for removing experimental feature marks

[Miyamae, Takeshi]

Dear Loic,

Thank you for your reply, and I mostly understand what you meant about commit 
policy.
By the way, may I ask a question about the hammer releases ?
Are these two releases,
1. We are very close to the release you commented in pull request #4083
and
2. backported later to hammer for the next point release you mentioned below,
different ?

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Thursday, March 19, 2015 4:16 PM
To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Kaga, Yoshihiro/加賀 芳宏; 
Kawaguchi, Shotaro/川口 翔太朗
Subject: Re: conditions for removing experimental feature marks

Hi,

On 19/03/2015 03:20, Miyamae, Takeshi wrote:
 Dear Loic,
 
 We are struggling with teuthology, but we must commit SHEC's recent 
 patches including Intel sse4 optimization into Hammer before that.

I'd be happy to help, do you have specific questions ?

 erasure code: fix shec performance/coding style issues #4083
 https://github.com/ceph/ceph/pull/4083

I think we need to split this pull request in three pull requests: 

* the performance optimization can go to master (and backported later to hammer 
for the next point release)
* the bug fix should be against hammer and be backported later to hammer
* the coding style cleanup should be against master and preferably after any 
change that you'd like to backport to hammer because it makes it a little more 
difficult to backport code

 Could you check the above pull request, please ?
 Almost all of the modifications are for SHEC plugin's file except for 
 some other document files.

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Tuesday, March 10, 2015 11:25 PM
 To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
 Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Kaga, Yoshihiro/加賀 
 芳宏; Kawaguchi, Shotaro/川口 翔太朗
 Subject: Re: conditions for removing experimental feature marks
 
 Hi !
 
 On 10/03/2015 11:35, Miyamae, Takeshi wrote:
 Dear Loic,

 I really apologize that our reply is too late.
 Since removing experimental flag from SHEC at v0.94 is our immediate 
 hope, we should have started any actions for that earlier.
 
 No worries, it's never too late to do good :-)
 
 By the way, you mean we must add just the same workaround as 10887 
 for SHEC if our target is Hammer.
 Is my understanding correct ?
 
 What is needed is integration tests running during a few weeks and showing 
 the plugin behaves well. 
 
 Running teuthology locally is non trivial, maybe we can provide you 
 with access to the community lab so that you can run teuthology 
 suites against the existing teuthology cluster (i.e. 
 http://pulpito.ceph.com/). Would you like me to ask ?

 Thank you for your proposal.
 It would be greatly helpful if we were allowed to use it !
 
 Could you please connect to irc.oftc.net#sepia ? This is the IRC channel 
 where lab related matters are discussed. We can figure out the details there. 
 
 In the meantime you can try teuthology and write a single test quite easily, 
 on your local machine. The tricky part comes where we want to run suites with 
 large number of jobs. You can adapt the instructions from 
 http://dachary.org/?p=2204 to your local environment. All you need really is 
 the ability to run two virtual machines.
 
 Cheers
 

 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Monday, February 16, 2015 6:17 PM
 To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
 Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
 Subject: Re: conditions for removing experimental feature marks

 Hi,

 On 16/02/2015 08:37, Miyamae, Takeshi wrote:
 Dear Loic,

 Thank you for your help on the pull request of SHEC last week.
 We believe that marking experimental feature on SHEC was inevitable 
 and the way to restrict the feature is proper.

 By the way, could you let us know what are the conditions for 
 removing experimental feature marks in the future?
 Are additional thorough tests required?

 The next step is to run integration tests with the shec plugin. The 
 integration tests have shown that the shec plugin does not disrupt anything. 
 Now we should check if it works properly under stress and upgrades. I 
 created two tickets for that purpose:

 http://tracker.ceph.com/issues/10886 : integration / theuthology 
 integration / theuthology thrasher tests for the shec erasure code 
 plugin
 http://tracker.ceph.com/issues/10887 : erasure-code: allow upgrades 
 for shec plugins

 It would be fantastic if you could work on 
 http://tracker.ceph.com/issues/7291 : it would make the integration of new 
 erasure code plugins easier. I realize that it is infrastructure work not 
 directly of interest to the shec plugin implementation.

 Running teuthology locally is non trivial, maybe we can provide you with 
 access

RE: conditions for removing experimental feature marks

[Miyamae, Takeshi]

Dear Loic,

We are struggling with teuthology, but we must commit SHEC's recent patches
including Intel sse4 optimization into Hammer before that.

erasure code: fix shec performance/coding style issues #4083
https://github.com/ceph/ceph/pull/4083

Could you check the above pull request, please ?
Almost all of the modifications are for SHEC plugin's file except for some other
document files.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Tuesday, March 10, 2015 11:25 PM
To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Kaga, Yoshihiro/加賀 芳宏; 
Kawaguchi, Shotaro/川口 翔太朗
Subject: Re: conditions for removing experimental feature marks

Hi !

On 10/03/2015 11:35, Miyamae, Takeshi wrote:
 Dear Loic,
 
 I really apologize that our reply is too late.
 Since removing experimental flag from SHEC at v0.94 is our immediate 
 hope, we should have started any actions for that earlier.

No worries, it's never too late to do good :-)

 By the way, you mean we must add just the same workaround as 10887 for 
 SHEC if our target is Hammer.
 Is my understanding correct ?

What is needed is integration tests running during a few weeks and showing the 
plugin behaves well. 

 Running teuthology locally is non trivial, maybe we can provide you 
 with access to the community lab so that you can run teuthology 
 suites against the existing teuthology cluster (i.e. 
 http://pulpito.ceph.com/). Would you like me to ask ?
 
 Thank you for your proposal.
 It would be greatly helpful if we were allowed to use it !

Could you please connect to irc.oftc.net#sepia ? This is the IRC channel where 
lab related matters are discussed. We can figure out the details there. 

In the meantime you can try teuthology and write a single test quite easily, on 
your local machine. The tricky part comes where we want to run suites with 
large number of jobs. You can adapt the instructions from 
http://dachary.org/?p=2204 to your local environment. All you need really is 
the ability to run two virtual machines.

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Monday, February 16, 2015 6:17 PM
 To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
 Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
 Subject: Re: conditions for removing experimental feature marks
 
 Hi,
 
 On 16/02/2015 08:37, Miyamae, Takeshi wrote:
 Dear Loic,

 Thank you for your help on the pull request of SHEC last week.
 We believe that marking experimental feature on SHEC was inevitable 
 and the way to restrict the feature is proper.

 By the way, could you let us know what are the conditions for 
 removing experimental feature marks in the future?
 Are additional thorough tests required?
 
 The next step is to run integration tests with the shec plugin. The 
 integration tests have shown that the shec plugin does not disrupt anything. 
 Now we should check if it works properly under stress and upgrades. I created 
 two tickets for that purpose:
 
 http://tracker.ceph.com/issues/10886 : integration / theuthology 
 integration / theuthology thrasher tests for the shec erasure code 
 plugin
 http://tracker.ceph.com/issues/10887 : erasure-code: allow upgrades 
 for shec plugins
 
 It would be fantastic if you could work on 
 http://tracker.ceph.com/issues/7291 : it would make the integration of new 
 erasure code plugins easier. I realize that it is infrastructure work not 
 directly of interest to the shec plugin implementation.
 
 Running teuthology locally is non trivial, maybe we can provide you with 
 access to the community lab so that you can run teuthology suites against the 
 existing teuthology cluster (i.e. http://pulpito.ceph.com/). Would you like 
 me to ask ? 
 
 Cheers
 
 Best regards,
 Takeshi Miyamae

 
 --
 Loïc Dachary, Artisan Logiciel Libre
 
 N r  y   b X  ǧv ^ )޺{.n +   z ]z   {ay ʇڙ ,j   f   h   z  w   
   j:+v   w j m zZ+ ݢj  !tml=
 

--
Loïc Dachary, Artisan Logiciel Libre

RE: conditions for removing experimental feature marks

[Miyamae, Takeshi]

Dear Loic,

I really apologize that our reply is too late.
Since removing experimental flag from SHEC at v0.94 is our immediate hope, we 
should
have started any actions for that earlier.

By the way, you mean we must add just the same workaround as 10887 for SHEC
if our target is Hammer.
Is my understanding correct ?

 Running teuthology locally is non trivial, maybe we can provide you with 
 access to the
 community lab so that you can run teuthology suites against the existing 
 teuthology cluster
 (i.e. http://pulpito.ceph.com/). Would you like me to ask ?

Thank you for your proposal.
It would be greatly helpful if we were allowed to use it !

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Monday, February 16, 2015 6:17 PM
To: Miyamae, Takeshi/宮前 剛; ceph-devel@vger.kernel.org
Cc: Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
Subject: Re: conditions for removing experimental feature marks

Hi,

On 16/02/2015 08:37, Miyamae, Takeshi wrote:
 Dear Loic,
 
 Thank you for your help on the pull request of SHEC last week.
 We believe that marking experimental feature on SHEC was inevitable 
 and the way to restrict the feature is proper.
 
 By the way, could you let us know what are the conditions for removing 
 experimental feature marks in the future?
 Are additional thorough tests required?

The next step is to run integration tests with the shec plugin. The integration 
tests have shown that the shec plugin does not disrupt anything. Now we should 
check if it works properly under stress and upgrades. I created two tickets for 
that purpose:

http://tracker.ceph.com/issues/10886 : integration / theuthology integration / 
theuthology thrasher tests for the shec erasure code plugin
http://tracker.ceph.com/issues/10887 : erasure-code: allow upgrades for shec 
plugins

It would be fantastic if you could work on http://tracker.ceph.com/issues/7291 
: it would make the integration of new erasure code plugins easier. I realize 
that it is infrastructure work not directly of interest to the shec plugin 
implementation.

Running teuthology locally is non trivial, maybe we can provide you with access 
to the community lab so that you can run teuthology suites against the existing 
teuthology cluster (i.e. http://pulpito.ceph.com/). Would you like me to ask ? 

Cheers

 Best regards,
 Takeshi Miyamae
 

--
Loïc Dachary, Artisan Logiciel Libre

conditions for removing experimental feature marks

[Miyamae, Takeshi]

Dear Loic,

Thank you for your help on the pull request of SHEC last week.
We believe that marking experimental feature on SHEC was inevitable and
the way to restrict the feature is proper.

By the way, could you let us know what are the conditions for removing
experimental feature marks in the future?
Are additional thorough tests required?

Best regards,
Takeshi Miyamae

RE: SHEC updates to the erasure code non regression corpus

[Miyamae, Takeshi]

Hi Loic,

 I would be grateful if you could verify that it works as intended.

We have tried create and check actions once for each. It seems it works well.
Is that enough for your job?

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Wednesday, February 11, 2015 9:28 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development
Subject: SHEC updates to the erasure code non regression corpus

Hi,

I've updated the erasure code corpus that verifies the encoding of erasure 
coded chunks do not change over time with a version that includes the SHEC 
erasure code plugin.

https://github.com/ceph/ceph-erasure-code-corpus/commit/498b0102955b747813182734e13e75195f2a02a9

From now on it will run each time someone does make check, but only if the 
sources are after

$ git rev-parse v0.92-988-g7df0556
7df0556210be3afdc02e2ca41b3a3b60569b753a

I would be grateful if you could verify that it works as intended. The process 
for updating the corpus has been documented at 
https://github.com/ceph/ceph-erasure-code-corpus#ceph-erasure-code-corpus : it 
was difficult to guess how it works ;-)

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: unittest_erasure_code_shec fails

[Miyamae, Takeshi]

Hi Loic,

We are sorry for the errors in the test script and thank you for your urgent 
handling.
To be honest, we also had found those errors last week and we thought that those
errors depend on execution environment.
Basically those are not required and your modification was enough, but we will 
issue
another pull request later because we would like to erase all the same kinds of 
tests
as those.

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Thursday, February 12, 2015 4:34 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development
Subject: unittest_erasure_code_shec fails

Hi,

As of today the SHEC unit test fail as described at 
http://tracker.ceph.com/issues/10839. Can you reproduce the failure locally ? 
I'm not sure why it happens now and not yesterday. I'll bisect the failure down 
to the guilty commit but it would be great if you could confirm that you also 
see it.

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: unittest_erasure_code_shec fails

[Miyamae, Takeshi]

Hi Loic,

We have opened a new pull request #3716 to fix #10839 just now.

mshec: fixed bug #10839 (unittest_erasure_code_shec fails)
https://github.com/ceph/ceph/pull/3716

Best regards,
Takeshi Miyamae

-Original Message-
From: Miyamae, Takeshi/宮前 剛 
Sent: Thursday, February 12, 2015 12:27 PM
To: 'Loic Dachary'
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔 (shiozawa.ken...@jp.fujitsu.com); 
Nakao, Takanori/中尾 鷹詔 (nakao.takan...@jp.fujitsu.com); Kaga Yoshihiro/加賀 芳宏 
(y-k...@jp.fujitsu.com); Kawaguchi Shotaro/川口 翔太朗 (kawaguch...@jp.fujitsu.com)
Subject: RE: unittest_erasure_code_shec fails

Hi Loic,

We are sorry for the errors in the test script and thank you for your urgent 
handling.
To be honest, we also had found those errors last week and we thought that 
those errors depend on execution environment.
Basically those are not required and your modification was enough, but we will 
issue another pull request later because we would like to erase all the same 
kinds of tests as those.

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Thursday, February 12, 2015 4:34 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development
Subject: unittest_erasure_code_shec fails

Hi,

As of today the SHEC unit test fail as described at 
http://tracker.ceph.com/issues/10839. Can you reproduce the failure locally ? 
I'm not sure why it happens now and not yesterday. I'll bisect the failure down 
to the guilty commit but it would be great if you could confirm that you also 
see it.

Cheers

--
Loïc Dachary, Artisan Logiciel Libre

RE: mSHEC pull request (2nd challenge)

[Miyamae, Takeshi]

Hi Loic,

Thank you for your cooperation !
If we could do something to reduce your burdens, please let us know.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Thursday, January 29, 2015 11:38 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
Kawaguchi, Shotaro/川口 翔太朗; Kaga, Yoshihiro/加賀 芳宏; Paul Von-Stamwitz 
(pvonstamw...@us.fujitsu.com)
Subject: Re: mSHEC pull request (2nd challenge)

Hi,

It looks good and ready for integration testing :-) I just created 
http://tracker.ceph.com/issues/10686 to track this feature. Since we are late 
in development cycle and unless someone has a different opinion, I will mark 
the SHEC plugin as experimental so people know it's new. I will however do that 
after it is merged in master.

Cheers

On 29/01/2015 15:24, Miyamae, Takeshi wrote:
 Hi Loic,
 
 When I reset our commits on our fork repository, the 1st pull request was 
 automatically closed.
 So, I have issued another pull request of mSHEC.
 
 mSHEC : multiple Shingled Erasure Code #3534
 https://github.com/ceph/ceph/pull/3534
 
 As a result, I believe I have squashed our commits into one.
 I'm grad if you could restart the review.
 
 (You already noticed that and gave us labels, thank you!)
 
 Best regards,
 Takeshi Miyamae
 

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: mSHEC pull request (2nd challenge)

[Miyamae, Takeshi]

Hi Loic,

 There was originally two files for tests and the one with 364 or something at 
 the end was removed
 if I'm not mistaken. Is there a reason for that ?

We had renamed the file from TestErasureCodeShec364.cc to 
TestErasureCodeShec_all.cc
because the number of tests included in this file is not always just 364. It's 
a simple reason. (^^)

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Friday, January 30, 2015 8:29 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
Kawaguchi, Shotaro/川口 翔太朗; Kaga, Yoshihiro/加賀 芳宏; Paul Von-Stamwitz 
(pvonstamw...@us.fujitsu.com)
Subject: Re: mSHEC pull request (2nd challenge)


Hi,

On 30/01/2015 11:28, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Thank you for your cooperation !
 If we could do something to reduce your burdens, please let us know.

Hopefully tests come out clean, let see :-)

There was originally two files for tests and the one with 364 or something at 
the end was removed if I'm not mistaken. Is there a reason for that ?

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org] 
 Sent: Thursday, January 29, 2015 11:38 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Kawaguchi, Shotaro/川口 翔太朗; Kaga, Yoshihiro/加賀 芳宏; Paul Von-Stamwitz 
 (pvonstamw...@us.fujitsu.com)
 Subject: Re: mSHEC pull request (2nd challenge)
 
 Hi,
 
 It looks good and ready for integration testing :-) I just created 
 http://tracker.ceph.com/issues/10686 to track this feature. Since we are late 
 in development cycle and unless someone has a different opinion, I will mark 
 the SHEC plugin as experimental so people know it's new. I will however do 
 that after it is merged in master.
 
 Cheers
 
 On 29/01/2015 15:24, Miyamae, Takeshi wrote:
 Hi Loic,

 When I reset our commits on our fork repository, the 1st pull request was 
 automatically closed.
 So, I have issued another pull request of mSHEC.

 mSHEC : multiple Shingled Erasure Code #3534
 https://github.com/ceph/ceph/pull/3534

 As a result, I believe I have squashed our commits into one.
 I'm grad if you could restart the review.

 (You already noticed that and gave us labels, thank you!)

 Best regards,
 Takeshi Miyamae

 

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

I have noticed that your repository ceph-erasure-code-corpus is forked for us,
so I created a new pull request.

Update non-regression.sh #1
https://github.com/t-miyamae/ceph-erasure-code-corpus/pull/1

Best regards,
Takeshi Miyamae

-Original Message-
From: Miyamae, Takeshi/宮前 剛 
Sent: Monday, January 26, 2015 2:44 PM
To: 'Loic Dachary'
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
Subject: RE: Deadline of Github pull request for Hammer release (question)

Hi Loic,

 Note that you also need to update

We have prepared mSHEC's parameter sets which we think will be commonly used.
Because I'm not sure how to update another person's repository, we will write 
down those parameter sets in this mail.
If we are required to do something, please let us know.

while read k m c ; do
for stripe_width in $STRIPE_WIDTHS ; do
ceph_erasure_code_non_regression --stripe-width $stripe_width --plugin 
shec --parameter technique=multiple --parameter k=$k --parameter m=$m 
--parameter c=$c $ACTION $VERBOSE $MYDIR
done
done EOF
1 1 1
2 1 1
3 2 1
3 2 2
3 3 2
4 1 1
4 2 2
4 3 2
5 2 1
6 3 2
6 4 2
6 4 3
7 2 1
8 3 2
8 4 2
8 4 3
9 4 2
9 5 3
12 7 4
EOF

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org]
Sent: Friday, January 23, 2015 10:47 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

Note that you also need to update 

https://github.com/dachary/ceph-erasure-code-corpus/blob/master/v0.85-764-gf3a1532/non-regression.sh

to include non regression tests for the most common cases of the SHEC plugin 
encoding / decoding. This is run by make check (this repository is a submodule 
of Ceph). It helps make sure that content encoded / decoded with a given 
version of the plugin can be encoded / decoded exactly in the same way by all 
future versions.

Cheers

On 06/01/2015 12:49, Miyamae, Takeshi wrote:
 Dear Loic,
 
 I'm Takeshi Miyamae, one of the authors of SHEC's blueprint.
 
 Shingled Erasure Code (SHEC)
 https://wiki.ceph.com/Planning/Blueprints/Hammer/Shingled_Erasure_Code
 _(SHEC)
 
 We have revised our blueprint shown in the last CDS to extend our 
 erasure code layouts and describe the guideline for choosing SHEC among 
 various EC plugins.
 We believe the blueprint now answers all the comments given at the CDS.
 
 In addition, we would like to ask for your advice on the schedule of 
 our github pull request. More specifically, we would like to know its 
 deadline for Hammer release.
 (As we have not really completed our verification of SHEC, we are 
 wondering if we should make it open for early preview.)
 
 Thank you in advance,
 Takeshi Miyamae
 
 --
 To unsubscribe from this list: send the line unsubscribe ceph-devel 
 in the body of a message to majord...@vger.kernel.org More majordomo 
 info at  http://vger.kernel.org/majordomo-info.html
 

--
Loïc Dachary, Artisan Logiciel Libre

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

 Note that you also need to update

We have prepared mSHEC's parameter sets which we think will be commonly used.
Because I'm not sure how to update another person's repository, we will write 
down
those parameter sets in this mail.
If we are required to do something, please let us know.

while read k m c ; do
for stripe_width in $STRIPE_WIDTHS ; do
ceph_erasure_code_non_regression --stripe-width $stripe_width --plugin 
shec --parameter technique=multiple --parameter k=$k --parameter m=$m 
--parameter c=$c $ACTION $VERBOSE $MYDIR
done
done EOF
1 1 1
2 1 1
3 2 1
3 2 2
3 3 2
4 1 1
4 2 2
4 3 2
5 2 1
6 3 2
6 4 2
6 4 3
7 2 1
8 3 2
8 4 2
8 4 3
9 4 2
9 5 3
12 7 4
EOF

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Friday, January 23, 2015 10:47 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

Note that you also need to update 

https://github.com/dachary/ceph-erasure-code-corpus/blob/master/v0.85-764-gf3a1532/non-regression.sh

to include non regression tests for the most common cases of the SHEC plugin 
encoding / decoding. This is run by make check (this repository is a submodule 
of Ceph). It helps make sure that content encoded / decoded with a given 
version of the plugin can be encoded / decoded exactly in the same way by all 
future versions.

Cheers

On 06/01/2015 12:49, Miyamae, Takeshi wrote:
 Dear Loic,
 
 I'm Takeshi Miyamae, one of the authors of SHEC's blueprint.
 
 Shingled Erasure Code (SHEC)
 https://wiki.ceph.com/Planning/Blueprints/Hammer/Shingled_Erasure_Code
 _(SHEC)
 
 We have revised our blueprint shown in the last CDS to extend our 
 erasure code layouts and describe the guideline for choosing SHEC among 
 various EC plugins.
 We believe the blueprint now answers all the comments given at the CDS.
 
 In addition, we would like to ask for your advice on the schedule of 
 our github pull request. More specifically, we would like to know its 
 deadline for Hammer release.
 (As we have not really completed our verification of SHEC, we are 
 wondering if we should make it open for early preview.)
 
 Thank you in advance,
 Takeshi Miyamae
 
 --
 To unsubscribe from this list: send the line unsubscribe ceph-devel 
 in the body of a message to majord...@vger.kernel.org More majordomo 
 info at  http://vger.kernel.org/majordomo-info.html
 

--
Loïc Dachary, Artisan Logiciel Libre

RE: mSHEC r33 release

[Miyamae, Takeshi]

Hi Loic,

 It looks like the branch from which you created the pull request still is 
 master and not wip-mSHEC. 
 That's not a problem. It only really becomes a problem if you have more than 
 one pull request going on.

I'm sorry that I didn't have such a common sense.
We recreated the pull request from wip-mSHEC branch.

wip-mSHEC : multiple Shingled Erasure Code #3488
https://github.com/ceph/ceph/pull/3488

Could you change the branch you will pull from?
If it were difficult or not good for the reason of logging comment already 
written, pulling from master branch would also be OK for us and I would remove 
the latter pull request.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Sunday, January 25, 2015 1:20 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: mSHEC r33 release

Hi,

On 24/01/2015 10:09, Miyamae, Takeshi wrote:
 Hi Loic,
 
 I have created a pull request of wip-mSHEC.
 
 wip-mSHEC pull request #3484
 https://github.com/ceph/ceph/pull/3484
 
 Besides, we changed the name of our fork repository.
 https://github.com/t-miyamae/wip-mSHEC
 
 I'm not sure that it was done correctly because I am a beginner.
 Would you check it, please?

It looks like the branch from which you created the pull request still is 
master and not wip-mSHEC. That's not a problem. It only really becomes a 
problem if you have more than one pull request going on.

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org] 
 Sent: Friday, January 23, 2015 11:40 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
 Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
 Shotaro/川口 翔太朗
 Subject: Re: mSHEC r33 release
 
 Thanks, I'll take a look. Could you please create a pull request against the 
 master branch ? When you do so, it will be convenient if you submit from a 
 branch that has a descriptive name such as wip-mSHEC or something similar.
 
 Cheers
 
 On 23/01/2015 15:30, Miyamae, Takeshi wrote:
 Hi Loic,

 We have released mSHEC r33 just now.

 https://github.com/t-miyamae/ceph

 NOTABLE CHANGES
   - ensure thread safety
   - support generator matrix cache (added ErasureCodeShecTableCache.cc)
   - refer to the shared jerasure 2.0 library
   - improve verification of return code in test codes
   - add test code for verifying thread safety (added 
 TestErasureCodeShec_thread.cc)

 LIMITATION
   - There are still lots of minor problems in test codes.
 We will fix it by 1/26(mon).

 Best regards,
 Takeshi Miyamae

 
 

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: mSHEC r33 release

[Miyamae, Takeshi]

Hi Loic

 We recreated the pull request from wip-mSHEC branch.

I'm sorry. I had thought twice and judged it would not be better to change the 
branch.
I'd close our 2nd pull request and delete wip-mSHEC branch.

Only #3484 is alive as our mSHEC pull request at this moment.

wip-mSHEC : multiple Shingled Erasure Code #3484
https://github.com/ceph/ceph/pull/3484

Best regareds,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Miyamae, Takeshi
Sent: Monday, January 26, 2015 11:22 AM
To: Loic Dachary
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: RE: mSHEC r33 release

Hi Loic,

 It looks like the branch from which you created the pull request still is 
 master and not wip-mSHEC. 
 That's not a problem. It only really becomes a problem if you have more than 
 one pull request going on.

I'm sorry that I didn't have such a common sense.
We recreated the pull request from wip-mSHEC branch.

wip-mSHEC : multiple Shingled Erasure Code #3488
https://github.com/ceph/ceph/pull/3488

Could you change the branch you will pull from?
If it were difficult or not good for the reason of logging comment already 
written, pulling from master branch would also be OK for us and I would remove 
the latter pull request.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Sunday, January 25, 2015 1:20 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: mSHEC r33 release

Hi,

On 24/01/2015 10:09, Miyamae, Takeshi wrote:
 Hi Loic,
 
 I have created a pull request of wip-mSHEC.
 
 wip-mSHEC pull request #3484
 https://github.com/ceph/ceph/pull/3484
 
 Besides, we changed the name of our fork repository.
 https://github.com/t-miyamae/wip-mSHEC
 
 I'm not sure that it was done correctly because I am a beginner.
 Would you check it, please?

It looks like the branch from which you created the pull request still is 
master and not wip-mSHEC. That's not a problem. It only really becomes a 
problem if you have more than one pull request going on.

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org] 
 Sent: Friday, January 23, 2015 11:40 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
 Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
 Shotaro/川口 翔太朗
 Subject: Re: mSHEC r33 release
 
 Thanks, I'll take a look. Could you please create a pull request against the 
 master branch ? When you do so, it will be convenient if you submit from a 
 branch that has a descriptive name such as wip-mSHEC or something similar.
 
 Cheers
 
 On 23/01/2015 15:30, Miyamae, Takeshi wrote:
 Hi Loic,

 We have released mSHEC r33 just now.

 https://github.com/t-miyamae/ceph

 NOTABLE CHANGES
   - ensure thread safety
   - support generator matrix cache (added ErasureCodeShecTableCache.cc)
   - refer to the shared jerasure 2.0 library
   - improve verification of return code in test codes
   - add test code for verifying thread safety (added 
 TestErasureCodeShec_thread.cc)

 LIMITATION
   - There are still lots of minor problems in test codes.
 We will fix it by 1/26(mon).

 Best regards,
 Takeshi Miyamae

 
 

-- 
Loïc Dachary, Artisan Logiciel Libre

�{.n�+���+%��lzwm��b�맲��r��yǩ�ׯzX����ܨ}���Ơz�j:+v���
zZ+��+zf���h���~i���z��w���?�)ߢf
N�r��yb�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

 Do you see a problem with that ?

I understood what you mentioned now. It might not be impossible.
We will try to add those verifications after our current high priority action 
items.

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Friday, January 23, 2015 10:38 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

On 23/01/2015 13:47, Miyamae, Takeshi wrote:
 Hi Loic,
 
 But for a given PG, minimum_to_decode will always return the same chunks, 
 right ?
 
 To be precise, PG, broken OSDs, generator matrix and complicated 
 calculation logic are required to predict the size of minimum_chunks.
 Because those are almost equivalent to whole implementation of 
 minimum_to_decode, we feel that might be no longer a testing.

Ok, I get it :-) I was suggesting that in addition to 

EXPECT_NE(want_to_decode,minimum_chunks);

you could add

expected_minimum_chunks.insert(3)
expected_minimum_chunks.insert(5)
expected_minimum_chunks.insert(8)
EXPECT_EQ(expected_minimum_chunks,minimum_chunks);

because this will always be true for this test since the input is always the 
same. And if for some reason it comes out different, then it means we have a 
problem.

Do you see a problem with that ?

Cheers


 
 If you mentioned quantitative evaluation of SHEC's read data during 
 recovery, we have already evaluated it as an average size of 
 minimum_chunks by calling minimum_to_decode with all input patterns.
 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Friday, January 23, 2015 6:09 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 
 芳宏; Kawaguchi, Shotaro/川口 翔太朗
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 
 Hi,
 
 On 23/01/2015 02:16, Miyamae, Takeshi wrote:
 Hi Loic,

 Could you give me the definition of a lace bug ?

 I'm sorry I meant race bug. It was just a typo (I'm farthest from a native 
 English speaker ...).

 Note that there are two kind of tests in Ceph : ...

 OK. I understand the Ceph's style of testing.

 Do you mean that two consecutive runs of minimum_to_decode will provide 
 different results ?

 Yes, they will. The reason is that SHEC's layout (=calculation ranges 
 of parities) can be asymmetric, which means that the size of 
 minimum_chunks (=the number of chunks that must be read at least from the 
 disks) depends on IDs of the broken chunks.
 For instance, in case of SHEC(5,3,2) as described below, two chunks 
 would be needed in some PG cases (where single broken chunk were 1, 
 2, or b), while three chunks in other PG cases (where single broken chunk 
 were 3, 4, 5, or c).

 SHEC(5,3,2)'s layout :
   data chunks 12345
   parity chunk a  -
   parity chunk b  --
   parity chunk c---
   (--- means calculation ranges of each parity)

 We called it a random aspect of SHEC's minimum_chunks.
 
 But for a given PG, minimum_to_decode will always return the same chunks, 
 right ?
 
 Cheers
 

 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Friday, January 23, 2015 2:29 AM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔;
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀
 芳宏; Kawaguchi, Shotaro/川口 翔太朗
 Subject: Re: Deadline of Github pull request for Hammer release
 (question)

 Hi,

 On 22/01/2015 17:34, Miyamae, Takeshi wrote:
 Hi Loic,

 Thank you for the code reference. We will use it to improve our codes.

 However, I'm not sure I understand why you need threads at all to test the 
 plugin. Could you explain ?

 Sure. The purpose of using threads is just to find lace bugs and ensure 
 thread safety.

 I'm not familiar with the expression lace bug and all I could find is 
 http://en.wiktionary.org/wiki/lace which does not help me (I'm french, 
 english is not my native language). Could you give me the definition of a 
 lace bug ? 

 However, I suppose those tests may be a little adhoc and be far from 
 completeness.
 Actually, we couldn't detect some init lace bugs including #7914 (We will 
 fix those bugs at the next release).
 Do you have any better ideas to combat these kind of bugs systematically?


 Race conditions such as http://tracker.ceph.com/issues/7914 are quite 
 difficult detect with tests and I don't know of a sure method to do so. 
 Carefully proofreading the code and keeping the logic simple is probably the 
 most effective way ;-) Once a race condition has been fixed, however, it 
 should be possible to recreate the conditions for it to appear in a 
 functional

RE: mSHEC r33 release

[Miyamae, Takeshi]

Hi Loic,

Thank you for your advice and information.
Both approaches are attractive and we have started to consider which one to 
take.
However, I'm afraid that we might not have enough time to implement and test it
until the first release of Hammer.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Saturday, January 24, 2015 8:40 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: mSHEC r33 release

Hi,

Since the SHEC plugin depends on the jerasure plugin, it would be simpler if it 
loaded it instead of including it. The main problem with the current inclusion 
is that it does not compile any SIMD acceleration code and loses the benefit of 
optimization when the CPU can provide it. 

There are two ways out of this 

a) add to the SHEC plugin the same selection that jerasure has (in the Makefile 
and with something like 
http://workbench.dachary.org/ceph/ceph/blob/master/src/erasure-code/jerasure/ErasureCodePluginSelectJerasure.cc

b) compile jerasure as a convenience library that can be included by both the 
jerasure and SHEC plugin.

The LRC plugin loads the jerasure plugin but the SHEC plugin cannot do the same 
because the standard API at 
http://workbench.dachary.org/ceph/ceph/blob/master/src/erasure-code/ErasureCodeInterface.h
 is not enough.

Note that this is not a blocker for the inclusion of the plugin and can be done 
afterwards.

Cheers

On 23/01/2015 15:30, Miyamae, Takeshi wrote:
 Hi Loic,
 
 We have released mSHEC r33 just now.
 
 https://github.com/t-miyamae/ceph
 
 NOTABLE CHANGES
   - ensure thread safety
   - support generator matrix cache (added ErasureCodeShecTableCache.cc)
   - refer to the shared jerasure 2.0 library
   - improve verification of return code in test codes
   - add test code for verifying thread safety (added 
 TestErasureCodeShec_thread.cc)
 
 LIMITATION
   - There are still lots of minor problems in test codes.
 We will fix it by 1/26(mon).
 
 Best regards,
 Takeshi Miyamae
 
 N�r��y���b�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j
��f���h���z��w���
���j:+v���w�j�m
zZ+�ݢj��!tml=
 

-- 
Loïc Dachary, Artisan Logiciel Libre

RE: mSHEC r33 release

[Miyamae, Takeshi]

Hi Loic,

I have created a pull request of wip-mSHEC.

wip-mSHEC pull request #3484
https://github.com/ceph/ceph/pull/3484

Besides, we changed the name of our fork repository.
https://github.com/t-miyamae/wip-mSHEC

I'm not sure that it was done correctly because I am a beginner.
Would you check it, please?

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Friday, January 23, 2015 11:40 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: mSHEC r33 release

Thanks, I'll take a look. Could you please create a pull request against the 
master branch ? When you do so, it will be convenient if you submit from a 
branch that has a descriptive name such as wip-mSHEC or something similar.

Cheers

On 23/01/2015 15:30, Miyamae, Takeshi wrote:
 Hi Loic,
 
 We have released mSHEC r33 just now.
 
 https://github.com/t-miyamae/ceph
 
 NOTABLE CHANGES
   - ensure thread safety
   - support generator matrix cache (added ErasureCodeShecTableCache.cc)
   - refer to the shared jerasure 2.0 library
   - improve verification of return code in test codes
   - add test code for verifying thread safety (added 
 TestErasureCodeShec_thread.cc)
 
 LIMITATION
   - There are still lots of minor problems in test codes.
 We will fix it by 1/26(mon).
 
 Best regards,
 Takeshi Miyamae
 


-- 
Loïc Dachary, Artisan Logiciel Libre

mSHEC r35 release

[Miyamae, Takeshi]

Hi Loic,

We are sorry that test errors bothered you.
We have released mSHEC r35 just now.

https://github.com/t-miyamae/ceph

NOTABLE CHANGES
  - remove test errors
  - remove compile warnings

LIMITATION
  - only TestErasureCodeShec364.cc is still not available.
We will fix it by 1/26(mon)

Best regards,
Takeshi Miyamae

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

mSHEC r33 release

[Miyamae, Takeshi]

Hi Loic,

We have released mSHEC r33 just now.

https://github.com/t-miyamae/ceph

NOTABLE CHANGES
  - ensure thread safety
  - support generator matrix cache (added ErasureCodeShecTableCache.cc)
  - refer to the shared jerasure 2.0 library
  - improve verification of return code in test codes
  - add test code for verifying thread safety (added 
TestErasureCodeShec_thread.cc)

LIMITATION
  - There are still lots of minor problems in test codes.
We will fix it by 1/26(mon).

Best regards,
Takeshi Miyamae

N�r��yb�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

 But for a given PG, minimum_to_decode will always return the same chunks, 
 right ?

To be precise, PG, broken OSDs, generator matrix and complicated calculation 
logic are
required to predict the size of minimum_chunks.
Because those are almost equivalent to whole implementation of 
minimum_to_decode,
we feel that might be no longer a testing.

If you mentioned quantitative evaluation of SHEC's read data during recovery, 
we have
already evaluated it as an average size of minimum_chunks by calling 
minimum_to_decode
with all input patterns.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Friday, January 23, 2015 6:09 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: Deadline of Github pull request for Hammer release (question)


Hi,

On 23/01/2015 02:16, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Could you give me the definition of a lace bug ?
 
 I'm sorry I meant race bug. It was just a typo (I'm farthest from a native 
 English speaker ...).
 
 Note that there are two kind of tests in Ceph : ...
 
 OK. I understand the Ceph's style of testing.
 
 Do you mean that two consecutive runs of minimum_to_decode will provide 
 different results ?
 
 Yes, they will. The reason is that SHEC's layout (=calculation ranges 
 of parities) can be asymmetric, which means that the size of 
 minimum_chunks (=the number of chunks that must be read at least from the 
 disks) depends on IDs of the broken chunks.
 For instance, in case of SHEC(5,3,2) as described below, two chunks 
 would be needed in some PG cases (where single broken chunk were 1, 2, 
 or b), while three chunks in other PG cases (where single broken chunk were 
 3, 4, 5, or c).
 
 SHEC(5,3,2)'s layout :
   data chunks 12345
   parity chunk a  -
   parity chunk b  --
   parity chunk c---
   (--- means calculation ranges of each parity)
 
 We called it a random aspect of SHEC's minimum_chunks.

But for a given PG, minimum_to_decode will always return the same chunks, right 
?

Cheers

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Friday, January 23, 2015 2:29 AM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 
 芳宏; Kawaguchi, Shotaro/川口 翔太朗
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 On 22/01/2015 17:34, Miyamae, Takeshi wrote:
 Hi Loic,

 Thank you for the code reference. We will use it to improve our codes.

 However, I'm not sure I understand why you need threads at all to test the 
 plugin. Could you explain ?

 Sure. The purpose of using threads is just to find lace bugs and ensure 
 thread safety.
 
 I'm not familiar with the expression lace bug and all I could find is 
 http://en.wiktionary.org/wiki/lace which does not help me (I'm french, 
 english is not my native language). Could you give me the definition of a 
 lace bug ? 
 
 However, I suppose those tests may be a little adhoc and be far from 
 completeness.
 Actually, we couldn't detect some init lace bugs including #7914 (We will 
 fix those bugs at the next release).
 Do you have any better ideas to combat these kind of bugs systematically?

 
 Race conditions such as http://tracker.ceph.com/issues/7914 are quite 
 difficult detect with tests and I don't know of a sure method to do so. 
 Carefully proofreading the code and keeping the logic simple is probably the 
 most effective way ;-) Once a race condition has been fixed, however, it 
 should be possible to recreate the conditions for it to appear in a 
 functional test that can be run with make check.
 
 Note that there are two kind of tests in Ceph : the unit / functional tests 
 that are run with make check, locally on the developer machine or by a bot on 
 each pull request. These tests run quickly and do not include any 
 benchmarking or stress tests, nor integration tests. The second kind is what 
 you find in teuthology : these tests include stress tests, error injections 
 etc. Most race conditions are discovered by running these teuthology tests 
 and analyzing their output.
 
 What do you think of my comments (about minimum_to_decode_3 and 
 minimum_to_decode_2 ) ?

 I don't think current minimum_to_decode_2 is adequate, as you mentioned.
 The verification of return codes is required and we will compare it with 
 expectations (EINVAL or EIO).
 However, as for the size of minimum_chunks, as it is hard to 
 pre-estimate without knowing parity layout because of its random aspect, we 
 won't improve it any more.
 
 Do you mean that two consecutive runs of minimum_to_decode will provide 
 different results ? 
 
 Then, as for minimum_to_decode_3, we found

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

Thanks for your additional comments.

 Would you be so kind as to update the 
 https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/Makefile.am

Sure. We'll do that.

 This is likely to fail on a slow machine. Instead of waiting you should use a 
 lock.

The purpose of sleep(1) is to ensure sequentiality between threads, but it's 
not enough on slow
machines as you mentioned. So, we'd like another example that uses a mutex 
lock. What files
should we refer to?

 They however all have the same assert ( EXPECT_TRUE(shec-matrix == NULL); )

We agree that EINVAL is better than EIO on verifying input variables. We'll 
review our whole
sources and fix both our plugin and test codes.

P.S. We are debugging thread safe mSHEC to release it tomorrow.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Wednesday, January 21, 2015 11:13 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com)
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

I see them at 
https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/TestErasureCodeShec.cc
 etc. thanks ! Would you be so kind as to update the 
https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/Makefile.am 
to add the compilation instructions for these files ?

I see the tests includes a few threads (thread1 to thread5). It looks like they 
are used for measuring performance, am I right ? 

pthread_t tid;
pthread_create(tid,NULL,thread1,shec);
sleep(1);

This is likely to fail on a slow machine. Instead of waiting you should use a 
lock. You will find examples in other tests, using various techniques depending 
on the context. If you'd like I could point to one. I'd have to better 
understand the intent of this test before I do.

From init_5 to init_22 there are various combinations of parameters which 
suggest checking for all kinds of errors (m being negative, or a string instead 
of a number etc.). They however all have the same assert ( 
EXPECT_TRUE(shec-matrix == NULL); ). It would be better to have an expectation 
that verifies the error has been caught as expected. Is it part of what your 
completing at the moment ?

minimum_to_decode_2 expectation for when it succeeds should be more precise that

EXPECT_TRUE(minimum_chunks.size());

since minimum_chunks is expecting to have a size that does not vary. And if it 
does that would be a problem.

In minimum_to_decode_3 after

EXPECT_NE(want_to_decode,minimum_chunks);

you could check the expected content of minimum_chunks also. Unless there is a 
random aspect to it ? 

Cheers

On 20/01/2015 10:07, Miyamae, Takeshi wrote:
 Hi Loic,
 
 I'd appreciated your help very much.
 I have just uploaded 2 test files into the fork repository.
 
 https://github.com/t-miyamae/ceph
 files:
   src/test/erasure-code/TestErasureCodeShec.cc
   src/test/erasure-code/TestErasureCodeShec364.cc
 
 I'm sorry that tests for the thread safety codes has not been included yet.
 
 Thank you in advance,
 Takeshi Miyamae
 
 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Tuesday, January 20, 2015 4:23 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 Thanks for the update. To speed up things, I could review what's already 
 published. Did you add the tests already ?
 
 Cheers
 
 On 20/01/2015 01:48, Miyamae, Takeshi wrote:
 Hi Loic,

 Thank you for your advice which suggested providing SHEC as an extra-package.
 We believe it's generally a good idea, but we are hoping SHEC would 
 be merged into Hammer because that would have an apparent advantage 
 from a viewpoint of maintenance support.

 As for the thread safety issue, we totally agree with you and we are trying 
 to solve it.
 We will complete it in a few days and we'd like to ask you to review 
 it again so that it might be in time for Hammer's feature freeze (v0.93).

 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Wednesday, January 14, 2015 3:03 AM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔;
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release
 (question)

 Hi,

 On 13/01/2015 18:05, Miyamae, Takeshi wrote:
 Hi Loic,

 Thank you for your quick review.

 Could you reference the jerasure files (they are in the jerasure 
 plugin already) instead of including them in your patch ?

 We had used the reference

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

Thank you for the code reference. We will use it to improve our codes.

 However, I'm not sure I understand why you need threads at all to test the 
 plugin. Could you explain ?

Sure. The purpose of using threads is just to find lace bugs and ensure thread 
safety.
However, I suppose those tests may be a little adhoc and be far from 
completeness.
Actually, we couldn't detect some init lace bugs including #7914 (We will fix 
those bugs at the next release).
Do you have any better ideas to combat these kind of bugs systematically?

 What do you think of my comments (about minimum_to_decode_3 and 
 minimum_to_decode_2 ) ?

I don't think current minimum_to_decode_2 is adequate, as you mentioned.
The verification of return codes is required and we will compare it with 
expectations (EINVAL or EIO).
However, as for the size of minimum_chunks, as it is hard to pre-estimate 
without knowing
parity layout because of its random aspect, we won't improve it any more.

Then, as for minimum_to_decode_3, we found it meaningless to verify 
minimum_chunks because
that is an error case when array size of want_to_decode and available_chunks 
are illegally large.
We will verify only return code of minimum_to_decode and remove the current 
check of
minimum_chunks in minimum_to_decode_3.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Thursday, January 22, 2015 6:28 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com)
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

On 22/01/2015 09:42, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Thanks for your additional comments.
 
 Would you be so kind as to update the 
 https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/M
 akefile.am
 
 Sure. We'll do that.
 
 This is likely to fail on a slow machine. Instead of waiting you should use 
 a lock.
 
 The purpose of sleep(1) is to ensure sequentiality between threads, 
 but it's not enough on slow machines as you mentioned. So, we'd like 
 another example that uses a mutex lock. What files should we refer to?

src/test/common/test_sharedptr_registry.cc contains an example. The classes 
that are helpful in implementing thread safe are in src/common/Cond.h and 
src/common/Mutex.h

However, I'm not sure I understand why you need threads at all to test the 
plugin. Could you explain ?

 
 They however all have the same assert ( EXPECT_TRUE(shec-matrix == 
 NULL); )
 
 We agree that EINVAL is better than EIO on verifying input variables. 
 We'll review our whole sources and fix both our plugin and test codes.

Thanks :-) What do you think of my comments (about minimum_to_decode_3 and 
minimum_to_decode_2 ) ?

Cheers

 
 P.S. We are debugging thread safe mSHEC to release it tomorrow.
 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Wednesday, January 21, 2015 11:13 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 I see them at 
 https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/TestErasureCodeShec.cc
  etc. thanks ! Would you be so kind as to update the 
 https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/Makefile.am
  to add the compilation instructions for these files ?
 
 I see the tests includes a few threads (thread1 to thread5). It looks like 
 they are used for measuring performance, am I right ? 
 
   pthread_t tid;
   pthread_create(tid,NULL,thread1,shec);
   sleep(1);
 
 This is likely to fail on a slow machine. Instead of waiting you should use a 
 lock. You will find examples in other tests, using various techniques 
 depending on the context. If you'd like I could point to one. I'd have to 
 better understand the intent of this test before I do.
 
 From init_5 to init_22 there are various combinations of parameters which 
 suggest checking for all kinds of errors (m being negative, or a string 
 instead of a number etc.). They however all have the same assert ( 
 EXPECT_TRUE(shec-matrix == NULL); ). It would be better to have an 
 expectation that verifies the error has been caught as expected. Is it part 
 of what your completing at the moment ?
 
 minimum_to_decode_2 expectation for when it succeeds should be more 
 precise that
 
   EXPECT_TRUE(minimum_chunks.size());
 
 since minimum_chunks is expecting to have a size that does not vary. And if 
 it does that would be a problem.
 
 In minimum_to_decode_3 after
 
   EXPECT_NE(want_to_decode,minimum_chunks);
 
 you could check the expected content of minimum_chunks also. Unless there is 
 a random aspect to it ? 
 
 Cheers
 
 On 20/01/2015 10:07, Miyamae, Takeshi wrote

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

 Could you give me the definition of a lace bug ?

I'm sorry I meant race bug. It was just a typo (I'm farthest from a native 
English speaker ...).

 Note that there are two kind of tests in Ceph : ...

OK. I understand the Ceph's style of testing.

 Do you mean that two consecutive runs of minimum_to_decode will provide 
 different results ?

Yes, they will. The reason is that SHEC's layout (=calculation ranges of 
parities) can be asymmetric,
which means that the size of minimum_chunks (=the number of chunks that must be 
read at least
from the disks) depends on IDs of the broken chunks.
For instance, in case of SHEC(5,3,2) as described below, two chunks would be 
needed in some
PG cases (where single broken chunk were 1, 2, or b), while three chunks in 
other PG cases
(where single broken chunk were 3, 4, 5, or c).

SHEC(5,3,2)'s layout :
  data chunks 12345
  parity chunk a  -
  parity chunk b  --
  parity chunk c---
  (--- means calculation ranges of each parity)

We called it a random aspect of SHEC's minimum_chunks.

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Friday, January 23, 2015 2:29 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com); Kaga, Yoshihiro/加賀 芳宏; Kawaguchi, 
Shotaro/川口 翔太朗
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

On 22/01/2015 17:34, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Thank you for the code reference. We will use it to improve our codes.
 
 However, I'm not sure I understand why you need threads at all to test the 
 plugin. Could you explain ?
 
 Sure. The purpose of using threads is just to find lace bugs and ensure 
 thread safety.

I'm not familiar with the expression lace bug and all I could find is 
http://en.wiktionary.org/wiki/lace which does not help me (I'm french, english 
is not my native language). Could you give me the definition of a lace bug ? 

 However, I suppose those tests may be a little adhoc and be far from 
 completeness.
 Actually, we couldn't detect some init lace bugs including #7914 (We will fix 
 those bugs at the next release).
 Do you have any better ideas to combat these kind of bugs systematically?
 

Race conditions such as http://tracker.ceph.com/issues/7914 are quite difficult 
detect with tests and I don't know of a sure method to do so. Carefully 
proofreading the code and keeping the logic simple is probably the most 
effective way ;-) Once a race condition has been fixed, however, it should be 
possible to recreate the conditions for it to appear in a functional test that 
can be run with make check.

Note that there are two kind of tests in Ceph : the unit / functional tests 
that are run with make check, locally on the developer machine or by a bot on 
each pull request. These tests run quickly and do not include any benchmarking 
or stress tests, nor integration tests. The second kind is what you find in 
teuthology : these tests include stress tests, error injections etc. Most race 
conditions are discovered by running these teuthology tests and analyzing their 
output.

 What do you think of my comments (about minimum_to_decode_3 and 
 minimum_to_decode_2 ) ?
 
 I don't think current minimum_to_decode_2 is adequate, as you mentioned.
 The verification of return codes is required and we will compare it with 
 expectations (EINVAL or EIO).
 However, as for the size of minimum_chunks, as it is hard to 
 pre-estimate without knowing parity layout because of its random aspect, we 
 won't improve it any more.

Do you mean that two consecutive runs of minimum_to_decode will provide 
different results ? 

 Then, as for minimum_to_decode_3, we found it meaningless to verify 
 minimum_chunks because that is an error case when array size of 
 want_to_decode and available_chunks are illegally large.
 We will verify only return code of minimum_to_decode and remove the 
 current check of minimum_chunks in minimum_to_decode_3.

Ok. I'll take a closer look as soon as I can run them and try things.

Thanks for explaining !

 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Thursday, January 22, 2015 6:28 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 On 22/01/2015 09:42, Miyamae, Takeshi wrote:
 Hi Loic,

 Thanks for your additional comments.

 Would you be so kind as to update the 
 https://github.com/t-miyamae/ceph/blob/master/src/test/erasure-code/
 M
 akefile.am

 Sure. We'll do that.

 This is likely to fail on a slow machine. Instead of waiting you should use 
 a lock.

 The purpose of sleep(1) is to ensure sequentiality between threads, 
 but it's not enough on slow

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

I'd appreciated your help very much.
I have just uploaded 2 test files into the fork repository.

https://github.com/t-miyamae/ceph
files:
  src/test/erasure-code/TestErasureCodeShec.cc
  src/test/erasure-code/TestErasureCodeShec364.cc

I'm sorry that tests for the thread safety codes has not been included yet.

Thank you in advance,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Tuesday, January 20, 2015 4:23 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com)
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

Thanks for the update. To speed up things, I could review what's already 
published. Did you add the tests already ?

Cheers

On 20/01/2015 01:48, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Thank you for your advice which suggested providing SHEC as an extra-package.
 We believe it's generally a good idea, but we are hoping SHEC would be 
 merged into Hammer because that would have an apparent advantage from 
 a viewpoint of maintenance support.
 
 As for the thread safety issue, we totally agree with you and we are trying 
 to solve it.
 We will complete it in a few days and we'd like to ask you to review 
 it again so that it might be in time for Hammer's feature freeze (v0.93).
 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Wednesday, January 14, 2015 3:03 AM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 On 13/01/2015 18:05, Miyamae, Takeshi wrote:
 Hi Loic,

 Thank you for your quick review.

 Could you reference the jerasure files (they are in the jerasure 
 plugin already) instead of including them in your patch ?

 We had used the reference of jerasure v2.0 files before, but changed 
 to including v1.2 files after the patent issue.
 
 If you are refering to http://erasure-code-patents.xyz/, it can safely be 
 ignored.
 
 However, we can restore the reference right away if we are needed.

 In ::prepare you reuse the matrix, if possible. If your intention is 
 to improve performances, you should consider using the same approach as the 
 isa plugin.

 We have found a performance issue caused by redundant initializations 
 of the module, and solved it by caching the initialized variables in memory.
 If that is the same approach as isa-plugin you mentioned, we also do 
 not have the same issue any more.
 
 The ISA plugin approach is thread safe, that's the important part.
 
 I'll have more comments once you have unit / functional tests

 We do have the those unit/functional tests, but the server is unreachable at 
 this moment.
 Please let us upload them to the repository tomorrow.
 
 Great.
 
 Regarding your initial question: I think it is too late for the Hammer 
 release.

 We are so disappointed to hear that, but we must apologize for the late 
 request.
 If there would be any chance that SHEC be pulled into hammer, we are 
 very happy to conduct all the necessary tests by ourselves.
 Please let us know the detailed schedule if this is a feasible option.
 
 Note that since this is a plugin it will be easy for someone to install it on 
 a Hammer cluster, simply by copying the plugin files to each OSD / MON and 
 restarting them. If there is some kind of urgency for you to be able to 
 install this new plugin, I would advise making a package that contains just 
 this file, restart the OSD once installed and recommend that the installation 
 is done on all machines of the cluster (because every OSD / MON need to know 
 about the plugin). 
 
 Cheers
 
 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Tuesday, January 13, 2015 9:46 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔;
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release
 (question)

 Hi,

 It's a great start :-) A few comments:

 Could you reference the jerasure files (they are in the jerasure plugin 
 already) instead of including them in your patch ?

 In ::prepare you reuse the matrix, if possible. If your intention is 
 to improve performances, you should consider using the same approach 
 as the isa plugin. See 
 http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/is
 a
 /ErasureCodePluginIsa.cc#L36 which is and independent type 
 http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

Thank you for your advice which suggested providing SHEC as an extra-package.
We believe it's generally a good idea, but we are hoping SHEC would be merged
into Hammer because that would have an apparent advantage from a viewpoint of
maintenance support.

As for the thread safety issue, we totally agree with you and we are trying to 
solve it.
We will complete it in a few days and we'd like to ask you to review it again 
so that
it might be in time for Hammer's feature freeze (v0.93).

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Wednesday, January 14, 2015 3:03 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com)
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

On 13/01/2015 18:05, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Thank you for your quick review.
 
 Could you reference the jerasure files (they are in the jerasure 
 plugin already) instead of including them in your patch ?
 
 We had used the reference of jerasure v2.0 files before, but changed 
 to including v1.2 files after the patent issue.

If you are refering to http://erasure-code-patents.xyz/, it can safely be 
ignored.

 However, we can restore the reference right away if we are needed.
 
 In ::prepare you reuse the matrix, if possible. If your intention is 
 to improve performances, you should consider using the same approach as the 
 isa plugin.
 
 We have found a performance issue caused by redundant initializations 
 of the module, and solved it by caching the initialized variables in memory.
 If that is the same approach as isa-plugin you mentioned, we also do 
 not have the same issue any more.

The ISA plugin approach is thread safe, that's the important part.

 I'll have more comments once you have unit / functional tests
 
 We do have the those unit/functional tests, but the server is unreachable at 
 this moment.
 Please let us upload them to the repository tomorrow.

Great.

 Regarding your initial question: I think it is too late for the Hammer 
 release.
 
 We are so disappointed to hear that, but we must apologize for the late 
 request.
 If there would be any chance that SHEC be pulled into hammer, we are 
 very happy to conduct all the necessary tests by ourselves.
 Please let us know the detailed schedule if this is a feasible option.

Note that since this is a plugin it will be easy for someone to install it on a 
Hammer cluster, simply by copying the plugin files to each OSD / MON and 
restarting them. If there is some kind of urgency for you to be able to install 
this new plugin, I would advise making a package that contains just this file, 
restart the OSD once installed and recommend that the installation is done on 
all machines of the cluster (because every OSD / MON need to know about the 
plugin). 

Cheers

 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Tuesday, January 13, 2015 9:46 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 It's a great start :-) A few comments:
 
 Could you reference the jerasure files (they are in the jerasure plugin 
 already) instead of including them in your patch ?
 
 In ::prepare you reuse the matrix, if possible. If your intention is 
 to improve performances, you should consider using the same approach 
 as the isa plugin. See 
 http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/isa
 /ErasureCodePluginIsa.cc#L36 which is and independent type 
 http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/isa
 /ErasureCodeIsaTableCache.h with only one instance and is populated as 
 needed and protected by a lock to make it thread safe : 
 http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/isa
 /ErasureCodeIsaTableCache.h#L101
 
 I'll have more comments once you have unit / functional tests ( similar to 
 http://workbench.dachary.org/ceph/ceph/blob/giant/src/test/erasure-code/TestErasureCodeJerasure.cc
  ). 
 
 Regarding your initial question: I think it is too late for the Hammer 
 release. But from what I read it looks like we'll be able to merge in the 
 early stages of the next release and that will give us time to properly test 
 it.
 
 Cheers
 
 On 13/01/2015 11:34, Miyamae, Takeshi wrote:
 Hi Loic,

 I'm so sorry. The following is the correct repository.

 https://github.com/t-miyamae/ceph

 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Tuesday, January 13, 2015 7:26 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

Thank you for your quick review.

 Could you reference the jerasure files (they are in the jerasure plugin 
 already)
 instead of including them in your patch ?

We had used the reference of jerasure v2.0 files before, but changed to 
including v1.2 files
after the patent issue.
However, we can restore the reference right away if we are needed.

 In ::prepare you reuse the matrix, if possible. If your intention is to 
 improve performances,
 you should consider using the same approach as the isa plugin.

We have found a performance issue caused by redundant initializations of the 
module,
and solved it by caching the initialized variables in memory.
If that is the same approach as isa-plugin you mentioned, we also do not have 
the same
issue any more.

 I'll have more comments once you have unit / functional tests

We do have the those unit/functional tests, but the server is unreachable at 
this moment.
Please let us upload them to the repository tomorrow.

 Regarding your initial question: I think it is too late for the Hammer 
 release.

We are so disappointed to hear that, but we must apologize for the late request.
If there would be any chance that SHEC be pulled into hammer, we are very happy 
to
conduct all the necessary tests by ourselves.
Please let us know the detailed schedule if this is a feasible option.

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Tuesday, January 13, 2015 9:46 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com)
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

It's a great start :-) A few comments:

Could you reference the jerasure files (they are in the jerasure plugin 
already) instead of including them in your patch ?

In ::prepare you reuse the matrix, if possible. If your intention is to improve 
performances, you should consider using the same approach as the isa plugin. 
See 
http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/isa/ErasureCodePluginIsa.cc#L36
 which is and independent type 
http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/isa/ErasureCodeIsaTableCache.h
 with only one instance and is populated as needed and protected by a lock to 
make it thread safe : 
http://workbench.dachary.org/ceph/ceph/blob/giant/src/erasure-code/isa/ErasureCodeIsaTableCache.h#L101

I'll have more comments once you have unit / functional tests ( similar to 
http://workbench.dachary.org/ceph/ceph/blob/giant/src/test/erasure-code/TestErasureCodeJerasure.cc
 ). 

Regarding your initial question: I think it is too late for the Hammer release. 
But from what I read it looks like we'll be able to merge in the early stages 
of the next release and that will give us time to properly test it.

Cheers

On 13/01/2015 11:34, Miyamae, Takeshi wrote:
 Hi Loic,
 
 I'm so sorry. The following is the correct repository.
 
 https://github.com/t-miyamae/ceph
 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: Loic Dachary [mailto:l...@dachary.org]
 Sent: Tuesday, January 13, 2015 7:26 PM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; 
 Paul Von-Stamwitz (pvonstamw...@us.fujitsu.com)
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 On 13/01/2015 11:24, Miyamae, Takeshi wrote:
 Hi Loic,

 Although we're late in the Hammer roadmap, it's a good time for an early 
 preview. It will help show what needs to be changed to accomodate the SHEC 
 plugin.

 Thank you for your advices.
 We have uploaded our latest codes to the following folk repository for an 
 early review.

 https://github.com/miyamae-takeshi/multiple-shec
 
 It's 404 ? Is it a private repository maybe ?
 

 SHEC is located in src/erasure-code/shec directory.

 We are verifying SHEC's advantages on our Ceph cluster. It takes a little 
 bit more.
 Would you please start the review before that?

 Best regards,
 Takeshi Miyamae

 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Wednesday, January 7, 2015 12:52 AM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
 Subject: Re: Deadline of Github pull request for Hammer release
 (question)

 Hi,

 On 06/01/2015 12:49, Miyamae, Takeshi wrote:
 Dear Loic,

 I'm Takeshi Miyamae, one of the authors of SHEC's blueprint.

 Shingled Erasure Code (SHEC)
 https://wiki.ceph.com/Planning/Blueprints/Hammer/Shingled_Erasure_Co
 d
 e
 _(SHEC)

 The work you have done is quite impressive :-)

 We have revised our blueprint shown in the last CDS to extend our 
 erasure code layouts and describe the guideline for choosing SHEC among 
 various EC plugins.
 We believe

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

 Although we're late in the Hammer roadmap, it's a good time for an early 
 preview. It will help show what needs to be changed to accomodate the SHEC 
 plugin.

Thank you for your advices.
We have uploaded our latest codes to the following folk repository for an early 
review.

https://github.com/miyamae-takeshi/multiple-shec

SHEC is located in src/erasure-code/shec directory.

We are verifying SHEC's advantages on our Ceph cluster. It takes a little bit 
more.
Would you please start the review before that?

Best regards,
Takeshi Miyamae

-Original Message-
From: ceph-devel-ow...@vger.kernel.org 
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
Sent: Wednesday, January 7, 2015 12:52 AM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

On 06/01/2015 12:49, Miyamae, Takeshi wrote:
 Dear Loic,
 
 I'm Takeshi Miyamae, one of the authors of SHEC's blueprint.
 
 Shingled Erasure Code (SHEC)
 https://wiki.ceph.com/Planning/Blueprints/Hammer/Shingled_Erasure_Code
 _(SHEC)

The work you have done is quite impressive :-)

 We have revised our blueprint shown in the last CDS to extend our 
 erasure code layouts and describe the guideline for choosing SHEC among 
 various EC plugins.
 We believe the blueprint now answers all the comments given at the CDS.

Great.

 In addition, we would like to ask for your advice on the schedule of 
 our github pull request. More specifically, we would like to know its 
 deadline for Hammer release.
 (As we have not really completed our verification of SHEC, we are 
 wondering if we should make it open for early preview.)

Although we're late in the Hammer roadmap, it's a good time for an early 
preview. It will help show what needs to be changed to accomodate the SHEC 
plugin.

Cheers

 Thank you in advance,
 Takeshi Miyamae
 
 --
 To unsubscribe from this list: send the line unsubscribe ceph-devel 
 in the body of a message to majord...@vger.kernel.org More majordomo 
 info at  http://vger.kernel.org/majordomo-info.html
 

--
Loïc Dachary, Artisan Logiciel Libre

RE: Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Hi Loic,

I'm so sorry. The following is the correct repository.

https://github.com/t-miyamae/ceph

Best regards,
Takeshi Miyamae

-Original Message-
From: Loic Dachary [mailto:l...@dachary.org] 
Sent: Tuesday, January 13, 2015 7:26 PM
To: Miyamae, Takeshi/宮前 剛
Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔; Paul 
Von-Stamwitz (pvonstamw...@us.fujitsu.com)
Subject: Re: Deadline of Github pull request for Hammer release (question)

Hi,

On 13/01/2015 11:24, Miyamae, Takeshi wrote:
 Hi Loic,
 
 Although we're late in the Hammer roadmap, it's a good time for an early 
 preview. It will help show what needs to be changed to accomodate the SHEC 
 plugin.
 
 Thank you for your advices.
 We have uploaded our latest codes to the following folk repository for an 
 early review.
 
 https://github.com/miyamae-takeshi/multiple-shec

It's 404 ? Is it a private repository maybe ?

 
 SHEC is located in src/erasure-code/shec directory.
 
 We are verifying SHEC's advantages on our Ceph cluster. It takes a little bit 
 more.
 Would you please start the review before that?
 
 Best regards,
 Takeshi Miyamae
 
 -Original Message-
 From: ceph-devel-ow...@vger.kernel.org 
 [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Loic Dachary
 Sent: Wednesday, January 7, 2015 12:52 AM
 To: Miyamae, Takeshi/宮前 剛
 Cc: Ceph Development; Shiozawa, Kensuke/塩沢 賢輔; Nakao, Takanori/中尾 鷹詔
 Subject: Re: Deadline of Github pull request for Hammer release 
 (question)
 
 Hi,
 
 On 06/01/2015 12:49, Miyamae, Takeshi wrote:
 Dear Loic,

 I'm Takeshi Miyamae, one of the authors of SHEC's blueprint.

 Shingled Erasure Code (SHEC)
 https://wiki.ceph.com/Planning/Blueprints/Hammer/Shingled_Erasure_Cod
 e
 _(SHEC)
 
 The work you have done is quite impressive :-)
 
 We have revised our blueprint shown in the last CDS to extend our 
 erasure code layouts and describe the guideline for choosing SHEC among 
 various EC plugins.
 We believe the blueprint now answers all the comments given at the CDS.
 
 Great.
 
 In addition, we would like to ask for your advice on the schedule of 
 our github pull request. More specifically, we would like to know its 
 deadline for Hammer release.
 (As we have not really completed our verification of SHEC, we are 
 wondering if we should make it open for early preview.)
 
 Although we're late in the Hammer roadmap, it's a good time for an early 
 preview. It will help show what needs to be changed to accomodate the SHEC 
 plugin.
 
 Cheers
 
 Thank you in advance,
 Takeshi Miyamae

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

 
 --
 Loïc Dachary, Artisan Logiciel Libre
 

--
Loïc Dachary, Artisan Logiciel Libre

N�r��yb�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

Deadline of Github pull request for Hammer release (question)

[Miyamae, Takeshi]

Dear Loic,

I'm Takeshi Miyamae, one of the authors of SHEC's blueprint.

Shingled Erasure Code (SHEC)
https://wiki.ceph.com/Planning/Blueprints/Hammer/Shingled_Erasure_Code_(SHEC)

We have revised our blueprint shown in the last CDS to extend our erasure code
layouts and describe the guideline for choosing SHEC among various EC plugins.
We believe the blueprint now answers all the comments given at the CDS.

In addition, we would like to ask for your advice on the schedule of our github
pull request. More specifically, we would like to know its deadline for Hammer
release.
(As we have not really completed our verification of SHEC, we are wondering if
we should make it open for early preview.)

Thank you in advance,
Takeshi Miyamae

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