Thanks Charles for replying.

Well that surely is a problem. But as I observe, when I create a file setattr is always getting called immediately after mknod. Is that supposed to be so? So can we call UpdateObjectHeader for mknod and not for setattr since creating a file is major operation and not setting attributes.

Also as you mention, how good addition will caching object headers would be? I would be interested in implementing it in my project. Any other viable enhancements to current behavior of yaffs that you can suggest? I even thought of having data bytes in the chunk that holds Object header, that would save a lot of storage space. Anything you want to comment on it?

Thanks a lot for your feedback.

Regards,
Sandeep

On Mon, Nov 22, 2010 at 6:55 PM, Charles Manning <manningc2@actrix.gen.nz> wrote:
On Tuesday 23 November 2010 13:06:13 sandeep dhoot wrote:
> Hi all,
>
> I am studying and characterizing yaffs2 as part of my grad project.
> Well I see that on creating a file 2 chunks get written one after other and
> when the second is written the first is invalidated. The first gets written
> due to call to UpdateObjectHeader from yaffs_MknodObject while the second
> is written due to call to UpdateObjectHeader from yaffs_setattr. So why do
> we write object header again to flash on setattr and not just call
> inode_setattr and return? Is there any specific reason for writing a chunk
> on setattr? This always wastes one chunk on file creation.

This is due to the way yaffs treats individual operations as atomic.

When yaffs creates a file, it has no way of knowing that this will be followed
by a setattr.

Consider what would happen if we did not write the header for mknod and the
setattr did not get called. We could end up with a sequence like this:

* create file [obj header write ignored]
* start writing data chunks to file.
* power failure.
On the next boot we'd end up with some data chunks with no object. That would
end up creating an object in lost+found.

There is a potential to cache these writes to an extent and save some of these
redundant object header writes. There are more valuable opportunities to be
chasing, but this might happen in time.

Charles