Hi YAFFSers

The purpose of shrink header marking is to track when files are truncated.

We have to be careful with the handling of shrink headers because if we delete 
them arbitrarily during garbage collection we risk allowing old data to come 
back in the place of file holes.

Consider the case of the following:
1. Create file. Writes object header
2. Write 5MB of data
3. Trucate file to 1MB: write object header (flen=1MB)
4 Seek to 2MB
5. Write 1MB of data.
6. Close file: write object header (flen = 3MB).

So now we have a 3MB file with data from 0 to 1MB and from 2MB to 3MB a hole 
in the middle. According to POSIX, that hole should read as zeros.

At this stage (we're assuming no gc has happened for simplicity of 
explanation), only the object header from step 6 is current and the others 
are obsolete. However, at this stage we cannot remove the shrink header 
written in step 3 or we'll forget about the truncation and the hole will fill 
with historic data.

This, at present, the garbage collection process is constrained so that blocks 
with shrink headers are only collected once all previous garbage has been 
collected. This can make for sub-optimal garbage collection which is the 
major reason for yaffs2 slowdowns.

Now I do have some ideas about faster shrink header handling, but there is 
another way of approaching this. We could create a mount option that ignores 
the shrink header check. This would allow for faster gc for those that either 
don't care about the POSIX-pure hole handling  (ie. holes might sometimes 
have undefined data) or use yaffs in systems that do not write files with 
holes in them.

Thoughts??

-- Charles