[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.)