Hi Reinoud,
On Sun, 2 May 2010 12:50:58 +0200, Reinoud Zandijk <reinoud@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
