Hans Reiser wrote:
David Masover wrote:
That's why we're trying to find something that people won't actually
touch, especially since if we design it right, this will be the last
delimiter introduced at the fs/vfs level.
Uh, no, there needs to be about a dozen or so more.
Where?
From what
David Masover <[EMAIL PROTECTED]> wrote:
> Hans Reiser wrote:
> > Horst von Brand wrote:
> >>Hans Reiser <[EMAIL PROTECTED]> wrote:
> >>>Stefan Smietanowski wrote:
[...]
> > Better to spend one's mind looking for bugs instead of this issue.
>
> .if bugs were seen as such a big deal.
> I
Neil Brown wrote:
>On Tuesday July 12, [EMAIL PROTECTED] wrote:
>
>
>>Neil Brown wrote:
>>
>>
>>
>>>Maybe it is worth repeating Al Viro's suggestion at this point. I
>>>don't have a reference but the idea was basically that if you open
>>>"/foo" and get filedescriptor N, then
>>> /proc/sel
On Tuesday July 12, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
>
> >
> >
> >Maybe it is worth repeating Al Viro's suggestion at this point. I
> >don't have a reference but the idea was basically that if you open
> >"/foo" and get filedescriptor N, then
> > /proc/self/fds/N-meta
> >is a direct
On Tuesday July 12, [EMAIL PROTECTED] wrote:
> >
> > Maybe it is worth repeating Al Viro's suggestion at this point. I
> > don't have a reference but the idea was basically that if you open
> > "/foo" and get filedescriptor N, then
> >/proc/self/fds/N-meta
>
> How am I supposed to get there
David Masover wrote:
>
> That's why we're trying to find something that people won't actually
> touch, especially since if we design it right, this will be the last
> delimiter introduced at the fs/vfs level.
Uh, no, there needs to be about a dozen or so more.
But not this year.
-
To unsubscribe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
> Horst von Brand wrote:
>
>
>>Hans Reiser <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>>Stefan Smietanowski wrote:
>>>
>>>
>>>
I think "..." and ".meta" both serve as a logical delimiter. However
some programs implement their
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Brown wrote:
> On Monday July 11, [EMAIL PROTECTED] wrote:
>
>>Stefan Smietanowski wrote:
>>
>>>-BEGIN PGP SIGNED MESSAGE-
>>>Hash: SHA1
>>>
>>>
>>>
Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it se
Neil Brown wrote:
>
>
>Maybe it is worth repeating Al Viro's suggestion at this point. I
>don't have a reference but the idea was basically that if you open
>"/foo" and get filedescriptor N, then
> /proc/self/fds/N-meta
>is a directory which contains all the meta stuff for "/foo".
>Then it is t
On Monday July 11, [EMAIL PROTECTED] wrote:
> Stefan Smietanowski wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >>Ok, still haven't heard much discussion of metafs vs file-as-directory,
> >>but it seems like it'd be easier in metafs.
> >
> >
> > Why not implement it ins
Horst von Brand wrote:
>Hans Reiser <[EMAIL PROTECTED]> wrote:
>
>
>>Stefan Smietanowski wrote:
>>
>>
>>>I think "..." and ".meta" both serve as a logical delimiter. However
>>>some programs implement their own "..." which would make it clash with
>>>them. Naturally if some program created a
On Mon, Jul 11, 2005 at 10:33:24PM -0400, Horst von Brand wrote:
> Hans Reiser <[EMAIL PROTECTED]> wrote:
> > I chose '' (four dots) because it clashes with less, not three dots.
>
> Is this some kind of "My dots are more than yours" contest?!
>
> /None/ of them is safe. ".meta", "...", "
David Masover <[EMAIL PROTECTED]> wrote:
[...]
> Both camps seem to want to allow easy access to the metadata of a
> file, whether we're given that file as an inode or as a pathname.
> That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
> to look up a file by name, and sometimes
Hans Reiser <[EMAIL PROTECTED]> wrote:
> Stefan Smietanowski wrote:
> > I think "..." and ".meta" both serve as a logical delimiter. However
> > some programs implement their own "..." which would make it clash with
> > them. Naturally if some program created a directory called .meta we're
> > equa
Stefan Smietanowski wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it seems like it'd be easier in metafs.
Why not implement it inside the directory containg the file ?
Ie the metadata for /home/stesmi/foo is
On Sun, 10 Jul 2005 02:00:49 +0200, Stefan Smietanowski <[EMAIL PROTECTED]>
said:
> So basically if I write a program that works in both Gnome and KDE I
> should (according to your description) implement my own VFS that will
> use the Gnome or KDE VFS that will then use the OS VFS.
Either that,
Stefan Smietanowski wrote:
>
> I think "..." and ".meta" both serve as a logical delimiter. However
> some programs implement their own "..." which would make it clash with
> them. Naturally if some program created a directory called .meta we're
> equally screwed.
I chose '' (four dots) becau
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
>> Why not implement it inside the directory containg the file ?
>>
>> Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
>>
>> This should be suit both camps I'd think?
>
> You still need to figure out the parent of "foo", which i
> So basically if I write a program that works in both Gnome and KDE
> I should (according to your description) implement my own VFS that
> will use the Gnome or KDE VFS that will then use the OS VFS.
>
> Is it only me finding that a little silly?
Maybe. Advantages of kde/gnome/other userland vfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Ok, still haven't heard much discussion of metafs vs file-as-directory,
> but it seems like it'd be easier in metafs.
Why not implement it inside the directory containg the file ?
Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hubert Chan wrote:
> On Thu, 30 Jun 2005 15:52:25 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
>
>
>>>This doesn't even invalidate the userland VFSs of the other guys,
>>>they're still needed for systems whose kernels don't have a metadata
>>>fac
Did you mean to reply to the list? I'm taking the liberty of sending
my reply to the list.
On 2005-07-06 17:50:07 -0400 Horst von Brand <[EMAIL PROTECTED]>
wrote:
Hubert Chan <[EMAIL PROTECTED]> wrote:
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand
<[EMAIL PROTECTED]>
said:
Hubert C
Hubert Chan wrote:
On Wed, 06 Jul 2005 23:42:50 -0700, Hans Reiser <[EMAIL PROTECTED]> said:
Oh no, don't store the whole path, store just the parent list. This
will make fsck more robust in the event that the directory gets
clobbered by hardware error.
I don't think it affects the cost o
On Wed, 06 Jul 2005 23:42:50 -0700, Hans Reiser <[EMAIL PROTECTED]> said:
> Oh no, don't store the whole path, store just the parent list. This
> will make fsck more robust in the event that the directory gets
> clobbered by hardware error.
> I don't think it affects the cost of detecting cycles
In article <[EMAIL PROTECTED]>,
David Masover <[EMAIL PROTECTED]> wrote:
>Markus Törnqvist wrote:
>> Anyway, I don't really like the metafs thing.
>>
>> To access the data, you still need to refactor userspace,
>> so that's not a real advantage. Doing lookups from /meta
>> all the time, instead o
Markus Törnqvist wrote:
On Fri, Jul 01, 2005 at 05:54:46PM +0200, David Weinehall wrote:
Which would neither need VFS changes nor be dependent on Reiser4 in
any way, so I don't see why this thread lives on. Just get down to
business and implement this metafs =)
I've been gone for a while an
On Fri, Jul 01, 2005 at 05:54:46PM +0200, David Weinehall wrote:
>
>Which would neither need VFS changes nor be dependent on Reiser4 in
>any way, so I don't see why this thread lives on. Just get down to
>business and implement this metafs =)
I've been gone for a while and suddenly drowning in ma
Jonathan Briggs wrote:
>On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
>
>
>>Hubert Chan wrote:
>>
>>
>>>And a question: is it feasible to store, for each inode, its parent(s),
>>>instead of just the hard link count?
>>>
>>>
>>>
>>>
>>Ooh, now that is an interesting old idea I
Horst von Brand wrote:
>Hans Reiser <[EMAIL PROTECTED]> wrote:
>
>[...]
>
>
>
>>I think the exokernel approach by Frans is a very interesting approach.
>>I wish I had the experience with it necessary to know if it was
>>effective. I do NOT take the position that name resolution should be in
>>
Doug Wicks wrote:
How do I get off the mail list here?
[EMAIL PROTECTED]
See www.namesys.com, click on "Join Mail List" then in "Unsubscribe
Mailinglist" and follow instructions.
Very difficult, i know.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
> mount --bind /meta/vfs/some/chroot /some/chroot/meta
This maybe funny if you got 1-2 chrooted applications.
But it will be a nightmare if you got 20-30 chrooted applications.
--
We're working on it, slowly but surely...or not-so-surely in the spots
we're not so sure... -- Larry Wall
-
To un
Neil Brown wrote:
On Tuesday July 5, [EMAIL PROTECTED] wrote:
I got it slightly wrong.
One can have hardlinks to a directory without cycles provided that one
does not have hardlinks from the children of that directory to any file
not a child of that directory. (Mountpoints currently implem
On Wed, Jul 06, 2005 at 09:33:13PM -0500, David Masover wrote:
> And speaking of which, the only doomsday scenario (running out of RAM)
> that I can think of with this scheme is if we have a ton of hardlinks to
> the same file and we try to move one of them. But this scales linearly
> with the
inux-kernel@vger.kernel.org; reiserfs-list@namesys.com;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: reiser4 plugins
>
> David Masover wrote:
>
> > So, will the format change happen at mount time? Will it need a
> > specia
Hubert Chan wrote:
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
Hubert Chan <[EMAIL PROTECTED]> wrote:
If you can store the parents, then finding cycles (relatively)
quickly is pretty easy: before you try to make A the parent of B,
walk up the parent pointers
David Masover wrote:
> And, once we start talking about applications, /meta will be more
> readily supported (as in, some apps will go through a pathname and
> stop when they get to a file, and then there's tar). On apps which
> don't have direct support for /meta, you'd be navigating to the file
Hans Reiser <[EMAIL PROTECTED]> wrote:
[...]
> I think the exokernel approach by Frans is a very interesting approach.
> I wish I had the experience with it necessary to know if it was
> effective. I do NOT take the position that name resolution should be in
> the kernel. I DO take the positio
Nate Diller wrote:
>
>
> as an example, if a program were to store some things it needs access
> to in its executable's attributes, it should have the option of
> keeping a hard reference to something, so that it can't be deleted out
> from underneath. this enables sane sharing of resources witho
PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; reiserfs-list@namesys.com;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: reiser4 plugins
David Masover wrote:
> So, w
David Masover wrote:
> So, will the format change happen at mount time? Will it need a
> special mount flag? Will I need to use debugfs or some other offline
> tool?
First we make sure we have the right answer. Have we solved the cycle
problem? Can we run out of memory as Horst/Nikita sugges
On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
> Hubert Chan wrote:
> >And a question: is it feasible to store, for each inode, its parent(s),
> >instead of just the hard link count?
> >
> >
> Ooh, now that is an interesting old idea I haven't considered in 20
> years makes fsck more r
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
> Hubert Chan <[EMAIL PROTECTED]> wrote:
>> If you can store the parents, then finding cycles (relatively)
>> quickly is pretty easy: before you try to make A the parent of B,
>> walk up the parent pointers starting from
Jonathan Briggs wrote:
On Wed, 2005-07-06 at 15:51 -0400, Hubert Chan wrote:
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
[snip]
It still has the performance and locking problem of having to update
every child file when moving a directory tree to a new paren
On Wed, 06 Jul 2005 14:33:18 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> On Wed, 2005-07-06 at 15:51 -0400, Hubert Chan wrote:
>> On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs
>> <[EMAIL PROTECTED]> said:
> [snip]
>>> It still has the performance and locking problem of having to
>>> u
Hans Reiser wrote:
David Masover wrote:
And, once we start talking about applications, /meta will be more
readily supported (as in, some apps will go through a pathname and
stop when they get to a file, and then there's tar). On apps which
don't have direct support for /meta, you'd be navigat
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
>> Hubert Chan wrote:
>>> And a question: is it feasible to store, for each
>>> inode, its parent(s), instead of just the hard link count?
>> Ooh, now that is an i
On Wed, 2005-07-06 at 15:51 -0400, Hubert Chan wrote:
> On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
[snip]
> > It still has the performance and locking problem of having to update
> > every child file when moving a directory tree to a new parent. On the
> > other
Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> > On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
> >> Hubert Chan wrote:
> >>> And a question: is it feasible to store, for each
> >>> inode, its parent(s), instead of jus
On Tue, 05 Jul 2005 22:51:07 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
> Hubert Chan <[EMAIL PROTECTED]> wrote:
>> On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]>
>> said:
>> > Horst von Brand wrote:
>> >> And who says that a normal user isn't allowed to annotate each and
Adrian Ulrich wrote:
so all we have left is the issue of whether using /meta costs us
performance, or whether breaking POSIX to add a symlink (such as
foo/...) really gives us that much more usability.
IMHO '/meta' isn't such a good idea, because a chrooted application
won't be able to use it
Hans Reiser wrote:
If we also add to this the restriction that once you create the file
part of a file-directory, you can never hardlink to a child of it, it
should then all work, yes?
So, /filename//owner should be able to avoid colliding with any
common names by virtue of the '', and n
> so all we have left is the issue of whether using /meta costs us
> performance, or whether breaking POSIX to add a symlink (such as
> foo/...) really gives us that much more usability.
IMHO '/meta' isn't such a good idea, because a chrooted application
won't be able to use it.
-
To unsubscri
Horst von Brand wrote:
Hubert Chan <[EMAIL PROTECTED]> wrote:
On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]> said:
Horst von Brand wrote:
And who says that a normal user isn't allowed to annotate each and
every file with its purpose or something else?
Explain how you
Horst von Brand wrote:
David Masover <[EMAIL PROTECTED]> wrote:
[...]
Just don't allow user-created hardlinks inside either metafs (/meta) or
the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files &c, and now it
Hans Reiser wrote:
Hubert Chan wrote:
On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <[EMAIL
PROTECTED]> said:
That sounds equivalent to no hard links (other than the usual parent
directory one). If there's any directory with two links to it, then
there will be a cycle
David Masover <[EMAIL PROTECTED]> wrote:
[...]
> Just don't allow user-created hardlinks inside either metafs (/meta) or
> the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files &c, and now it is severely crippled?
--
Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]> said:
> > Horst von Brand wrote:
> >> And who says that a normal user isn't allowed to annotate each and
> >> every file with its purpose or something else?
> Explain how you currently allow
Martin Waitz wrote:
>hoi :)
>
>On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
>
>
>>You could do filesystems in userspace too and just use the kernel's
>>block layer.
>>
>>
>
>but you can't do that in an library, you have to use a filesystem
>server in order to get access c
On Tue, Jul 05, 2005 at 06:43:31PM -0400, Jeremy Maitin-Shepard wrote:
> > Let's say cryptocompress gets implemented. Not all of userland
> > rewritten, not even any of userland rewritten, just a cryptocompress
> > plugin for the kernel. And instead of having to learn a new tool, I can
> > just b
hoi :)
On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
> You could do filesystems in userspace too and just use the kernel's
> block layer.
but you can't do that in an library, you have to use a filesystem
server in order to get access control.
But you can build a library that ha
Hubert Chan wrote:
>On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <[EMAIL
>PROTECTED]> said:
>
>
>
>>That sounds equivalent to no hard links (other than the usual parent
>>directory one). If there's any directory with two links to it, then
>>there will be a cycle somewhere!
>
On Tuesday July 5, [EMAIL PROTECTED] wrote:
> I got it slightly wrong.
>
> One can have hardlinks to a directory without cycles provided that one
> does not have hardlinks from the children of that directory to any file
> not a child of that directory. (Mountpoints currently implement that
> rest
On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <[EMAIL
PROTECTED]> said:
> That sounds equivalent to no hard links (other than the usual parent
> directory one). If there's any directory with two links to it, then
> there will be a cycle somewhere!
What we want is no directed c
Hans Reiser wrote on Tue, 05 Jul 2005 16:56:02 -0700:
> One can have hardlinks to a directory without cycles provided that one
> does not have hardlinks from the children of that directory to any file
> not a child of that directory. (Mountpoints currently implement that
> restriction.)
>
> Quest
Jeremy Maitin-Shepard wrote:
>Okay, so you are suggesting that file-as-dir would provide the user
>interface for enabling the encryption or compression. Alternatively,
>though, an ioctl could be used to control compression and encryption.
>
>
>
Why is it that /proc does not use an ioctl? Use o
If we also add to this the restriction that once you create the file
part of a file-directory, you can never hardlink to a child of it, it
should then all work, yes?
So, /filename//owner should be able to avoid colliding with any
common names by virtue of the '', and not letting any filedi
I got it slightly wrong.
One can have hardlinks to a directory without cycles provided that one
does not have hardlinks from the children of that directory to any file
not a child of that directory. (Mountpoints currently implement that
restriction.)
Question: can one implement that lesser restr
David Masover wrote:
>Now, can anyone think of a situation where we want user-created
>hardlinks inside metadata? More importantly, what do we do about it?
>
>
I think the equivalent of symlinks would be good enough to get by on for
now for most linking of metafiles. Maybe some years from now
David Masover <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> David Masover <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>>
I have. And have seen /no/ benefit to you. Except, of course, the benefit
accrued from some magic in Linus' kernel, by which all format differences
Hans Reiser wrote:
> David Masover wrote:
>
>
>>Hans Reiser wrote:
>>
>>
>>
>>>Hubert Chan wrote:
>>>
>>>
>>>
>>>
>>>
On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said:
>Hubert Chan wrote:
>
>
>
>
Jeremy Maitin-Shepard wrote:
> David Masover <[EMAIL PROTECTED]> writes:
>
> [snip]
>
>
>>>I have. And have seen /no/ benefit to you. Except, of course, the benefit
>>>accrued from some magic in Linus' kernel, by which all format differences
>>>go in a puff of smoke if they are implemented insid
David Masover wrote:
>Hans Reiser wrote:
>
>
>>Hubert Chan wrote:
>>
>>
>>
>>
>>>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said:
>>>
>>>
>>>
>>>
>>>
>>>
Hubert Chan wrote:
>>>
>>>
>>>
>>>
>The main thing blocking f
David Masover <[EMAIL PROTECTED]> writes:
[snip]
>> I have. And have seen /no/ benefit to you. Except, of course, the benefit
>> accrued from some magic in Linus' kernel, by which all format differences
>> go in a puff of smoke if they are implemented inside it, and furthermore
>> all userland ge
On Tue, 2005-07-05 at 17:46 +0200, Martin Waitz wrote:
[snip]
> Filesystems are there to store files.
> Everything else can be done in userspace.
You could do filesystems in userspace too and just use the kernel's
block layer.
In fact you can reduce the OS kernel to just interrupts, memory
manage
Horst von Brand wrote:
> David Masover <[EMAIL PROTECTED]> wrote:
>
>>Horst von Brand wrote:
>>
>>>David Masover <[EMAIL PROTECTED]> wrote:
>>>
David Weinehall wrote:
>On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
>
>>David Weinehall wrote:
>
>
> [...]
>
>
Hans Reiser wrote:
> Hubert Chan wrote:
>
>
>>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said:
>>
>>
>>
>>
>>>Hubert Chan wrote:
>>>
>>>
>>
>>
>>
>>
The main thing blocking file-as-dir is that there are some
locking(IIRC?) issues. And, of course, some peop
Hubert Chan wrote:
>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said:
>
>
>
>>Hubert Chan wrote:
>>
>>
>
>
>
>>>The main thing blocking file-as-dir is that there are some
>>>locking(IIRC?) issues. And, of course, some people wouldn't want it
>>>to be merged into
On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said:
> Hubert Chan wrote:
>> The main thing blocking file-as-dir is that there are some
>> locking(IIRC?) issues. And, of course, some people wouldn't want it
>> to be merged into the mainline kernel. (Of course, the latter
On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]> said:
> Horst von Brand wrote:
>> And who says that a normal user isn't allowed to annotate each and
>> every file with its purpose or something else?
Explain how you currently allow users to annotate arbitrary files.
>> I can ve
On Thu, 30 Jun 2005 15:52:25 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
>> This doesn't even invalidate the userland VFSs of the other guys,
>> they're still needed for systems whose kernels don't have a metadata
>> facility.
> So the metadata facility in kernel won't be used, for portabili
hoi :)
On Wed, Jun 29, 2005 at 08:04:58PM -0700, Hans Reiser wrote:
> >How is directories as files logically any different than putting all
> >data into .data files and making all files directories (yes you would
> >need some sort of special handling for files that were really called
> >.data).
>
David Masover <[EMAIL PROTECTED]> wrote:
> Horst von Brand wrote:
> > David Masover <[EMAIL PROTECTED]> wrote:
> >>David Weinehall wrote:
> >>>On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
> David Weinehall wrote:
[...]
> >>Even if they don't, it would be more beneficial to m
ff
Garzik; Christoph Hellwig; Andrew Morton; linux-kernel@vger.kernel.org;
ReiserFS List
Subject: Re: reiser4 plugins
Horst von Brand wrote:
>
>>Right. But, /proc started somewhere, didn't it?
>>
>>
>
>Sun.
>
>
No, plan 9.
-
To unsubscribe from this l
Horst von Brand wrote:
Kevin Bowen <[EMAIL PROTECTED]> wrote:
[...]
So, for instance, if I want to grab all mp3s with Artist "Paul
Oakenfold" and change the genre to "techno" (can you do that?), I can
use Beagle's search tool to find all mp3s by Oakenfold, but to change
the genre, I have to
Horst von Brand wrote:
David Masover <[EMAIL PROTECTED]> wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
GNOME and KDE run on operating systems that run other kernels than
Linux, hence they have to implement their own u
On Sun, Jul 03, 2005 at 08:42:24PM -0700, Hans Reiser wrote:
> >>Right. But, /proc started somewhere, didn't it?
> >>
> >>
> >
> >Sun.
> >
> >
> No, plan 9.
Almost on the right track, it was v8, two steps before plan9. But that's
just the process-part of procfs, not the big mess we have no
86 matches
Mail list logo
