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 embod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nikita Danilov wrote:
[...]
> It seems to me that in the domains where proposed designs are
> applicable, symlinks already provide viable solution.
It's a little late in the game for me to jump in, but can someone else
comment on this? Is this a "via
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 pow
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
t;
To: "Jonathan Briggs" <[EMAIL PROTECTED]>
Cc: "Hans Reiser" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"Alexander G. M. Smith" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
; <[EMAIL PROTECTED]>; "Nate Diller"
<[EMAIL PROTE
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
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 fe
On Thu, 2 Jun 2005 13:11:05 +0400, Nikita Danilov <[EMAIL PROTECTED]> said:
> 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 ne
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 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
>
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
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 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 beco
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 beli
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
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/
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 g
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
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 logi
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 j
Alexander G. M. Smith writes:
> 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
>
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
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
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
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
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, 1
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/
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
name: /tmp/A/B/file1
name: /tmp/A/B/C/file1
Object 1002:
name: /tmp
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
Ni
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..
Ho
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 t
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 del
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
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
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
leng
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
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 direc
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 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 solv
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
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 *
[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
42 matches
Mail list logo
