From: Neil Brown <neilb@cse.unsw.edu.au>
To: Hans Reiser <reiser@namesys.com>
Date: Tue, 7 Sep 2004 09:04:33 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16700.60673.453455.255327@cse.unsw.edu.au>
Cc: linux-kernel@vger.kernel.org, Alexander Zarochentcev <zam@namesys.com>,
       vs <vs@thebsh.namesys.com>
Subject: Re: [PATCH - EXPERIMENTAL] files with forks in the VFS
In-Reply-To: message from Hans Reiser on Sunday September 5
References: <16699.44411.361938.856856@cse.unsw.edu.au>
	<413BFCB5.4010608@namesys.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2050
Lines: 47

On Sunday September 5, reiser@namesys.com wrote:
> Neil Brown wrote:
> 
> >As a followup to the multi-branching threads about reiser4, I would
> >like to present this patch for discussion and exploration.
> >It implements files with fork (which are quite different to files that
> >provide different views via a subdirectory structure).
> >  
> >
> How are they different?  Having a distinguished file is consistent with 
> the reiser4 approach.
> 

They are different at least in my perception.  It is possible that a
common abstraction and a common implementation could support them
both, though I am slightly sceptical.

On the one hand, you have a name space within a file which provides
access to information that is not part of that file but is only
loosely associated with it:  an icon for a desktop app, documentation
for a program, a collection of fonts that a document uses.

On the other hand, you have a name space within a file which provides
alternate views onto information that already exists within that
file:  "unzip" which presents the file uncompressed, "tar" which
explodes a tar achieve, "tag" which shows tags in a multi-media
file. "elf" which exposes sections of an ELF executable.

In the first case, the subordinate files should clearly be writable,
and should be backed up along with the main file.
In the second case, it is not clear that subordinate files should or
could be writable in general (though there may well be specific
cases), and the data does not need to be backed up.

In the first case, the extra semantic only applies to files, not
directories (allowing a directory to have extra streams is nothing
new).
In the second case, the extra semantic should apply to directories as
well (as there may we be different views you might want on a
directory). 

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/