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 users to add a
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 month that
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
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 THE VFS LAYER,
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 other words,
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
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
time.
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 literally
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 its own.
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,
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 included then.:)
Indeed,
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 other than
=)
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
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,
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,
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
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 generic, or should we
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
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 to
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
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
Ł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
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 you
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 sure.
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
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
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
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
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
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
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 a
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.
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 other than
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 for
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 have any
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?
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 generic, or
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
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
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.
Hmm,
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...
None of the
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 a
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
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
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
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
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
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
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
probably
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
but
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
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
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
53 matches
Mail list logo
