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
Hi Nikita;
The problems of files not fitting in the query of the smart folder is a
serious one. We had implemented this same thing for our semantic
filesystem.
For ex we create a MP3 file is a JPEG folder things it wont ever get
listed.
This will fundamentally change the way users see
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
On Wed, 2005-06-01 at 18:42 +0400, Nikita Danilov wrote:
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
Jonathan Briggs writes:
[...]
However, query directories (or smart folders) will have this namespace
problem in every case and there is no avoiding it. If the query is for
every file modified in the past day, the file path through the query
directory is not going to match any given
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 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
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
I think what Alex is suggesting below is reasonable and something
resembling it should be done, though I will not go into details on it
until we have some working code
Hans
Alexander G. M. Smith wrote:
[EMAIL PROTECTED] wrote on Sat, 28 May 2005 15:42:35 -0400:
I'm not Hans, but I
Alexander G. M. Smith writes:
[EMAIL PROTECTED] wrote on Sat, 28 May 2005 15:42:35 -0400:
I'm not Hans, but I *will* ask How much of this is *rationally* doable
without some help from the VFS?. At the very least, some of this stuff
will require the FS to tell the VFS to suspend its
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
[EMAIL PROTECTED] wrote on Sat, 28 May 2005 15:42:35 -0400:
I'm not Hans, but I *will* ask How much of this is *rationally* doable
without some help from the VFS?. At the very least, some of this stuff
will require the FS to tell the VFS to suspend its disbelief (for starters,
doing this
38 matches
Mail list logo
