... inode.¹

The lack of distinction between directory entries and inodes means that the original JFFS cannot support hard links.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... node.²

Actually, if the node was obsoleted the reference to it would already have been removed from the linked list of nodes which JFFS stores. The head pointer only ever points to a valid node. This is an implementation detail, though. The point is that valid nodes are obsoleted, and obsoleted nodes are ignored -- either explicitly or implicitly.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... collected.³

An attempt was made to limit this growth by counting the number of valid nodes containing the current name of each file, and writing out a name with a new node only if there were fewer than two such nodes. This attempt was abandoned because the initial implementation was buggy and could lead to a situation with no valid copies of a file name, and because it would not have solved the problem properly even if the hard-to-find bugs were located and fixed.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... source.⁴

This duplication is scheduled to be fixed fairly early during the 2.5 development series.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... well-distributed.⁵

The size of the hash table is variable at compile time, and in all cases is currently only one entry - which effectively means that all inode cache structures are stored in a single linked list. If and when this becomes noticeably suboptimal, it will be simple to correct.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.