[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS compression and hard links.

On Tue, 9 Jan 2001, Finn Hakansson wrote:

> I have thought of a solution to hard links in JFFS but I never had
> the time to add it and I also didn't know if this was the way to
> go. Right now I don't remember all of the issues either.
> First of all we have the 'nlink' member in struct jffs_raw_inode
> and in struct jffs_file that we haven't used so far. nlink could be
> used to keep track of how many links there are to one file.
> (Isn't that the whole idea with nlink in the first place?)
> A hard link could be created by (somehow) storing the inode number
> of the original file. (One could use the same strategy for storing
> this data that is used for storing devices' kdev_t struct.) A
> problem is that the original file's nlink member has to be updated
> which requires an extra write to the flash device. (Similar stuff
> like that is done when renaming a file to an already existing file
> name.)
> Upon deletion of a file, nlink should be decreased by one and if
> the nlink member of that file reaches 0 we can safely remove that
> file. (Just removing the file is probably the normal situation.)
> Also, deleting a hard linked file, should cause the file to
> disapear from the directory listing. Yeah, this is just the normal
> behavior of hard links but it has to be handled by JFFS.

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 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?

struct jffs_raw_dirent {
	__u32 magic;
	__u32 nodetype; /* == JFFS_DIRENT_v1 */
	__u32 direntnum;
	__u32 version;
	__u32 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 :)

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

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.


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