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
(text/plain)