[Yaffs] problem with object (file) creation

[Charles Manning]

A quick update:

OK, I've worked through the reasoning as to what is going on. It is as=20
Michael says, YAFFS is forgetting about objects with cached inodes and th=
is=20
causes things to get out of whack.

I've been over to the linux-fsdevel folks and have received some advice.

One of the possible solutions involves the use of ilookup(). I am loath t=
o=20
use this as it is not available in older kernels (eg.2.4.18).  I am acute=
ly=20
aware that many embedded application use older kernels and it is unrealis=
tic=20
to say "just upgrade".

The solution I'm working on (ready in the next few days) does not use=20
ilookup(), but rather extends the code in yaffs_delete_inode.

In the meantime, if you're being help up by things, try the patchlette th=
at=20
Michael gives.


-- Charles=20

On Monday 11 October 2004 07:26, Charles Manning wrote:
> Michael
>
> Thank you very much for this. I too have struggled to sometimes get my =
head
> around the vfs and how it works and the input from various people has b=
eem
> very useful.
>
> I will be investigating this ASAP.
>
> Can you tell me what version of Linux you're using here? Some of these
> things might be version specific.
>
> Thanx
>
> -- CHarles
>
> On Saturday 09 October 2004 00:54, Michael Fischer wrote:
> > Hello everyone,
> > i am new to the list as well as to the linux vfs/fs stuff and i am
> > looking for any help/comments on the following:
> > In some cases when copying a big number of files i got complains from=
 the
> > cp command that a newly created file was a directory thus not beeing =
able
> > to write data into it. The following steps would reproduce the behavi=
or:
> > - delete a directory with many files and subdirs recursively.
> > - have some process which still has a reference to the dir or some fi=
le
> > open (e.g. cd /test; rm -rf /test)
> > - move or copy back the deleted dir-tree from some backup location.
> >
> > Debuging it further i found that the yaffs layer deletes objects whic=
h
> > due to references still exist in the inode cache of the vfs layer.
> > Looking into the code i found that yaffs_fs.c/yaffs_mknod =3D>
> > __yaffs_mknod =3D> yaffs_FindNiceObjectBucket returns the object id .
> > Depending on
> > YAFFS_NOBJECT_BUCKETS you probably get an id of a recently deleted
> > object. When afterwards calling yaffs_get_inode(iget4) you get an
> > possibly allready existing inode (inode reference count > 1). This in=
ode
> > doesnt get initialized so attributes like directory are still valid a=
nd
> > cause the described behavior.
> >
> > so a small patch (read: fast dirty hack) of yaffs_mknod (see below) d=
oes
> > solve the problem in my case:
> >
> > doitagain:
> > 	obj =3D __yaffs_mknod ( parent, dentry, mode, rdev);
> > 	if(obj)
> > 	{
> > 		inode =3D yaffs_get_inode(dir->i_sb, mode, rdev, obj);
> > 		T(YAFFS_TRACE_OS,(KERN_DEBUG"yaffs_mknod created object %d count =3D
> > %d\n",obj->objectId,atomic_read(&inode->i_count)));
> > 		if (atomic_read(&inode->i_count) > 1) {
> > 			iput(inode);
> > 			yaffs_DeleteFile(obj);
> > 			goto doitagain;
> > 		}
> > 		d_instantiate(dentry, inode);
> > 		error =3D 0;
> > 	}
> > 	else
> > 	{
> >
> > ok, as mentioned before i am new to all this therefore i am of cause
> > unsure if i havnt overseen something or this is fixed in later versio=
ns
> > or how a clean patch could look like.
> >
> > Thanks a lot for any comments and best regards,
> > Michael
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > yaffs mailing list
> > yaffs@stoneboat.aleph1.co.uk
> > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
> _______________________________________________
> yaffs mailing list
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs