Re: Implementing Meta File information in Linux

Kristian Koehntopp (kris@koehntopp.de)
Wed, 2 Sep 1998 12:41:02 +0200


In netuse.lists.linux-kernel you write:
>I really fail to see one single advantage of multiple forks over
>directories. Not one.

This discussion comes up ever now and then in various
Unix-related USENET newsgroups. Terry Lambert is usually very
fond of the idea of forked files and brings up a lot of issues
that could be handled better by forked files. All of them but
one can be done as well or better with directories.

The one thing that directories cannot do better currently is
crash-stability/integrity. In a forked file done properly
according to Terry there is a mechanism that ties a fork to the
file containing it, so that the fork can be retied to that file
when the file system explodes. On the other hand it is likely
for files to show up in /lost+found with not enough information
available to even manually shove them back into their rightful
place.

This is an important issue, if you are building a filesystem
that is supposed to be stable in a textbook. In practice (I have
been a Nextstep user and developer for several years) it tends
to be a non-issue, just as delayed metadata updates are.
Certainly such a tie-mechanism would be nice to have
(dcache-like datastructure on disk? I next to nothing about
dcache...), but it is not critical.

The rest can be implemented in userland, just like Nextstep did.

Kristian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html