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