[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS compression and hard links.
On Tue, 9 Jan 2001, David Woodhouse wrote:
> email@example.com said:
> > Heh I don't even know hard-links semantics in normal filesystems so
> > I'll let that pass :)
> Simple - the same inode is linked to by two or more directories.
> Doing that in JFFS is going to be, erm, interesting. It basically means
> you can't have 'name' or 'parent' information in the inode itself - you
> have to have directory structure represented another way.
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
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.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org