Hi!
> >> Most users not only cannot patch a kernel, they don't know what a patch
> >> is. It most certainly does.
> >
> >
> > obviously you can provide complete kernels, including precompiled ones.
> > Most distros have a yum or apt or similar tool to suck down packages,
> > it's trivial for u
Hi!
> > Using guilt as an argument in a technical discussion is a flashing red
> > sign that says "I have no technical rebuttal"
>
> Wow, that is really nervy. Let's recap this all:
>
> * reiser4 has a 2x performance advantage over the next fastest FS
> (ext3), and when compression ships in a m
Horst H. von Brand wrote:
Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote:
On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote:
What fancy (beside cryptocompress) does reiser4 do now?
it is supposed to provide an ability to easy modify filesystem behaviour
in various aspects without brea
Dnia Wed, 02 Aug 2006 20:45:07 +0200, Horst H. von Brand
<[EMAIL PROTECTED]> napisał:
Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote:
On Tue, 2006-08-01 at 17:32 +0200, �ukasz Mierzwa wrote:
> Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds
<[EMAIL PROTECTED]>
> napisał:
> > In othe
Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote:
> > Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds <[EMAIL PROTECTED]>
> > napisaÅ:
> > > In other words, if a filesystem wants to do something fancy, it needs to
> > > do so WITH TH
Christian Trefzer wrote:
On Mon, Jul 31, 2006 at 10:57:35AM -0500, David Masover wrote:
Wil Reichert wrote:
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked it, b
Hello
On Tue, 2006-08-01 at 17:32 +0200, Łukasz Mierzwa wrote:
> Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds <[EMAIL PROTECTED]>
> napisał:
>
> > In other words, if a filesystem wants to do something fancy, it needs to
> > do so WITH THE VFS LAYER, not as some plugin architecture of it
Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds <[EMAIL PROTECTED]>
napisał:
In other words, if a filesystem wants to do something fancy, it needs to
do so WITH THE VFS LAYER, not as some plugin architecture of its own. We
already have exactly the plugin interface we need, and it literall
On Mon, Jul 31, 2006 at 06:05:01PM +0200, Łukasz Mierzwa wrote:
> I gues that extens are much harder to reuse then normal inodes so when You
> have something as big as portage tree filled with nano files wich are
> being modified all the time then You just can't keep performance all the
> ti
On Mon, Jul 31, 2006 at 10:57:35AM -0500, David Masover wrote:
>
> Wil Reichert wrote:
>
> >Any idea how the fragmentation resulting from re-syncing the tree
> >affects performance over time?
>
> Yes, it does affect it a lot. I have no idea how much, and I've never
> benchmarked it, but purely s
On Monday 31 July 2006 21:35, Łukasz Mierzwa wrote:
> I gues that extens are much harder to reuse then normal inodes so when You
> have something as big as portage tree filled with nano files wich are
> being modified all the time then You just can't keep performance all the
> time. You can always
Dnia Mon, 31 Jul 2006 17:57:35 +0200, David Masover <[EMAIL PROTECTED]>
napisał:
Wil Reichert wrote:
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Try to post replies at the bottom, or below the context.
Yes,
Wil Reichert wrote:
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Try to post replies at the bottom, or below the context.
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked it, bu
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Wil
On 7/30/06, Christian Trefzer <[EMAIL PROTECTED]> wrote:
On Sun, Jul 30, 2006 at 11:39:42PM +0200, Christian Trefzer wrote:
>
> In order to avoid having to pull the
Hans Reiser <[EMAIL PROTECTED]> wrote:
> David Masover wrote:
> > If indeed it can be changed easily at all. I think the burden is on
> > you to prove that you can change it to be more generic, rather than
> > saying "Well, we could do it later, if people want us to..."
> None of the filesystems
Hans Reiser writes:
> Nikita Danilov wrote:
[...]
> >
> >As you see, ext2 code already has multiple file "plugins", with
> >persistent "plugin id" (stored in i_mode field of on-disk struct
> >ext2_inode).
> >
> >Nikita.
> >
> >
> So the job is already done. Good. Reiser4 can be includ
Christian Trefzer wrote:
On Sun, Jul 30, 2006 at 11:39:42PM +0200, Christian Trefzer wrote:
In order to avoid having to pull the whole tree via rsync again, you
might want to grab my script from the list and adapt it to your needs.
Of course, you can tar it up manually instead. Silly me, but a
On Sun, Jul 30, 2006 at 11:39:42PM +0200, Christian Trefzer wrote:
>
> In order to avoid having to pull the whole tree via rsync again, you
> might want to grab my script from the list and adapt it to your needs.
Of course, you can tar it up manually instead. Silly me, but after
approx. 9h of stu
Hi Wil,
On Sun, Jul 30, 2006 at 02:10:04PM -0700, Wil Reichert wrote:
> Hmm, looks like I have a partition to re-format now.
In order to avoid having to pull the whole tree via rsync again, you
might want to grab my script from the list and adapt it to your needs.
Kind regards,
Chris
pgpNAbzw
If reiser4 is delayed enough, for reasons that have nothing to do
with
its needs, and without it having encumbered anyone else, it won't be
ahead of the other filesystems when it ships.
How is that important in any way for the Linux kernel? This is not
(and has
not been for quite some time
Hmm, looks like I have a partition to re-format now.
Wil
On 7/30/06, Christian Trefzer <[EMAIL PROTECTED]> wrote:
On Sat, Jul 29, 2006 at 03:30:15PM -0500, David Masover wrote:
>
> Is /usr/portage still faster on Reiser4? I know it was when I switched,
> but that was years ago...
It is for su
Hans Reiser <[EMAIL PROTECTED]> wrote:
> Let me put it from my perspective and stop pretending to be unbiased, so
> others can see where I am coming from.
OK, but /that/ was pretty clear from day one...
> No one was interested in our
> plugins.
Should tell
Łukasz Mierzwa wrote:
Dnia Sat, 29 Jul 2006 20:31:59 +0200, David Masover <[EMAIL PROTECTED]>
napisał:
Nikita Danilov wrote:
As you see, ext2 code already has multiple file "plugins", with
persistent "plugin id" (stored in i_mode field of on-disk struct
ext2_inode).
Aha! So here's another
On Sat, Jul 29, 2006 at 03:30:15PM -0500, David Masover wrote:
>
> Is /usr/portage still faster on Reiser4? I know it was when I switched,
> but that was years ago...
It is for sure. v4 is even better with fantastillions of small files
than v3.
uziel
pgpxeVIQPVXTn.pgp
Description: PGP signat
Dnia Sun, 30 Jul 2006 03:08:55 +0200, Hans Reiser <[EMAIL PROTECTED]>
napisał:
Maciej Sołtysiak wrote:
Hmm, what about linspire / freespire ? Linsire is a proud reiser4
debugging
sponsor as the website (http://www.namesys.com) says.
Wouldn't they want to include reiser4 in their distro
Dnia Sat, 29 Jul 2006 20:31:59 +0200, David Masover <[EMAIL PROTECTED]>
napisał:
Nikita Danilov wrote:
As you see, ext2 code already has multiple file "plugins", with
persistent "plugin id" (stored in i_mode field of on-disk struct
ext2_inode).
Aha! So here's another question: Is it fair
Maciej Sołtysiak wrote:
>
>Hmm, what about linspire / freespire ? Linsire is a proud reiser4 debugging
>sponsor as the website (http://www.namesys.com) says.
>
>Wouldn't they want to include reiser4 in their distro first?
>
>
>
Not if the mainstream kernel is not going to add it.
Hans
David Masover wrote:
>Nikita Danilov wrote:
>
>
>
>>As you see, ext2 code already has multiple file "plugins", with
>>persistent "plugin id" (stored in i_mode field of on-disk struct
>>ext2_inode).
>>
>>
>
>Aha! So here's another question: Is it fair to ask Reiser4 to make its
>plugins gen
Nikita Danilov wrote:
>Hans Reiser writes:
> > David Masover wrote:
> >
> > >
> > > If indeed it can be changed easily at all. I think the burden is on
> > > you to prove that you can change it to be more generic, rather than
> > > saying "Well, we could do it later, if people want us to..."
> >
Hello David,
Saturday, July 29, 2006, 8:11:11 PM, you wrote:
> What's more, many distros patch their kernels extensively. They listen
> to their users, too. So if there are a lot of users wanting this to be
> in the kernel, let them complain -- loudly -- to their distro to patch
> for Reiser4.
H
Sarath Menon wrote:
On Saturday 29 July 2006 23:41, David Masover wrote:
I know Gentoo handles this automatically (emerge nvidia-kernel).
I hate to say this again, but its not automatically. It requires more
My point is, there's a fairly large group of users who would be willing
to do tha
On Saturday 29 July 2006 23:41, David Masover wrote:
> I know Gentoo handles this automatically (emerge nvidia-kernel).
I hate to say this again, but its not automatically. It requires more
knowledge of ther user, and is more than asking users to patch the kernel. (I
am in the support industry
David Masover writes:
> Nikita Danilov wrote:
>
> > As you see, ext2 code already has multiple file "plugins", with
> > persistent "plugin id" (stored in i_mode field of on-disk struct
> > ext2_inode).
>
> Aha! So here's another question: Is it fair to ask Reiser4 to make its
> plugins
Nikita Danilov wrote:
> As you see, ext2 code already has multiple file "plugins", with
> persistent "plugin id" (stored in i_mode field of on-disk struct
> ext2_inode).
Aha! So here's another question: Is it fair to ask Reiser4 to make its
plugins generic, or should we be asking ext2/3 first?
Hans Reiser wrote:
> David Masover wrote:
>
>> If indeed it can be changed easily at all. I think the burden is on
>> you to prove that you can change it to be more generic, rather than
>> saying "Well, we could do it later, if people want us to..."
>
> None of the filesystems other than reiser4
Arjan van de Ven wrote:
>> Most users not only cannot patch a kernel, they don't know what a patch
>> is. It most certainly does.
>
>
> obviously you can provide complete kernels, including precompiled ones.
> Most distros have a yum or apt or similar tool to suck down packages,
> it's trivial
Hans Reiser writes:
> David Masover wrote:
>
> >
> > If indeed it can be changed easily at all. I think the burden is on
> > you to prove that you can change it to be more generic, rather than
> > saying "Well, we could do it later, if people want us to..."
>
> None of the filesystems ot
Mike and Lukasz, please post your email to not just reiserfs-list, where
only the reiserfs team will read it, but also to lkml if you could,
please? Thanks for your support, user opinions count for a lot on lkml.
Jeff Garzik wrote:
>
> Using guilt as an argument in a technical discussion is a flashing red
> sign that says "I have no technical rebuttal"
Wow, that is really nervy. Let's recap this all:
* reiser4 has a 2x performance advantage over the next fastest FS
(ext3), and when compression ships in
> Most users not only cannot patch a kernel, they don't know what a patch
> is. It most certainly does.
obviously you can provide complete kernels, including precompiled ones.
Most distros have a yum or apt or similar tool to suck down packages,
it's trivial for users to add a site to that, so
David Masover wrote:
>
> If indeed it can be changed easily at all. I think the burden is on
> you to prove that you can change it to be more generic, rather than
> saying "Well, we could do it later, if people want us to..."
None of the filesystems other than reiser4 have any interest in using
Hans Reiser wrote:
As for this "we are all too grand to be bothered with money to feed our
families" business, building a system in which those who contribute can
find a way to be rewarded is what managers do. Free software
programmers may be willing to live on less than others, but they cannot
Hans Reiser wrote:
plugins if not for us. Our plugins affect no one else. Our
self-contained code should not be delayed because other people delayed
And at the moment, I can still use Reiser4. If I ever make a distro, I
will include Reiser4 support, probably as the default FS. That will
On Fri, 2006-07-28 at 22:58 +0200, Łukasz Mierzwa wrote:
> It just hited me that 90% of mails (those I've read and remember) in which
> You guys are talking why r4 should or should not be merged did not contain
> a patch or not even a line of code as a reference, most of complains feels
> so
Dnia Fri, 28 Jul 2006 15:34:36 +0200, Hans Reiser <[EMAIL PROTECTED]>
napisał:
Let me put it from my perspective and stop pretending to be unbiased, so
others can see where I am coming from. No one was interested in our
plugins. We put the design on a website, spoke at conferences, no one
bu
Hua Zhong wrote:
>I remember someone said something along the lines of "Linux is evolution, not
>revolution". To me it seems unreasonable to put all
>the "revolutionary" VFS burden upon reiserfs team. It's not practical.
>
>
>
>
Thanks for saying that Hua. We have a guy named Nate Diller, who
Let me put it from my perspective and stop pretending to be unbiased, so
others can see where I am coming from. No one was interested in our
plugins. We put the design on a website, spoke at conferences, no one
but users were interested. No one would have conceived of having
plugins if not for u
> Doesn't have to be in fstab, I hope, but think of it this
> way: ext3 uses JBD for its journaling. As I understand it,
> any other filesystem can also use JBD, and ext3 is mostly ext2 + JDB.
The fact that no other major journaling filesystems use JBD except EXT3 might
make this idea less ap
Hans Reiser wrote:
Linus Torvalds wrote:
In other words, if a filesystem wants to do something fancy, it needs to
do so WITH THE VFS LAYER, not as some plugin architecture of its own.
(Let us try to avoid arguments over whether if you extend VFS it is
still called VFS or is called reiser
Linus Torvalds wrote:
>
>
>In other words, if a filesystem wants to do something fancy, it needs to
>do so WITH THE VFS LAYER, not as some plugin architecture of its own.
>
Where does VFS store the plugin ids that specify per file variations?
/etc/fstab? Also, is (current) VFS the interface for
On Fri, 28 Jul 2006, David Masover wrote:
>
> But what's wrong with people doing such experiments outside the kernel?
> AFAICS, "exotic, site-specific one" is not something that would be considered
> for inclusion.
Here's a few ground rules at least from my viewpoint:
- as long you call them
Horst H. von Brand wrote:
Jeff Garzik <[EMAIL PROTECTED]> wrote:
[...]
It is then simple to follow that train of logic: why not make it easy
to replace the directory algorithm [and associated metadata]? or the
file data space management algorithms? or even the inode handling?
why not allow
Jeff Garzik <[EMAIL PROTECTED]> wrote:
[...]
> It is then simple to follow that train of logic: why not make it easy
> to replace the directory algorithm [and associated metadata]? or the
> file data space management algorithms? or even the inode handling?
> why not allow customers to replace
53 matches
Mail list logo
