Hi folks

I think Ian's comments below summarise the issues very well.

On Wednesday 03 August 2005 02:52, Ian McDonnell wrote:
> On Tuesday 02 August 2005 04:02
>
> manningc2@actrix.gen.nz wrote:
> > AT present, YAFFS2 uses 64-bit times for WinCE and 32-bits for
> > other stuff.
> >
> > IMHO it would be best to use 64 bit for everything internally
> > and use some sort of fudge factor for 2.4 kernel.
> >
> > Benefits:
> > 1) Get the feature in OSs that support it.
> > 2) Get rid of ugly #ifdef WINCE stuff in the code.
> >
> > Unless there is a noise to the negative, I'll do this in two
> > days or so.
>
> Here's an opinion... and this is just for your consideration,
> I understand your motive for change and it looks like you are
> only considering the in-memory timestamps, not those in flash,
> is that right?

I would like to change the in-flash ones too. There is not much point in just 
changing the in-ram ones.
>
> Long-term stability in the on-media data format is very
> desireable. I'm sure you have given a lot of thought to what's
> actually layed-down in flash.  We have (user) data in NAND that
> *will* outlive the version of YAFFS/MTD code that created it.
> We will need to access data in NAND in whatever format it happens
> to be in.  It is not easy to save, reformat and reinstall data
> from NAND in an isolated embedded system where there is more
> data than free RAM.

This was actually my primary concern, and here is how I suggest it could be 
handled:

There are currently two areas set aside for times and only one or the other 
are used:

#ifdef CONFIG_YAFFS_WINCE
	__u32 notForWinCE[5];
#else
	__u32 yst_uid;   // user ID of owner
	__u32 yst_gid;    // group ID of owner 
	__u32 yst_atime; // time of last access
	__u32 yst_mtime; // time of last modification
	__u32 yst_ctime; // time of last change
#endif

<snip>

#ifdef CONFIG_YAFFS_WINCE
	__u32 win_ctime[2];
	__u32 win_atime[2];
	__u32 win_mtime[2];
	__u32 roomToGrow[4];
#else
	__u32 roomToGrow[10];
#endif

This would change to:

	__u32 yst_uid;   // user ID of owner
	__u32 yst_gid;    // group ID of owner 
	__u32 yst_atime32;/ time of last access
	__u32 yst_mtime32;/ time of last modification
	__u32 yst_ctime32;/ time of last change


<snip>

	__u32 yst_ctime64[2];
	__u32 yst_atime64[2];
	__u32 yst_mtime64[2];
	__u32 roomToGrow[4];



What I was thinking was to have yaffs understand both according to the 
following rules:
* Reserve both areas in their current positions.
* Write both
* When reading, if the 64-bit time is available (ie not 0xFF), then use it 
else use the 32-bit time.



>
> We recently hit an issue with the ECC byte ordering. We have
> thousands of units in the field that run with the original YAFFS
> code on small-page NAND, now we have moved to the YAFFS2 code
> base (to support large-page devices) and have found that the
> MTD-based ECC has different on-NAND byte ordering when running
> in YAFFS1 mode.  Of course we have fixed this with a simple
> change to the code which we will have to maintain.  Some users
> have a real need to support older formats 'forever', and it
> would be very nice if YAFFS could be built to support its older
> formats without too much hacking.

I have tried to only modify stuff by addition, ie by whittling at the 
roomToGrow.

I think the above will be OK, but your comments would be appreciated.

<snip>

-- CHarles