Re: Starting a grad project that may change kernel VFS. Early research Re: Starting a grad project that may change kernel VFS. Early research

[Jeff Shanab <jshanab@earthlink.net>]

Rik van Riel wrote:
> Jeff Shanab wrote:
>
>> Updates start at the file and only work upwards back to root. How does
>> the hardlink get traversed?
>
> A hard link is just a second directory entry linking to
> the same inode.  There are no back links from inodes to
> the directory entries that point to them and they are
> essentially indistinguishable from files that are not
> hardlinked.
>
> Hard links have been done like this in pretty much every
> Unix filesystem since the 1970's.
>
Right :-( I need a workaround but I am not sure how the sementics should be.

In my example where we have a directory structure like so, where file is
the same.

test/foo/bar/file
test/bar/foo/file

My example would result in the size showing up in each directory at the
bar/file and foo/file level
Then the two numbers are passed up to test and the test directory size
would be wrong.
There is no real way to handle this becasue the two files look the same
to the filesystem.

I can even remove the initial file without effecting the other. Is there
a refcount I can take advantage of in the inode?

Even then, I can't decide what the semantic is.

For example I could add a pie chart that changed with navigation into my
gui file manager. This system would make that practical.
How would I display this information usefully to the user. I suppose if
they navigate into either subdir they see the file size, but somehow
when they navigate up to the directory that holds subdirs that
indirectly contain both of them, only 1 can be counted.  The problem is
that the top level directory will not be able to see the inodes of the
individual files, it is lost in the aggregate.

Still thinking....