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
>
>