links to a non-directory file then I know that the
predicate '/foo/bar' is asserted of that file (and that file only).
Even if 'foo' and/or 'bar' is mysterious to me, I already know a good
deal about the intended meaning of this bit of the filesystem, and I
can use what I know to help me deduce
On 11/21/05, Hubert Chan [EMAIL PROTECTED] wrote:
[snip]
As a completely different side issue, I think that using random names
such as aardvark or zebra to refer to tuples is a bad idea (and I
know this isn't part of your proposal). If you use things that are real
words, people will get
On 11/19/05, Alexander G. M. Smith [EMAIL PROTECTED] wrote:
Leo Comerford wrote on Fri, 18 Nov 2005 03:42:50 +:
[^.*$]
Just a few points I thought of while reading through your text:
Genealogy is an extremely structured arrangement of data, most people won't be
doing something that
Due to a divorce, I am much delayed in responding to this thread. It is
not for lack of interest, it is rather that a proper response would take
much time and must wait until next week.
Thanks for patience,
Hans
children called father
and son. Pretty obvious. Similarly, if she comes across
/usr/bin
/usr/bin/alpha
/usr/bin/bravo
[etc. etc.]
, if she is familiar with Unix she will know that /usr/bin/ indicates
user binaries. Every (non-directory) file in /usr/bin/ isA '/usr/bin',
a user binary. (Also, common
On Sun, 20 Nov 2005 07:03:03 +, Leo Comerford [EMAIL PROTECTED] said:
On 11/19/05, Hubert Chan [EMAIL PROTECTED] wrote:
P.S. your relational model can easily be expressed using file-as-dir
(well, actually, just standard directories):
/(something)/father-son/aardvark/father is a symlink
On 11/19/05, Hubert Chan [EMAIL PROTECTED] wrote:
P.S. your relational model can easily be expressed using file-as-dir
(well, actually, just standard directories):
/(something)/father-son/aardvark/father is a symlink to
'/(whatever)/portrait/Mike')
/(something)/father-son/aardvark/son is a
criticise file-as-directory some more - far from exciting, but
apparently still necessary. Things should pick up in part three.)
(Just briefly skimmed through these overly long posts.)
But now let's try to express the father's/son's-photo relationships
between the /(whatever)/portrait photos
P.S. your relational model can easily be expressed using file-as-dir
(well, actually, just standard directories):
/(something)/father-son/aardvark/father is a symlink to
'/(whatever)/portrait/Mike')
/(something)/father-son/aardvark/son is a symlink to
'/(whatever)/portrait/Bob')
--
Hubert
Once again, I have to apologise for a stupidly long and stupidly late
reply. I've tried to make this thing a little more digestible by
chopping it into three chunks. In order to keep any replies together,
I suggest that people reply to the third part unless the reply is very
specific to one of the
(This long essay has been posted in three parts. In order to keep any
replies together, I suggest that people reply to the third part unless
the reply is very specific to one of the others. This is part two, in
which I criticise file-as-directory some more - far from exciting, but
apparently still
)/friend/Ed
and then you can use the rooted-digraph operators on the graph.) But
the subfile-metadata approach only provides us with one presentation
or the other unless we duplicate or rejig the data, or use a custom
persistent query.
In sum: file-as-a-directory gives us nothing, in terms of power
On 9/5/05, Alexander G. M. Smith [EMAIL PROTECTED] wrote:
michael chang wrote on Fri, 2 Sep 2005 11:57:20 -0400:
Could it end up being a user-space/high-level library? Manually
implementing this as it is will have sucky performance anyways. The
idea would be to discourage it's use unless
open the
file as a directory and look inside to see the attributes (date modified,
thumbnail, etc) for that file. In BeOS there's a separate API for that;
with files as directories, it could be elegantly avoided.
The one big difference is that your scheme somehow has split attribute keys.
The photo
Leo, did you see my paper on the website, that the future vision button
takes you to? I think it addresses topics relevant to your email.
Best,
Hans
On 9/2/05, Hubert Chan [EMAIL PROTECTED] wrote:
On Sun, 28 Aug 2005 16:33:37 +0100, Leo Comerford [EMAIL PROTECTED] said:
On 8/25/05, Hubert Chan [EMAIL PROTECTED] wrote:
On Wed, 24 Aug 2005 07:51:19 +0100, Leo Comerford
[EMAIL PROTECTED] said:
It's not so easy. You need to determine
On Sun, 28 Aug 2005 16:33:37 +0100, Leo Comerford [EMAIL PROTECTED] said:
On 8/25/05, Hubert Chan [EMAIL PROTECTED] wrote:
On Wed, 24 Aug 2005 07:51:19 +0100, Leo Comerford
[EMAIL PROTECTED] said:
[... lots of stuff snipped ...]
At other levels, of course, the differences assert
On 8/25/05, Hubert Chan [EMAIL PROTECTED] wrote:
On Wed, 24 Aug 2005 07:51:19 +0100, Leo Comerford [EMAIL PROTECTED] said:
[... lots of stuff snipped ...]
At other levels, of course, the differences assert themselves. For one
thing, the normal Unix filesystem API doesn't have calls to,
On Wed, 24 Aug 2005 07:51:19 +0100, Leo Comerford [EMAIL PROTECTED] said:
[... lots of stuff snipped ...]
At other levels, of course, the differences assert themselves. For one
thing, the normal Unix filesystem API doesn't have calls to, for
instance, check the pathnames asserted of a given
'/bin' and '/bin/touch' are asserted of whichever
non-directory file is /bin/touch ). This is of course a horrible
crock. The right solution is to allow final name segments to be
blank. Any and all of the links from a directory to its non-directory
children (and any future opaque links
Nikita Danilov wrote:
Hans Reiser writes:
Nikita Danilov wrote:
But cycles are solvable in current file systems too: they simply do
not exist there.
Yes, but Nikita, cycles represent semantic functionality that has value
because being able to embody more expressions means
Hans Reiser writes:
Nikita Danilov wrote:
But cycles are solvable in current file systems too: they simply do
not exist there.
Yes, but Nikita, cycles represent semantic functionality that has value
because being able to embody more expressions means more power of
If you
: Hans Reiser [EMAIL PROTECTED]; [EMAIL PROTECTED];
Alexander G. M. Smith [EMAIL PROTECTED]; [EMAIL PROTECTED];
reiserfs-list@namesys.com; [EMAIL PROTECTED]; Nate Diller
[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 4:54 PM
Subject: Re: File as a directory - VFS Changes
Jonathan Briggs writes
Nikita Danilov wrote:
But cycles are solvable in current file systems too: they simply do
not exist there.
Yes, but Nikita, cycles represent semantic functionality that has value
because being able to embody more expressions means more power of
expression. If some way can be found to allow
Alexander G. M. Smith wrote:
Hans Reiser wrote on Tue, 31 May 2005 11:32:04 -0700:
What about if we have it that only the first name a directory is created
with counts towards its reference count, and that if the directory is
moved if it is moved from its first name, the new name becomes the
Hans Reiser writes:
What about if we have it that only the first name a directory is created
with counts towards its reference count, and that if the directory is
moved if it is moved from its first name, the new name becomes the one
that counts towards the reference count? A bit of a
Alexander G. M. Smith writes:
[...]
The typical worst case operation will be deleting a link to your photo
from a directory you decided didn't classify it properly. The photo may
be in several directories, such as Cottage, Aunt and Bottles if it is
a picture of a champaign bottle you
Jonathan Briggs writes:
On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote:
[snip]
Frankly speaking, I suspect that name-as-attribute is going to limit
usability of file system significantly.
Note, that in the real world, only names from quite limited class are
attributes
Or parentdirectory=thisdirectory. This make the virtual
folder stuff work as EXTENSION to standard file/directory relationship
rather than work as RELPLACEMENT.
Personal experience says that user dont digest any change to UNIX
filesystem mode. Anything extra is OK but replacements are BAD. Think of it
you
On Thu, 2005-06-02 at 14:38 +0400, Nikita Danilov wrote:
Jonathan Briggs writes:
On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote:
[snip]
Frankly speaking, I suspect that name-as-attribute is going to limit
usability of file system significantly.
Usability as in features?
Jonathan Briggs writes:
On Thu, 2005-06-02 at 14:38 +0400, Nikita Danilov wrote:
Jonathan Briggs writes:
On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote:
[snip]
Frankly speaking, I suspect that name-as-attribute is going to limit
usability of file system
Jonathan Briggs writes:
On Wed, 2005-06-01 at 02:36 +0400, Nikita Danilov wrote:
[...]
One problem with the above is that directory structure is inconsistent
with lists of names associated with objects. For example, file1 is a
child of /tmp/A/B/C/A, but Object 1001 doesn't list
Nikita Danilov writes:
[...]
Yes. :-) It is radical, and the idea is taken from databases. I
thought that seemed to be the direction Reiser filesystems were moving.
In this scheme a name is just another bit of metadata and not
first-class important information. The
On Wed, 2005-06-01 at 14:43 +0400, Nikita Danilov wrote:
Nikita Danilov writes:
[...]
Yes. :-) It is radical, and the idea is taken from databases. I
thought that seemed to be the direction Reiser filesystems were moving.
In this scheme a name is just another bit
Jonathan Briggs writes:
On Wed, 2005-06-01 at 14:43 +0400, Nikita Danilov wrote:
Nikita Danilov writes:
[...]
That latter bit, about making them persistent, is where the trouble
begins: once queries acquire identity and a place in the file system
name-space, they logically
. Same for
keyword queries, ownership queries, or whatever.
In the traditional directory system, a file doesn't have an official
name, just links to it from directory entries. Perhaps if you think of
the proposed name meta-data as a preferred name the idea would work
better for you?
--
Jonathan
objects are reachable. These paths _are_ names as far as
user is concerned (after all names exist to reach objects), but they are
not in the name-as-attribute model.
In the traditional directory system, a file doesn't have an official
name, just links to it from directory entries. Perhaps
On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote:
[snip]
Frankly speaking, I suspect that name-as-attribute is going to limit
usability of file system significantly.
Note, that in the real world, only names from quite limited class are
attributes of objects, viz. /proper names/ like
Hans Reiser wrote on Tue, 31 May 2005 11:32:04 -0700:
What about if we have it that only the first name a directory is created
with counts towards its reference count, and that if the directory is
moved if it is moved from its first name, the new name becomes the one
that counts towards the
Nikita Danilov wrote on Wed, 1 Jun 2005 14:58:47 +0400:
For example: mv /d0 /d1
To check that this doesn't introduce a cycle one has to load each child
of /d0 (which may be millions) and recursively check that from none of
them /d1 is reachable. This has to be done on each rename. I believe
Alexander G. M. Smith writes:
Nikita Danilov wrote on Mon, 30 May 2005 15:00:52 +0400:
Nothing in VFS prevents files from supporting both read(2) and
readdir(3). The problem is with link(2): VFS assumes that directories
form _tree_, that is, every directory has well-defined parent.
Nikita Danilov wrote:
Alexander G. M. Smith writes:
Nikita Danilov wrote on Mon, 30 May 2005 15:00:52 +0400:
Nothing in VFS prevents files from supporting both read(2) and
readdir(3). The problem is with link(2): VFS assumes that directories
form _tree_, that is, every directory has
Hello Hans,
Hans Reiser writes:
Nikita Danilov wrote:
Alexander G. M. Smith writes:
Nikita Danilov wrote on Mon, 30 May 2005 15:00:52 +0400:
Nothing in VFS prevents files from supporting both read(2) and
readdir(3). The problem is with link(2): VFS assumes that directories
On Tue, 31 May 2005 08:04:42 PDT, Hans Reiser said:
Cycle may consists of more graph nodes than fits into memory.
There are pathname length restrictions already in the kernel that should
prevent that, yes?
The problem is that although a *single* pathname can't be longer than some
length,
On Mon, 2005-05-30 at 01:19 -0700, Hans Reiser wrote:
[EMAIL PROTECTED] wrote:
On Fri, 27 May 2005 23:56:35 CDT, David Masover said:
Hans, comment please? Is this approaching v5 / v6 / Future Vision? It
does seem more than a little clunky when applied to v4...
Well, if you
On Tue, 2005-05-31 at 12:30 -0400, [EMAIL PROTECTED] wrote:
On Tue, 31 May 2005 08:04:42 PDT, Hans Reiser said:
Cycle may consists of more graph nodes than fits into memory.
There are pathname length restrictions already in the kernel that should
prevent that, yes?
The problem is
What happens when you unlink the True Name?
Hans
Jonathan Briggs wrote:
You can avoid cycles by redefining the problem.
Every file or data object has one single True Name which is their
inode or OID. Each data object then has one or more names as
properties. Names are either single strings
Jonathan Briggs wrote:
Why innovate in the filesystem though, when it would work just as well
or better in the VFS layer?
Why don't we just have one filesystem, think of the advantages.
;-)
I don't try to get other people to follow my lead anymore, I just ship
code that works. Putting it
Either that isn't allowed, or it immediately vanishes from all
directories.
If deleting by OID isn't allowed, then every name property must be
removed in order to delete the file.
Personally, I would allow deleting the OID. It would be a convenient
way to be sure every instance of a file was
Jonathan Briggs writes:
On Tue, 2005-05-31 at 12:30 -0400, [EMAIL PROTECTED] wrote:
On Tue, 31 May 2005 08:04:42 PDT, Hans Reiser said:
Cycle may consists of more graph nodes than fits into memory.
There are pathname length restrictions already in the kernel that should
Well,. if you allow multiple true names, then you start to resemble
something I suggested a few years ago, in which I outlined a taxonomy of
links, and suggested that some links would count towards the reference
count and some would not.
Of course, that does nothing for the cycle problem..
What about if we have it that only the first name a directory is created
with counts towards its reference count, and that if the directory is
moved if it is moved from its first name, the new name becomes the one
that counts towards the reference count? A bit of a hack, but would work.
Hans
On Tue, 2005-05-31 at 15:01 -0600, Jonathan Briggs wrote:
I should create an example.
Wherever I used True Name previously, use OID instead. True Name was
simply another term for a unique object identifier.
Three files with OIDs of 1001, 1002, and 1003.
Object 1001:
name: /tmp/A/file1
Jonathan Briggs writes:
On Tue, 2005-05-31 at 15:01 -0600, Jonathan Briggs wrote:
I should create an example.
Wherever I used True Name previously, use OID instead. True Name was
simply another term for a unique object identifier.
Three files with OIDs of 1001, 1002, and
On Wed, 2005-06-01 at 02:36 +0400, Nikita Danilov wrote:
Jonathan Briggs writes:
On Tue, 2005-05-31 at 15:01 -0600, Jonathan Briggs wrote:
I should create an example.
Wherever I used True Name previously, use OID instead. True Name was
simply another term for a unique object
Nikita Danilov wrote on Tue, 31 May 2005 13:34:55 +0400:
Cycle may consists of more graph nodes than fits into memory. Cycle
detection is crucial for rename semantics, and if
cycle-just-about-to-be-formed doesn't fit into memory it's not clear how
to detect it, because tree has to be locked
[EMAIL PROTECTED] wrote:
On Fri, 27 May 2005 23:56:35 CDT, David Masover said:
Hans, comment please? Is this approaching v5 / v6 / Future Vision? It
does seem more than a little clunky when applied to v4...
Well, if you read our whitepaper, we consider relational algebra to be a
inodes would
be fake ones, geneated as needed to represent the old style view of the
file / directory / attribute thing (such as the parent symbolic links).
But what would I (Hans likely has other views) like to see in a new VFS
to support files / directories / attributes all being the same kind
representing
the objects, containing a specially named file for the raw data, mixed in
with child items and symbolic links to parent objects. Some inodes would
be fake ones, geneated as needed to represent the old style view of the
file / directory / attribute thing (such as the parent symbolic links
Nikita Danilov wrote on Mon, 30 May 2005 15:00:52 +0400:
Nothing in VFS prevents files from supporting both read(2) and
readdir(3). The problem is with link(2): VFS assumes that directories
form _tree_, that is, every directory has well-defined parent.
At least that's one problem that's
for the raw data, mixed in
with child items and symbolic links to parent objects. Some inodes would
be fake ones, geneated as needed to represent the old style view of the
file / directory / attribute thing (such as the parent symbolic links).
But what would I (Hans likely has other views) like
On Fri, 27 May 2005 23:56:35 CDT, David Masover said:
Hans, comment please? Is this approaching v5 / v6 / Future Vision? It
does seem more than a little clunky when applied to v4...
I'm not Hans, but I *will* ask How much of this is *rationally* doable
without some help from the VFS?. At
listings. There may
be a duality between relation directories and a file system with
indexed attributes, like BeOS's BFS or a true file-is-a-directory
system.
One system has a relations directory stuffed with property values of
a similar kind (such as short text descriptions for photos
with
indexed attributes, like BeOS's BFS or a true file-is-a-directory
system.
One system has a relations directory stuffed with property values of
a similar kind (such as short text descriptions for photos). The
directory implies the contents type (short text description), while
the items
And then there are ReiserFS plugins, which might give you a magic
directory that when read for data, yields the concatenation of its
children's data contents.
Better, you could have a little custom filesystem which can take the
/(something)/concatenation/zebra: subgraph as its device and
the
relation-directory its file type: it's the pathname
'/(something)/description/(whatever)' that tells us to interpret the
relation-directory as a link between a description and the file it
describes. Actually aardvark: already has a file type of
relation-directory - the link from /(something)/description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander G. M. Smith wrote:
[...]
On the other hand, garbage collection will be a significant hurdle,
for two reasons. One is cycles. [...] The other is more
sophisticated needs for automatic deletion.
Neither are impossible, we just have to
David Masover wrote on Tue, 17 May 2005 17:51:20 -0500:
How much of a price do I pay? And could that price be avioded by only
enabling those features for directories where I want them? Could that
be done easily in Reiser4?
Interesting point. A lot of those features require that file system
language) give a directory an opaque name. An opaque
directory name would assert a predicate of the directory file itself
and not its descendants, whereas a normal directory name asserts a
predicate of the directory's non-directory descendants and not the
directory itself. So, for example, we might
Leo Comerford wrote on Mon, 16 May 2005 13:32:19 +0100:
Probably the biggest barrier is the fact that it's nigh-impossible to
take a specific (non-directory) file and find its pathnames! We need
the ability to do this for any file, directory or otherwise, and for
all types of pathnames applied
On Tue, May 10, 2005 at 04:38:48PM +0100, Peter Foldiak wrote:
On Tue, 2005-05-10 at 16:14, [EMAIL PROTECTED] wrote:
On Tue, 10 May 2005 10:39:23 BST, Peter Foldiak said:
Back in November 2004, I suggested on the linux-kernel and reiserfs
lists that the Reiser4 architecture could allow us
into the structure of
chapter 1, section A, you need to launch the editing application.
What a pity.
Why is it, that we have this hard and fast dichotomy between directory
structure and file structure? Why is it that file system exploring
utilities need to stop in their tracks when they hit things called
has a number of sub-chapters. However, that
is as far as you can go. To dig any further into the structure of
chapter 1, section A, you need to launch the editing application.
What a pity.
Why is it, that we have this hard and fast dichotomy between directory
structure and file structure? Why
On Tue, 10 May 2005 10:39:23 BST, Peter Foldiak said:
Back in November 2004, I suggested on the linux-kernel and reiserfs
lists that the Reiser4 architecture could allow us to abolish the
unnatural naming distinction between directories/files/parts-of-file
(i.e. to unify naming
On Tue, 2005-05-10 at 16:14, [EMAIL PROTECTED] wrote:
On Tue, 10 May 2005 10:39:23 BST, Peter Foldiak said:
Back in November 2004, I suggested on the linux-kernel and reiserfs
lists that the Reiser4 architecture could allow us to abolish the
unnatural naming distinction between
Peter Foldiak wrote:
On Tue, 2005-05-10 at 15:53, Hans Reiser wrote:
I agree with the below in that sometimes you want to see a collection of
stuff as one file, and sometimes you want to see it as a tree, and that
file format browsers can be integrated into file system browsers to look
seamless
Peter Foldiak wrote:
On Tue, 2005-05-10 at 16:14, [EMAIL PROTECTED] wrote:
On Tue, 10 May 2005 10:39:23 BST, Peter Foldiak said:
Back in November 2004, I suggested on the linux-kernel and reiserfs
lists that the Reiser4 architecture could allow us to abolish the
unnatural naming
Sean McGrath wrote:
The thing that interests me most is the difference (if any) between
giving a stream of bytes an opaque name e.g. Chapter 1 of my
book.sxw versus giving a stream of bytes a query expression that can
also be considered an opaque name e.g.
/book/chapter[1]
What is an
Hans Reiser wrote:
Sean McGrath wrote:
The thing that interests me most is the difference (if any) between
giving a stream of bytes an opaque name e.g. Chapter 1 of my
book.sxw versus giving a stream of bytes a query expression that can
also be considered an opaque name e.g.
/book/chapter[1]
Sean McGrath wrote:
Hans Reiser wrote:
Sean McGrath wrote:
The thing that interests me most is the difference (if any) between
giving a stream of bytes an opaque name e.g. Chapter 1 of my
book.sxw versus giving a stream of bytes a query expression that can
also be considered an opaque
Hans Reiser wrote:
Sean McGrath wrote:
Hans Reiser wrote:
Sean McGrath wrote:
The thing that interests me most is the difference (if any) between
giving a stream of bytes an opaque name e.g. Chapter 1 of my
book.sxw versus giving a stream of bytes a query expression that can
also
Sean McGrath wrote:
What is an opaque name?
By opaque name I mean a name that is purely a label. A name that
cannot be interpreted as a query expression.
Isn't query just another name for name?
That is a major philosophical nugget :-)
I recommend Saul Kripke's Naming
David Masover wrote on Mon, 20 Dec 2004 23:31:53 -0600:
Would it work in a typical setup? My instinct is no.
Depends on how big the directory loop and attached files are (basically all
the descendants of the directory you're trying to delete). In most cases,
you don't have millions of
Alexander G. M. Smith [EMAIL PROTECTED] said:
Hans Reiser wrote on Mon, 20 Dec 2004 09:21:35 -0800:
Ok, go talk to the befs driver guy, and you'll find out he has already
done work on it.
I just did some work in making a test file system with hard links and
bidirectional references (files
Horst von Brand wrote:
Can you point me to any such literature? I'm just curious.
Look in every field of cs except filesystems and kernels.;-)
Right. Smart people are found elsewhere only.
There is a huge pile of innovations by the database field that
filesystems people do not
Hans Reiser wrote on Mon, 20 Dec 2004 09:21:35 -0800:
Ok, go talk to the befs driver guy, and you'll find out he has already
done work on it.
I just did some work in making a test file system with hard links and
bidirectional references (files know which directories (plural) they are in).
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander G. M. Smith wrote:
[...]
|Everthing stuff that works on the assumption that what they are working
|on fits in RAM (or can overflow into swap space in a pinch), [...]
|
|
| Admittedly my experiment was for a RAM disk. It can be extended to a
Hans Reiser [EMAIL PROTECTED] said:
David Masover wrote:
Hans Reiser wrote:
[...]
| My solution is to tell Nate Diller that there is extensive literature on
| it, that it isn't really the big problem it is made out to be, and leave
| it to him to go read the literature and code it up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
[...]
| My solution is to tell Nate Diller that there is extensive literature on
| it, that it isn't really the big problem it is made out to be, and leave
| it to him to go read the literature and code it up after he finishes the
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| David Masover wrote:
|
|
|
| Speaking of which, how much speed is lost by starting up a process?
|
| The idea of caching is that running
|
| cat *; cat *; cat *; cat *; cat *
|
| is probably slower than
|
| cat * baz; cat baz; cat
David Masover wrote:
Hans Reiser wrote:
| David Masover wrote:
|
|
|
| Speaking of which, how much speed is lost by starting up a process?
|
| The idea of caching is that running
|
| cat *; cat *; cat *; cat *; cat *
|
| is probably slower than
|
| cat * baz; cat baz; cat baz; cat baz; cat baz;
Peter Foldiak wrote:
On Thu, 2004-12-16 at 18:48, Hans Reiser wrote:
David Masover wrote:
Speaking of which, how much speed is lost by starting up a process?
The idea of caching is that running
cat *; cat *; cat *; cat *; cat *
is probably slower than
cat * baz; cat baz; cat baz; cat baz;
On Thu, 2004-12-16 at 18:48, Hans Reiser wrote:
David Masover wrote:
Speaking of which, how much speed is lost by starting up a process?
The idea of caching is that running
cat *; cat *; cat *; cat *; cat *
is probably slower than
cat * baz; cat baz; cat baz; cat baz; cat baz;
David Masover wrote:
Speaking of which, how much speed is lost by starting up a process?
The idea of caching is that running
cat *; cat *; cat *; cat *; cat *
is probably slower than
cat * baz; cat baz; cat baz; cat baz; cat baz; cat baz
Only for small files where the per file overhead of a read
.
|
| Right.
|
| Also, there should be an inverse. For instance, a file-as-directory
type
| object should have a contents object, usually a normal directory, but
| which could conceivably be any type of object, including a code-ish
| object which implements a filesystem. Accessing foo/ would be the same
could have sub-components.
Right.
Also, there should be an inverse. For instance, a file-as-directory type
object should have a contents object, usually a normal directory, but
which could conceivably be any type of object, including a code-ish
object which implements a filesystem. Accessing
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] said:
Horst von Brand wrote:
Peter Foldiak [EMAIL PROTECTED] said:
[...]
Perhaps a better way to think about this is that instead of talking
about directories and files, we just talk about objects.
Then
On Wed, Dec 15, 2004 at 08:57:27AM -0800, Hans Reiser wrote:
www.namesys.com/future_vision.html
404.
http://www.namesys.com/whitepaper.html
--
mjt
only spend the half
second when passwd is modified, instead of every time a user logs in.
|
|
| | The component objects themselves could be full objects, so they
| | themselves could have sub-components.
|
| Right.
|
| Also, there should be an inverse. For instance, a file-as-directory type
| object
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Foldiak wrote:
| On Wed, 2004-12-15 at 04:47, David Masover wrote:
|
|Peter Foldiak wrote:
|| Also, a pseudofile (e.g. dirname//structure ?) could be used to
|| specify how the files should be glued together. A simple question is,
|| for
1 - 100 of 163 matches
Mail list logo
