On Thursday 11 February 2010 11:29:59 Steve Zook wrote:
>> I'm a little murky on an algorithmic aspect of the yaffs2 and I was
hoping
>> to get educated. I've read all the theory materials but could not find an
>> answer to the question.
>>
>> When an object gets deleted, a new header gets written to media to mark
the
>> object as deleted. The deleting header should always be, sequence number
>> wise, last for that object. When the block containing the deleting header
>> gets garbage collected, how does it get decided whether to copy the
>> deleting header or to drop it?

>This is different for the yaffs1 vs yaffs2 modes of operation. From what 
>you're saying it looks like you're talking about the yaffs2 mode of 
>operation.

Yes, indeed I'm talking about the yaffs2 mode. The yaffs1 mode easily
handles this kind of thing by marking all obsolete chunks (object headers
and data). Obsolete things never get copied and are skipped during scanning,
case closed.

>yaffs also tracks the number of data chunks per file. When that number
drops 
>to zero the header chunk becomes deleted and the gc will no longer copy it.
> <snip>
> <snip>

An example of a case I'm concerned with (a bit overly simplified for
illustration) is:

  Create a file (with object header as last chunk in block A).
  Write data (all data chunks in block B).
  Close file (new object header written as last chunk in block B).
  Delete file (new object header is first chunk in Block C).

At this point, only the object header in C is active, all older object
headers and data chunks are inactive.

  Garbage collect and/or Erase block B. Block B can simply be erased because
there are no active chunks in it (I don't know whether yaffs2 would erase
this block immediately after it writes the header in block C, or whether it
waits till a garbage collection pass). Either way, the data chunks and
object header are not copied because they're inactive. nDataChunks for the
file goes to 0.
  Garbage collect block C.
  Power fail. 

Does the deleting object header in block C get copied during the block C
garbage collection? If not, a zero length file will get resurrected after
the reboot because of the left over object header in block A. But if I
understand the algorithm outlined in your reply, the object header in block
C will not be copied because there are no unerased data chunks. 

In other words, I don't understand how the copying decision can be properly
made when only the data chunks and the most recent object header are tracked
while older, inactive, object headers (potentially many) are not.