Many thanks for the inputs. That is extremely helpful.

Regards,
Sandeep

On Mon, Nov 22, 2010 at 8:30 PM, Charles Manning <manningc2@actrix.gen.nz>wrote:

>
> On Tuesday 23 November 2010 14:30:08 sandeep dhoot wrote:
> > Thanks Charles for replying.
>
> Sundeep
>
> Please don't top-post on emails, it makes the thread hard to read.
>
> > 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.
>
> That assumes the kernel interface does not change
> >
> > Also as you mention, how good addition will caching object headers would
> > be? I would be interested in implementing it in my project.
>
> The headers could be cached with a policy such as this:
> * When a file is created do not immediately write. Just cache the header.
> * If the setattr is done, then do not immediately write. Just cache the
> header.
>
> So when do we actually write?
>  1) Get the background thread to flush the cached objects.
> 2)  Before the first data chunk is written ensure that the object header is
> written.
>
>
> > 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?
>
>
> Yes that is something  I  have considered and would be a valuable.
> Depending
> on usage scenarios there can be many small files. Being able to use the
> rest
> of the header for holding data means that files smaller than approx 1.5k
> (eg.
> a lot of the small files in /etc)  would typically not need any extra
> storage.
>
> Bear in mind though that the spare space in object headers  is also used
> for
> xattrib. You would need to coexist with xattrib.
>
>
> >
> > 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
>
>
>