Hi Charles,

Charles Manning wrote:

>short byteCount is OK. short chunkId limits the file size to 64k  chunks == 
>128MBytes (too small for some systems). short objectId limits the fs to 64k 
>files (probably OK).
>short sequenceNumber is most definitely **not** OK since this is incremented 
>every time a new block is allocated. That would limit the fs usage.
>
>There is also an issue that the tag fields get overloaded with other values to 
>speed scanning. Making the fields too tight will break that. For example, we 
>sometimes stash the whole file size in byteCount. Having file sizes limited 
>to 64k would be a bit depressing. If you use your scheme, please disable all 
>the extraHeader code in yaffs_PackTags2() and yaffs_UnpackTags2(). yaffs2 
>works fine without the extraheader stuff and will just use it if it is 
>available.
>
>I'll think a bit about this, but I think a more compressed packed tags 
>structure could fit in 16 bytes including the ecc on tags and only minimal 
>loss of exta header tags etc.
>
>Perhaps something like the following will work pretty well (but some mods 
>required to the extended header stuff):
>
>typedef struct __attribute__((packed)) {
>    unsigned sequenceNumber;
>    unsigned objectId:24;
>    unsigned colParity:8;
>    unsigned chunkId:24;
>    unsigned lineParity:8;
>    unsigned byteCount:24;
>    unsigned  lineParityPrime:8;
>} yaffs_PackedTags2TagsPart;
>
>  
>
Thanks for your explanations, packed tags being 16 bytes long  work 
quite fine for me.
Anyhing that is not more than 20 is fine. :)

Looking forward to having such an option for yaffs2 to be able to 
implement its support on my target without hacks,

Thanks,
   Vitaly