[Yaffs] Rewind readdir when entries deleted

[Charles Manning]

I looked at Todd's suggestion.

Yes, there is a bit of a hole.

I don't think that returning names twice is a good idea. Instead I think 
something more along the lines of the yaffs direct directory search stuff is 
better. This is something that was done after Beat Morf raised issue with the 
slowness of the previous version.

Rather than counting down the directory list (as the current Linux stuff 
does),  this mechanism points to the next object to be returned in the 
directory. If files are deleted, then we don't miss stuff by counting. There 
is a callback to handle the interesting case where the next object to be 
returned is deleted.

I can take a look at fixing this, but I will need to set up my crash box 
first.

-- Charles


On Sunday 06 November 2005 10:37, Charles Manning wrote:
> On Saturday 05 November 2005 13:34, Todd Poynor wrote:
> > busybox rm -rf <dir>, bonnie++, and other applications that do not
> > rewinddir after each file removal, may fail to remove all files when
> > multiple readdir calls are needed due to the number of dentries.  The
> > file position passed into the subsequent readdir calls no longer
> > describes the list position of the "next" entry to be returned.
> >
> > The below solution causes a subsequent readdir to restart whenever a
> > file is deleted from that directory since the previous call.  In some
> > uses this will cause dentries to be returned twice, but it is a quick
> > solution for rm -rf.  If the inode version bumping introduced below
> > remains the sole situation in which a version would be bumped by yaffs,
> > it would be possible to compute the proper index to restart at.
> >
> > Other suggestions welcomed.  Note some shells introduce a rewinddir into
> > the rm -r code to avoid this problem.
>
> It might instead make sense to use the feature introduced in 1.19 to handle
> this a bit faster in yaffs direct. See
> http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_guts.c?r1=1.18&r2=
>1.19 This implements a fix for the problem
>
> I first encountered a problem like this when using YAFFS in WinCE. The
> problem was addressed by creating a list of returned objects and checking
> the list before returning it. This solution degrades with large directories
> and the above solution handles it.
>
> Perhaps it makes sense to propagate this solution into Linux space too.
>
> > Signed-off-by: Todd Poynor <tpoynor at mvista.com>
> >
> > Index: yaffs_fs.c
> > ===================================================================
> > RCS file: /home/aleph1/cvs/yaffs2/yaffs_fs.c,v
> > retrieving revision 1.33
> > diff -u -r1.33 yaffs_fs.c
> > --- yaffs_fs.c	27 Oct 2005 22:24:04 -0000	1.33
> > +++ yaffs_fs.c	5 Nov 2005 00:28:27 -0000
> > @@ -814,6 +814,15 @@
> >
> >  	curoffs = 1;
> >
> > +	/* If the directory has changed since the open or last call to
> > +	   readdir, rewind to after the 2 canned entries. */
> > +
> > +	if (f->f_version != inode->i_version) {
> > +		offset = 2;
> > +		f->f_pos = offset;
> > +		f->f_version = inode->i_version;
> > +	}
> > +
> >  	list_for_each(i, &obj->variant.directoryVariant.children) {
> >  		curoffs++;
> >  		if (curoffs >= offset) {
> > @@ -981,15 +990,15 @@
> >
> >  	retVal = yaffs_Unlink(yaffs_InodeToObject(dir), dentry->d_name.name);
> >
> > -	yaffs_GrossUnlock(dev);
> > -
> >  	if (retVal == YAFFS_OK) {
> >  		dentry->d_inode->i_nlink--;
> > +		dir->i_version++;
> > +		yaffs_GrossUnlock(dev);
> >  		mark_inode_dirty(dentry->d_inode);
> >  		return 0;
> > -	} else {
> > -		return -ENOTEMPTY;
> >  	}
> > +	yaffs_GrossUnlock(dev);
> > +	return -ENOTEMPTY;
> >  }
> >
> >  /*
> >
> > _______________________________________________
> > yaffs mailing list
> > yaffs at stoneboat.aleph1.co.uk
> > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
> _______________________________________________
> yaffs mailing list
> yaffs at stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs