> > The way I designed this to work is that when the file gets unlinked (last
> > link) it gets placed in the "unlinked directory" which is not in the
> > directory tree. It should only be marked for deletion if the file is
> > already closed (or when the file handle is closed).
>
> Is this a necessity? What will/should happen if we just remove the file
> entry from the directory?
> i.e: yaffs_unlink()     -> play with the hardlink iplementation
> 			 + yaffs_RemoveObjectFromDirectory()
>
>      yaffs_delete_inode -> yaffs_DeleteWorker()
>                          + yaffs_FreeTnode()
>                          + yaffs_FreeObject()
>
> ?????

The trickiness is that that the *nix file model knows about links and inodes 
as distinct beings, but internally yaffs knows only about Objects. This makes 
some of these issues a bit tricky, but not much.  THis is purposefully done 
so that we don't have to keep both a liink and a file Object for most files - 
thus saving some NAND. We can't delete the file's Object without deleting the 
file. So, the way I handle this is to move unlinked files into a special 
directory. When the file becomes free, it is marked for deletion.

It concerns me that you are seeing significant slowdowns associated with 
running background deletion. Some other (WInCE) people have noted this too.
Essentially the same effort is done in foreground deletion as in background 
deletion. The difference is that with foreground deletion, all the detion 
work is done immediately (ie. the unlink takes a long time). With background 
deletion the actual deletion work is spread over the next n write operations. 
Thus,  the unlink is fast, but subsequent writes are slower (until the 
background deletion is finished). There are some things I can do here:
* Do less background deletions in every write, thus spreading the deletion 
out more.
* Doing "soft deletion". Let me explain: Already the garbage collection is 
modified such that when it gathers a block it checks if the page to be copied 
is in a deleted file. If it is in a deleted file, then it does not get 
copied, but is instead unhooked out of the file's tree. This saves copies and 
saves deleting the page being discarded. However, currently 
this nice scenario is unlikely to actually happen because the blocks are not 
likely to get selected for garbage collection. (because their in-use counts 
are artificailly high since deleted files are still counted).  This can be 
remedied by "soft deletion" where the block's in-use count is reduced thus 
making it more likely to be selected for garbage collection. This should make 
for a scheme that is more efficient (faster) than the current deletion scheme 
since deletion of data chunks will not require NAND programming cycles to 
delete the data chunks.

[If you got lost in that last lot, don't feel too bad].

In short, I would rather improve background deletion to make it faster (as 
outlined above) than have people suffer foreground deletion. Still, I guess 
foreground deletion should really work if it is an option.

I will try to get something sorted this week. It will also contain some other 
work in progress (changes to facilitate moveing to YAFFS2).

-- CHarles



---------------------------------------------------------------------------------------
This mailing list is hosted by Toby Churchill open software (www.toby-churchill.org).
If mailing list membership is no longer wanted you can remove yourself from the list by 
sending an email to yaffs-request@toby-churchill.org with the text "unsubscribe" 
(without the quotes) as the subject.