[sheepdog] [PATCH v5 5/7] sheep: rename journal_file.c as journal.c

[Hitoshi Mitake]

> +/* FIXME: Try not sleep inside lock */
> +static void switch_journal_file(void)
> +{
> +	int old = jfile.fd, err;
> +	pthread_t thread;
> +
> +retry:
> +	if (!uatomic_set_true(&jfile.in_commit)) {
> +		sd_eprintf("journal file in committing, "
> +			   "you might need enlarge jfile size");
> +		usleep(100000); /* Wait until committing is finished */
> +		goto retry;
> +	}
>  
> -		ret = xpread(jd.fd, &end_mark, sizeof(end_mark),
> -				sizeof(jd.head) + jd.head.size);
> -		if (ret != sizeof(end_mark)) {
> -			sd_eprintf("can't read journal end mark for object %s",
> -				   jd.head.target_path);
> -			goto end_while_2;
> -		}
> +	if (old == jfile_fds[0])
> +		jfile.fd = jfile_fds[1];
> +	else
> +		jfile.fd = jfile_fds[0];
> +	jfile.commit_fd = old;
> +	jfile.pos = 0;
>  

I have a naive question about the design of this journaling
mechanism. It seems that jfile.pos is increased when new journal entry
is appended and is set as 0 when switching of journal files is caused.

So the replay_journal_entry() has a possibility of overwriting epoch,
config, and object with identical data which is already stored in the
files. This may cause an overhead during initialization process of
sheep.

Is my understanding correct?

I'm not blaming the overhead. If my understanding is correct, we
should add this point to a guideline of determining journaling
parameters. I want to make the point clear.

Thanks,
Hitoshi