David Masover wrote:
I am skeptical that it gets worse than V3, unless it is because we
haven't put in all the bitmap optimizations we did for V3. I wish I
knew how to measure it.
Me too. It's fairly subjective on my part, so maybe not. After all,
I've gone from
So for most webserver cases, FS speed doesn't matter. For the few
cases where it does, locality is usually fairly good... so who cares
if the new FS is 2x faster, when it is still 200x slower than ram. Add
ram.
But Reiser4 helps stuffing more files into the cache.
It also helps when
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
michael chang wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
David Masover wrote:
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other
On Tue, 09 Aug 2005 13:52:49 EDT, michael chang said:
Striped RAID only works if you have multiple disks and a decent bus.
I'm stuck on the lowest-end Dell Dimension 3000, with one of the
slowest hard drives in history. And I haven't gotten around to
opening the case... yet.
Newbie. ;)
michael chang wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
michael chang wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
David Masover wrote:
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already
Gregory Maxwell wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
[...]
My ability to use it is severely hampered only being able to use it on
boxes running test-kernel of the day.. which are laden with other
issues unrelated to reiser4 that I don't have time to deal with.
How recent
Forgive me for moving to private, but I've posted this on the list before
without comment.
The 2.6.12.x patches and 2.6.12.x applied from -mm have incorrect behavior
when modifying the root directory. If you add or remove files in the root,
the filesystem check fails. You can try this on a ram
Pat Double wrote:
Forgive me for moving to private, but I've posted this on the list before
without comment.
Make it public again if you like.
The 2.6.12.x patches and 2.6.12.x applied from -mm have incorrect behavior
when modifying the root directory. If you add or remove files in the root,
Actually I did make it public, hit the wrong command on my mail client ;)
I did not try the -mm kernel (latest patches is for -mm5 IIRC), I use software
suspend 2 and it does not apply to the 2.6.12.x-mm series. Except for this
problem reiser4 has worked great for me. Since I use a single
Pat Double wrote:
Actually I did make it public, hit the wrong command on my mail client ;)
I did not try the -mm kernel (latest patches is for -mm5 IIRC), I use software
suspend 2 and it does not apply to the 2.6.12.x-mm series. Except for this
problem reiser4 has worked great for me. Since
On Tuesday 09 August 2005 09:32 pm, David Masover wrote:
Pat Double wrote:
Actually I did make it public, hit the wrong command on my mail client ;)
I did not try the -mm kernel (latest patches is for -mm5 IIRC), I use
software suspend 2 and it does not apply to the 2.6.12.x-mm series.
I just wanted to say thank you for putting together reiser4 :)
Same here. The first filesystem ever which makes a crummy laptop drive
look goo, and that's saying something.
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my battery runs out. Any idea when it will make
it into the stable 2.6 kernel?
If only it had a resizer :(
That's one of the main reasons I stopped
On 2005-08-08 14:09, Raymond A. Meijer wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my battery runs out. Any idea when it will make
it into the stable 2.6 kernel?
Yes, yes, yes.
I had a DMA problem and the laptop froze several times on high
If only it had a resizer :(
I would definitely give $25 for the repacker, which is the mandatory
condition to get the resizer. How many people would give $25 too ? why not
do a little fundraising ?
Hemiplegic Menehune wrote:
Hi,
I just wanted to say thank you for putting together reiser4 :)
I just upgraded to the latest -mm kernel on my box and my jaw is on the
floor looking at the performance of reiser4. I have previously played around
with it on a few occasions, but I never had the
I should add that fsync performance has not been worked on yet, which is
surely why postgres performance is poor.
Hans
Hemiplegic Menehune wrote:
Hi,
I just wanted to say thank you for putting together reiser4 :)
I just upgraded to the latest -mm kernel on my box and my jaw is on the
floor
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my battery runs out. Any idea when it will make
it into the stable 2.6 kernel?
If only it had a resizer :(
Resizer
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
PFC wrote:
If only it had a resizer :(
I would definitely give $25 for the repacker, which is the
mandatory condition to get the resizer. How many people would give $25
too ? why not do a little fundraising ?
I would give $25 before
On 8/8/05, michael chang [EMAIL PROTECTED] wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
PFC wrote:
If only it had a resizer :(
I would definitely give $25 for the repacker, which is the
mandatory condition to get the resizer. How many people would give $25
too ? why
how many people are on reiserfs-list? On 8/8/05, michael chang [EMAIL PROTECTED] wrote:
On 8/8/05, michael chang [EMAIL PROTECTED] wrote: On 8/8/05, David Masover [EMAIL PROTECTED] wrote: PFC wrote:
If only it had a resizer :( I would definitely give $25 for the repacker, which is the
Hello David,
Monday, August 8, 2005, 9:56:36 PM, you wrote:
What I want is the repacker, beacuse performance does steadily degrade
on my Reiser4 systems, eventually getting worse than Reiser3, but not
worse than VFAT -- probably because my old FAT partitions are on old,
virus-ridden systems.
On 8/8/05, Bedros Hanounik [EMAIL PROTECTED] wrote:
On 8/8/05, michael chang [EMAIL PROTECTED] wrote:
On 8/8/05, michael chang [EMAIL PROTECTED] wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
PFC wrote:
If only it had a resizer :(
I would definitely give $25 for
On 2005-08-08 16:58, michael chang wrote:
To get $90 000 USD for Reiser4
= = = = =
If Paypal account used on Fundable.org is owned by Namesys:
Required before Fees: $ 96550.25
Donators at $25 ea: 3863 (-- mostly because of that last evil quarter
[...]
You also have to
David Masover wrote:
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my battery runs out. Any idea when it will make
it into the stable 2.6 kernel?
If only it had
I think we should just let the current possible big sponsor take care of
the repacker sponsoring, and I will focus on making that happen.
Hns
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
I should add that fsync performance has not been worked on yet, which is
surely why postgres performance is poor.
Hans, I'm on the postgresql hackers list (although I don't really have
a voice there, so I can't really speak much for reiser4
Gregory Maxwell wrote:
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
I should add that fsync performance has not been worked on yet, which is
surely why postgres performance is poor.
Hans, I'm on the postgresql hackers list (although I don't really have
a voice there, so I can't
Hans Reiser wrote:
David Masover wrote:
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my battery runs out. Any idea when it will make
it into the stable 2.6
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
David Masover wrote:
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my battery runs out. Any idea
Gregory Maxwell wrote:
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
If ever you are looking for a killer app for Reiser4 that people who
don't care about the visionary stuff will care about:
Define visionary?
I can name a few things that work best in Reiser4, and very well in v3,
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Gregory Maxwell wrote:
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
If ever you are looking for a killer app for Reiser4 that people who
don't care about the visionary stuff will care about:
Define visionary?
I can name a few
michael chang wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
David Masover wrote:
Raymond A. Meijer wrote:
On Monday 8 August 2005 13:32, Hemiplegic Menehune wrote:
Its already as stable as any other fs on my systems and recovers
better than most when my
Gregory Maxwell wrote:
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Gregory Maxwell wrote:
On 8/8/05, Hans Reiser [EMAIL PROTECTED] wrote:
If ever you are looking for a killer app for Reiser4 that people who
don't care about the visionary stuff will care about:
Define visionary?
I
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Reiser4 would be great if... is getting old. It is great, and it's
getting even better pretty fast.
And, by the way, if the transaction interface gets done, it's not just
databases that will benefit, but also small files. After all, what
On 8/8/05, David Masover [EMAIL PROTECTED] wrote:
Absolutely. I'm not knocking your idea, just wanted to clarify that
Reiser4 would be great if... is getting old. It is great, and it's
getting even better pretty fast.
(sorry for reply bloat)
I just wanted to point out.. that wasn't my
Hello
sergey ivanov wrote:
I have a problem with reiser4.
Recently I have installed Altlinux Compact-rc2 on reiserfs (v3.6),
patched kernel 2.6.12 with patch 2.6.12-mm2, created new reiser4
partition hda6 and copied by #cp -ax / /mnt/hda6 there. Fixed /etc/fstab
and /boot/grub for new partition
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 inside the directory
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 trivial to
-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 seems like it'd be easier in
-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 own ... which would make it clash
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.
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 with a shell
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 directory which
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/self/fds/N-meta
is a
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 think it's far
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
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
-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 isn't
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) because it
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, or
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
equally screwed.
I
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 by
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, ..., ,
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 directory called .meta
-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
facility.
So
-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
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 of
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.
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
the kernel. I
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 haven't considered in 20
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
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
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!
What we
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
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 control.
But you
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?
--
Dr.
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 users to
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
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 is
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
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
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
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
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 position
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
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 without
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 robust
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 interesting
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
every file
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 hand,
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 just the hard link
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
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
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 A. If
PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: reiser4 plugins
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
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
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
;
[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
special mount flag? Will I need to use debugfs or some other offline
tool?
First we make sure
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
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).
Add
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 portability's
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 very well
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
doesn't
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 the mainline kernel.
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 people wouldn't want it
to be merged into
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:
[...]
Even if they don't, it would be more
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
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 file-as-dir is that there are some
locking(IIRC?) issues. And, of
501 - 600 of 1292 matches
Mail list logo
