> > 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.
(text/plain)