At Mon, 29 Apr 2013 23:36:21 +0900,
Hitoshi Mitake wrote:
>
> This patch lets sheepdog employ gnu99 (C99 + gnu extensions) style of
> GCC. The main benefit of gnu99 is allowing interleaved statements and
> declarations. sheepdog source tree has many functions with lots of
> local variable declarat
At Tue, 30 Apr 2013 09:14:19 +0900,
Hitoshi Mitake wrote:
>
> Current lockf() usage in lock_base_dir() is invalid bacause sheep
> calls daemon(3) after the lockf(). daemon(3) forks internally and a
> parent process exits immediately. In a case of sheep, daemon() must be
> called after locking base
On 04/29/2013 11:18 PM, Hitoshi Mitake wrote:
> Sorry, the second is incorrect. The notation like this cause errors
> even if -std=gnu99 is passed to gcc:
> struct journal_descriptor jd = {
> .magic = JOURNAL_DESC_MAGIC,
> .flag = JF_EPOCH,
> .epoch =
At Sun, 28 Apr 2013 11:15:41 +0800,
harryxiyou wrote:
>
> Hi all,
>
> I have known Sheepdog for a log time and cannot understand its
> core framework so i just wanna participate into some features'
> development to understand Sheepdog more clearly. Could anyone
> give me some suggestions?
Here a
Current lockf() usage in lock_base_dir() is invalid bacause sheep
calls daemon(3) after the lockf(). daemon(3) forks internally and a
parent process exits immediately. In a case of sheep, daemon() must be
called after locking base dir so the lock owner, parent process, exits
and the lock will be re
At Tue, 30 Apr 2013 02:37:12 +0900,
MORITA Kazutaka wrote:
>
> At Mon, 29 Apr 2013 12:19:15 +0900,
> Hitoshi Mitake wrote:
> >
> > sheep employes lockf() for mutex of lock_base_dir() now. But the
> > lockf() is not suitable for sheep bacause sheep calls daemon(3) after
>
> This comment looks str
At Mon, 29 Apr 2013 12:19:15 +0900,
Hitoshi Mitake wrote:
>
> sheep employes lockf() for mutex of lock_base_dir() now. But the
> lockf() is not suitable for sheep bacause sheep calls daemon(3) after
This comment looks strange because you use lockf() after all.
Otherwise looks good to me.
Thanks
At Tue, 30 Apr 2013 00:08:28 +0900,
Hitoshi Mitake wrote:
> 2. Unnamed struct/union fields:
>http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields
>With this feature, journal_write_store() and journal_write_epoch()
>can be cleaner.
Sorry, the second is incorrect. The not
At Mon, 29 Apr 2013 22:52:09 +0800,
Liu Yuan wrote:
>
> On 04/29/2013 10:25 PM, Hitoshi Mitake wrote:
> > Oops, sorry. The above macro doesn't work well with the line like this:
> > cache->lru_tree = RB_ROOT;
> > # 594 of object_cache.c
> >
> > I think these sort of initialization sho
On 04/29/2013 10:25 PM, Hitoshi Mitake wrote:
> Oops, sorry. The above macro doesn't work well with the line like this:
> cache->lru_tree = RB_ROOT;
> # 594 of object_cache.c
>
> I think these sort of initialization should be done with a macro like
> INIT_LIST_HEAD(). Is it okay to i
This patch lets sheepdog employ gnu99 (C99 + gnu extensions) style of
GCC. The main benefit of gnu99 is allowing interleaved statements and
declarations. sheepdog source tree has many functions with lots of
local variable declarations on their head part. They are harmful from
the perspective of rea
At Mon, 29 Apr 2013 22:26:30 +0900,
Hitoshi Mitake wrote:
>
> At Mon, 29 Apr 2013 20:48:47 +0800,
> Liu Yuan wrote:
> >
> > On 04/29/2013 08:38 PM, Hitoshi Mitake wrote:
> > > Of course I don't say variable declarations is the most important
> > > problem for source code readability. Its role is
At Mon, 29 Apr 2013 21:43:05 +0800,
Liu Yuan wrote:
> > Dividing these switches into functoins and jump tables would be a
> > better way, but it cannnot be optimal always. Because the local
> > variables in original function should be passed as their
> > parameters. If there are many local variable
On 04/29/2013 09:26 PM, Hitoshi Mitake wrote:
> Removing the RB_ROOT was overkill. This is my mistake. It can be
> implemented like this under gnu99:
> #define RB_ROOT { NULL }
>
Okay. If we don't pay price, then it is nice to have gnu-c99 with more
features.
>
>> >
> > >> >
> > >> >
At Mon, 29 Apr 2013 20:48:47 +0800,
Liu Yuan wrote:
>
> On 04/29/2013 08:38 PM, Hitoshi Mitake wrote:
> > Of course I don't say variable declarations is the most important
> > problem for source code readability. Its role is very little. But I
> > strongly believe that variables with narrow scope
At Mon, 29 Apr 2013 20:55:39 +0800,
Liu Yuan wrote:
>
> From: Liu Yuan
>
> tests/010 will fail sometimes to catch this bug.
>
> When auto-recover is disabled, if we prepare_schedule_oid on the same oid
> multiple times, it will break finish_schedule_oid to wrongly squeeze some
> victim oid out
>
> One more question, does RHEL 5 support GNU-C99 fully? And other platform
> such as old debian, you know, many servers in production is very
> conventional and impossible to upgrade GCC.
We don't have to take into account at least RHEL5 because its kernel
doesn't support timerfd and signalfd a
At Mon, 29 Apr 2013 20:21:25 +0800,
Liu Yuan wrote:
>
> From: Liu Yuan
>
> Signed-off-by: Liu Yuan
> ---
> sheep/vdi.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
Applied, thanks!
Kazutaka
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wp
From: Liu Yuan
tests/010 will fail sometimes to catch this bug.
When auto-recover is disabled, if we prepare_schedule_oid on the same oid
multiple times, it will break finish_schedule_oid to wrongly squeeze some
victim oid out of rw->oids array, then this node will never have a chance to
recover
On 04/29/2013 08:49 PM, MORITA Kazutaka wrote:
> Why do you move resume_suspended_recovery()? If the oid is not
> scheduled, we don't have to call this function.
Because finish_schedule_oid should be seen after prepare_schedule_oid in
the log. Anyway, we should just move resume_suspended_recover
At Mon, 29 Apr 2013 20:31:02 +0800,
Liu Yuan wrote:
>
> From: Liu Yuan
>
> tests/010 will fail sometimes to catch this bug.
>
> When auto-recover is disabled, if we prepare_schedule_oid on the same oid
> multiple times, it will break finish_schedule_oid to wrongly squeeze some
> victim oid out
On 04/29/2013 08:38 PM, Hitoshi Mitake wrote:
> Of course I don't say variable declarations is the most important
> problem for source code readability. Its role is very little. But I
> strongly believe that variables with narrow scope can contribute to
> the readability. e.g. If we write a variabl
At Mon, 29 Apr 2013 17:41:27 +0800,
Liu Yuan wrote:
>
> On 04/29/2013 05:15 PM, Hitoshi Mitake wrote:
> > This patch lets sheepdog employ gnu99 (C99 + gnu extensions) style of
> > GCC. The main benefit of gnu99 is allowing interleaved statements and
> > declarations.
>
> The idea doesn't look ap
From: Liu Yuan
tests/010 will fail sometimes to catch this bug.
When auto-recover is disabled, if we prepare_schedule_oid on the same oid
multiple times, it will break finish_schedule_oid to wrongly squeeze some
victim oid out of rw->oids array, then this node will never have a chance to
recover
From: Liu Yuan
Signed-off-by: Liu Yuan
---
sheep/vdi.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/sheep/vdi.c b/sheep/vdi.c
index 8b7a11f..5ed784f 100644
--- a/sheep/vdi.c
+++ b/sheep/vdi.c
@@ -498,17 +498,18 @@ int vdi_create(struct vdi_iocb *
On 04/29/2013 08:07 PM, MORITA Kazutaka wrote:
> The second and later oids may be already scheduled ones.
> prepare_schedule_oid() can re-schedule them and re-order rw->oids
> again unnecessarily. Anyway, that's not a big problem.
>
I suspect it would be problem for running many OS on the node.
At Mon, 29 Apr 2013 19:00:06 +0800,
Liu Yuan wrote:
>
> From: Liu Yuan
>
> Signed-off-by: Liu Yuan
> ---
> sheep/vdi.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/sheep/vdi.c b/sheep/vdi.c
> index 8b7a11f..b3bd0cb 100644
> --- a/sheep/vdi
At Mon, 29 Apr 2013 15:19:53 +0800,
Liu Yuan wrote:
>
> On 04/29/2013 02:59 PM, MORITA Kazutaka wrote:
> > Thanks, I understood what's going on from your log.
> >
> > The problem is that scheduled oids can be re-scheduled again. I think
> > the following is a better fix because it also omits red
At Mon, 29 Apr 2013 18:22:34 +0800,
Liu Yuan wrote:
>
> On 04/29/2013 06:35 AM, MORITA Kazutaka wrote:
> > I think changing the order of these two functions makes it very hard
> > to review this patch. Can you prepare another one to change this
> > order?
>
> You mean two different patches to sq
At Mon, 29 Apr 2013 18:18:31 +0800,
Liu Yuan wrote:
>
> On 04/29/2013 06:26 AM, MORITA Kazutaka wrote:
> > If we can safely read the inode from cache, please explain the reason
> > in the commit log.
> >
> > Perhaps, vdi_get_inode() has to call read_backend_object() instead of
> > read_object()?
On 04/29/2013 08:38 AM, MORITA Kazutaka wrote:
> This increases performance of vdi traversing.
Applied, thanks.
Yuan
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
From: Liu Yuan
Signed-off-by: Liu Yuan
---
sheep/vdi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sheep/vdi.c b/sheep/vdi.c
index 1434971..eb57d13 100644
--- a/sheep/vdi.c
+++ b/sheep/vdi.c
@@ -552,7 +552,7 @@ struct deletion_work {
uint32_t done;
From: Liu Yuan
Signed-off-by: Liu Yuan
---
sheep/ops.c|6 +++---
sheep/sheep_priv.h |8
sheep/store.c | 18 -
sheep/vdi.c| 56 +---
4 files changed, 37 insertions(+), 51 deletions(-)
diff
From: Liu Yuan
Signed-off-by: Liu Yuan
---
collie/collie.h |4 ++--
collie/common.c |4 ++--
collie/node.c|2 +-
collie/vdi.c | 42 +-
include/sheepdog_proto.h |8
sheep/plain_store.c
From: Liu Yuan
Signed-off-by: Liu Yuan
---
sheep/vdi.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/sheep/vdi.c b/sheep/vdi.c
index 8b7a11f..b3bd0cb 100644
--- a/sheep/vdi.c
+++ b/sheep/vdi.c
@@ -498,17 +498,18 @@ int vdi_create(struct vdi_iocb *
From: Liu Yuan
v2:
- just send first 4 patchse that doesn't have controversion
Patch 1-5 are mainly prepare patches
Patch 6 refactor start_deletion
1.7.9.5
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
On 04/29/2013 06:35 AM, MORITA Kazutaka wrote:
> I think changing the order of these two functions makes it very hard
> to review this patch. Can you prepare another one to change this
> order?
You mean two different patches to squash each functions? these two
functions as well as vdi_fill_list()
On 04/29/2013 06:26 AM, MORITA Kazutaka wrote:
> If we can safely read the inode from cache, please explain the reason
> in the commit log.
>
> Perhaps, vdi_get_inode() has to call read_backend_object() instead of
> read_object()?
I'm not sure. Current object cache will be released after we shutd
On 04/29/2013 05:15 PM, Hitoshi Mitake wrote:
> This patch lets sheepdog employ gnu99 (C99 + gnu extensions) style of
> GCC. The main benefit of gnu99 is allowing interleaved statements and
> declarations.
The idea doesn't look appealing to me. This will increase the complier
dependency and the p
This patch lets sheepdog employ gnu99 (C99 + gnu extensions) style of
GCC. The main benefit of gnu99 is allowing interleaved statements and
declarations. sheepdog source tree has many functions with lots of
local variable declarations on their head part. They are harmful from
the perspective of rea
On 04/29/2013 02:59 PM, MORITA Kazutaka wrote:
> Thanks, I understood what's going on from your log.
>
> The problem is that scheduled oids can be re-scheduled again. I think
> the following is a better fix because it also omits redundant
> scheduling even when auto-recovery is enabled.
Why bett
At Mon, 29 Apr 2013 15:59:03 +0900,
MORITA Kazutaka wrote:
>
> At Mon, 29 Apr 2013 13:15:55 +0800,
> Liu Yuan wrote:
> >
> > On 04/29/2013 07:15 AM, MORITA Kazutaka wrote:
> > > When auto-recovery is disabled, sheep recovers the objects only in
> > > prio_oids and shouldn't reach here if the oid
42 matches
Mail list logo
