From: Hans Reiser <reiser@namesys.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: linux-kernel@vger.kernel.org,
Alexander Zarochentcev <zam@namesys.com>,
vs <vs@thebsh.namesys.com>, Edward Shishkin <edward@namesys.com>
Subject: Re: [PATCH - EXPERIMENTAL] files with forks in the VFS
Date: Tue, 07 Sep 2004 12:31:20 -0700 [thread overview]
Message-ID: <413E0C88.6020402@namesys.com> (raw)
In-Reply-To: <16700.60673.453455.255327@cse.unsw.edu.au>
Neil Brown wrote:
>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.
>
>
After the file compression plugin we should consider creating a
directory compression plugin for directories with lots of small files....
>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).
>
>
I don't understand the paragraph above. Can you say with fewer
indirections (e.g. define extra semantic)?
>NeilBrown
>
>
>
>
next prev parent reply other threads:[~2004-09-07 19:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-06 0:21 [PATCH - EXPERIMENTAL] files with forks in the VFS Neil Brown
2004-09-06 5:59 ` Hans Reiser
2004-09-06 23:04 ` Neil Brown
2004-09-07 19:31 ` Hans Reiser [this message]
2004-09-08 0:27 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=413E0C88.6020402@namesys.com \
--to=reiser@namesys.com \
--cc=edward@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=vs@thebsh.namesys.com \
--cc=zam@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.