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

Re: Hard links in JFFS



On Wed, 10 Jan 2001, Finn Hakansson wrote:

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

One of them is redundant, agreed. But as mentioned below, you can keep
nlink in core, and by removing it from the nodes you don't need to write
anything to the inode when removing a directory entry.

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

We're also likely to want 'snapshot' nodes at some point in the not too
distant future. We could work round it all by keeping 'snapshot' and
'dirent' information as data inside a special inode, but I think it's
cleaner just to have different types of nodes.

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

Probably not. A different 32-bit magic would probably suffice.

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

I used 'version' to be consistent with the usage in the data nodes. It
confused me to start with, but I'm used to it now :)

> > 	__u32 ino;
>
> Perhaps 'version' should swap places with 'ino'.

Quite possibly. I just meant to illustrate the idea.

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

Well, I tried keeping a count of the number of (currently valid) names
present on the flash for each file, and writing the name out with GC only
when that count would have been reduced below 2 by the deletion of the
node being GC'd. But as I said, that didn't work. So I gave up and just
wrote it out every time.

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

I meant into a third type of node, so we don't write out ugid and perms
with every data node written. But I don't think it's worth it.

-- 
dwmw2



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