[sheepdog] [PATCH] journal: refactor the journaling subsystem

Kai Zhang kyle at zelin.io
Tue Jun 25 03:41:05 CEST 2013


On Jun 24, 2013, at 11:54 PM, Hitoshi Mitake <mitake.hitoshi at gmail.com> wrote:

> At Mon, 24 Jun 2013 02:20:59 -0700,
> Kai Zhang wrote:
>> 
>> Hitoshi Mitake <mitake.hitoshi at gmail.com> writes:
>> 
>>> At Mon, 24 Jun 2013 01:31:41 -0700,
>>> Kai Zhang wrote:
>>>> 
>>>> Hitoshi Mitake <mitake.hitoshi at lab.ntt.co.jp> writes:
>>>> 
>>>>> Current journaling subsystem has some dirty parts because of its old
>>>>> journal descriptor types (epoch and config). This patch cleans them.
>>>>> 
>>>>> Signed-off-by: Hitoshi Mitake <mitake.hitoshi at lab.ntt.co.jp>
>>>>> ---
>>>>> sheep/journal.c |   31 +++++++++++++++----------------
>>>>> 1 files changed, 15 insertions(+), 16 deletions(-)
>>>>> 
>>>>> diff --git a/sheep/journal.c b/sheep/journal.c
>>>>> index 50783f2..f1f94da 100644
>>>>> --- a/sheep/journal.c
>>>>> +++ b/sheep/journal.c
>>>>> @@ -137,21 +137,18 @@ static bool journal_entry_full_write(struct journal_descriptor *jd)
>>>>> 
>>>>> static void journal_get_path(struct journal_descriptor *jd, char *path)
>>>>> {
>>>>> -	switch (jd->flag) {
>>>>> -	case JF_STORE:
>>>>> -	case JF_REMOVE_OBJ:
>>>>> -		snprintf(path, PATH_MAX, "%s/%016"PRIx64,
>>>>> -			 md_get_object_path(jd->oid), jd->oid);
>>>>> -		if (jd->flag == JF_STORE)
>>>>> -			sd_iprintf("%s, size %"PRIu64", off %"PRIu64", %d",
>>>>> -				path, jd->size, jd->offset, jd->create);
>>>>> -		else		/* JF_REMOVE_OBJ */
>>>>> -			sd_iprintf("%s (remove)", path);
>>>>> -		break;
>>>>> -	default:
>>>>> -		panic("unknown type of journal flag: %d", jd->flag);
>>>>> -		break;
>>>>> -	}
>>>>> +	snprintf(path, PATH_MAX, "%s/%016"PRIx64,
>>>>> +		md_get_object_path(jd->oid), jd->oid);
>>>>> +
>>>>> +	if (jd->flag == JF_STORE)
>>>>> +		sd_iprintf("%s, size %"PRIu64", off %"PRIu64", %d",
>>>>> +			path, jd->size, jd->offset, jd->create);
>>>>> +	else if (jd->flag == JF_REMOVE_OBJ)
>>>>> +		sd_iprintf("%s (remove)", path);
>>>>> +	else
>>>>> +		panic("unknown type of journal flag,"
>>>>> +			" the journal flag seems to be corrupted: %d",
>>>>> +			jd->flag);
>>>>> }
>>>>> 
>>>>> static int replay_journal_entry(struct journal_descriptor *jd)
>>>>> @@ -168,6 +165,8 @@ static int replay_journal_entry(struct journal_descriptor *jd)
>>>>> 		return 0;
>>>>> 	}
>>>>> 
>>>>> +	assert(jd->flag == JF_STORE);
>>>>> +
>>>> 
>>>> Because journal_get_path(jd, patch) is needed whenever jd->flag is
>>>> JF_REMOVE_OBJ or JF_STORE, I think we can put it to the top to clean the code.
>>>> And because the value of jd->flag will be checked by both journal_get_path(),
>>>> and this assert, so it would be better to check it in one place.
>>>> The modifide code would be like:
>>>> 
>>>> journal_get_path(jd, path); // no check
>>>> if (jd->flag == JF_REMOVE_OBJ) {
>>>>   unlink(path);
>>>>   return 0;
>>>> } else if (jd->flag == JF_RESTORE) {
>>>>   /* restore logic here */
>>> 
>>> Do you mean STORE?
>>> 
>> 
>> Sorry, my mistake. It should be STORE.
>> 
>>>> } else {
>>>>   panic(...);
>>>> }
>>>> 
>>>> A switch case is also a good choice.
>>> 
>>> Because current journal entry has only two types, the above
>>> indentation of /* restore logic here */ or switch statements would be
>>> too flowery.
>>> 
>> 
>> How about a helper function to wrap them up?
>> Anyway, maybe this is not a big issue.
> 
> Do you mean implementing functions for each types of journal entry? I
> feel it is an over abstraction.
> 
>> But what I stressed is that journal_get_path() and the logic of checking
>> jd->flag were duplicated. And there is a way to clean them.
>> 
> 
> IIUC, you think that the assert(jd->flag == JF_STORE); is
> redundant. Of course we can remove the assert practically. But I added
> the assert mainly for documentation. And it produces no runtime
> overhead. I believe this would be helpful for understanding of other
> developers.


I see.
Maybe it's just a matter of taste.
And because I'm not a maintainer currently, please ignore my comments and
wait for Yuan or Kazutaka to merge this patch.

Thanks,
Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/sheepdog/attachments/20130625/72d952f1/attachment-0004.html>


More information about the sheepdog mailing list