Re: [PATCH] nilfs2: insert checkpoint number in segment summary header

[Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>]

Hi Reinoud,
On Sun, 2 May 2010 12:50:58 +0200, Reinoud Zandijk <reinoud-qavaossjCcEdnm+yROfE0A@public.gmane.org> wrote:
> Hi Ryusuke,
> 
> On Sat, Apr 10, 2010 at 08:07:31PM +0900, Ryusuke Konishi wrote:
> > This patch extends the format of segment summary so that it stores a
> > checkpoint number in the header.  This is normally not used, but I
> > think this would help recovery from critcal situation in which the
> > filesystem has lost its pointer to the latest log.
> 
> that sounds like i good plan. I'm not that happy about the position in the
> structure you added the cno to...
> 
> What i miss in the patch is the roll-forward support for this. The field
> `sector_t next' has moved but i dont see any reference in the patch that takes
> into account the size of the structure to see if the `next' field has shifted
> position or not. Am i missing/overseeing a thing?

There seems a misunderstanding on use of the structure in question.

nilfs_segsum_info is an on-memory structure and is not for the on-disk
format.  The on-disk summary header is defined by
nilfs_segment_summary as below:

> diff --git a/include/linux/nilfs2_fs.h b/include/linux/nilfs2_fs.h
> index 640702e..f642e8a 100644
> --- a/include/linux/nilfs2_fs.h
> +++ b/include/linux/nilfs2_fs.h
> @@ -377,6 +377,7 @@ union nilfs_binfo {
>  * @ss_nfinfo: number of finfo structures
>  * @ss_sumbytes: total size of segment summary in bytes
>  * @ss_pad: padding
> + * @ss_cno: checkpoint number
>  */
>  struct nilfs_segment_summary {
>        __le32 ss_datasum;
> @@ -391,6 +392,7 @@ struct nilfs_segment_summary {
>        __le32 ss_nfinfo;
>        __le32 ss_sumbytes;
>        __le32 ss_pad;
> +       __le64 ss_cno;
>        /* array of finfo structures */
>  };

The checkpoint number field is appended to the tail in order to keep
compatibility; the ``next'' and other fields are not moved in the
header.

nilfs_segsum_info is volatile, so we don't have to care about the
order except for the viewpoint of optimization or simplicity.
 
> P.S. the write support of the NetBSD NiLFS implementation has been delayed
> quite some time due to simple lack of time (AKA too many projects running
> simultaniously) but after some time dormant i've picked it up again.

Me neither for lack of time, thanks anyway :)

With regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html