[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More GC fun.
On Thu, 17 Aug 2000, David Woodhouse wrote:
> jffs_write_node(), through jffs_possibly_delete_file(), appears to remove a
> file from the in-core tree as soon as it's deleted, even if there are still
> nodes on the flash which belong to it.
You mean jffs_possibly_delete_file is called from jffs_insert_node, right?
Yes, the deleted file is removed from the internal file tree. The areas on the
flash corresponding to the deleted file's nodes, represented with jffs_fm
structs, are kept to be able to track during garbage collection.
> When jffs_garbage_collect_now() later tries to pass over those nodes, it
> isn't happy, because it can't find the file to which they belong.
At least for the moment, I don't see why the nodes of a _deleted_ file are
needed during a garbage collection.
> I think we want to keep the file in the tree until the last node has been
> removed by GC. That way, we know which inode numbers can safely be re-used
> after c->next_ino wraps. (/me spots a new can-o-worms in that one ;)
I dismissed the thoughts of c->next_ino should ever wrap in a real situation. I
reasoned that the flash device itself would have broken long before such a wrap.
I might have misjudged this issue of course.
(During each scan of a flash partition, the next_ino is recalculated and
sometimes some numbers are reused that way.)