Hard links in JFFS

[Finn Hakansson <finn@xxxxxxx.com>]

I'm changing the subject header.

On Tue, 9 Jan 2001, David Woodhouse wrote:

> Sounds reasonable. But what about when you delete the file from the
> _original_ directory? Write out a node with deleted==1, nlinks > 0?

How about removing the deleted flag from the structs and use nlink
insted? When nlink becomes zero, the file could be deleted. I may
have overlooked something here...


> How about using your hard link entry for _all_ directory entries, rather
> than just the second and subsequent ones? Remove the name and parent
> information from the jffs_raw_inode and store them in entirely separate
> nodes to the actual data for the inode?

Good idea. I have thought about this but I didn't like to have more
than one data structure on-flash in order to keep the scanning of
the flash simple. That could be reconsidered though. There could
lurk a number of new issues in the scanning process that could
emerge. Different sizes of the jffs_raw_inode and jffs_raw_dirent
could lead to difficulties perhaps. Not sure.


> struct jffs_raw_dirent {
> 	__u32 magic;
> 	__u32 nodetype; /* == JFFS_DIRENT_v1 */

By adding something like this, it would be possible to make changes
to the filesystem's on-flash structures in the future. But is it
necessary with 32 bits?

> 	__u32 direntnum;
> 	__u32 version;

Does anyone have a better name for 'version' BTW? 'version' isn't
the best word IMO.


> 	__u32 ino;

Perhaps 'version' should swap places with 'ino'.

> 	__u32 pdirent;
> 	__u16 chksum;
> 	__u8 spare: 7;
> 	__u8 unlinked : 1;
> 	/*    rename field isn't needed. Just a new version does that */
> 	__u8 nsize;
> 	__u8 name[0];
> };


> It was already getting on my tits that we had to write out the name with
> every node we GC'd - I tried being clever about it and ended up with files
> with no names left on the flash at all :)

Correct. To be on the safe side, the names have to be rewritten
during garbage collection. Not so good. So this speaks for your
idea of introducing the raw_dirent structure.


> Perhaps we could split the ugid and permission information off too, but
> I don't think we'll gain too much from that.

The uid/gid information is associated with the (raw) inode and the
hard links (dirents) that refer to this inode should all have the
same permissions.


> We don't need to store nlink on the medium. We always have to scan the
> flash and hence can work it out at runtime.

Then we need the deleted flag I think.

/Finn


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com