On 08 Apr 2007 06:32:26 +0200, Christer Weinigel <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] writes:
> Lennart. Tell me again that these results from
>
> http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
> http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
>
> are not of
[EMAIL PROTECTED] wrote:
On Mon, 09 Apr 2007 00:58:53 +0200, "Richard Knutsson"
<[EMAIL PROTECTED]> said:
Wow, I'm impressed. Think you got the record on how many mails you
referenced to in a reply...
TWO actually. I guess you are easily impressed.
Oh, took it to be from 5-6
On Sun, Apr 08, 2007 at 10:14:18PM -0700, [EMAIL PROTECTED] wrote:
> NO. You people simply come across as zealots who work together, against
> Reiser4.
Poor guy ! People are not against Reiser4, they are against the stupid and
irritating person who pollutes the lists always sending the same
On Sun, Apr 08, 2007 at 10:14:18PM -0700, [EMAIL PROTECTED] wrote:
NO. You people simply come across as zealots who work together, against
Reiser4.
Poor guy ! People are not against Reiser4, they are against the stupid and
irritating person who pollutes the lists always sending the same results
[EMAIL PROTECTED] wrote:
On Mon, 09 Apr 2007 00:58:53 +0200, Richard Knutsson
[EMAIL PROTECTED] said:
Wow, I'm impressed. Think you got the record on how many mails you
referenced to in a reply...
TWO actually. I guess you are easily impressed.
Oh, took it to be from 5-6
On 08 Apr 2007 06:32:26 +0200, Christer Weinigel [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
Lennart. Tell me again that these results from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are not of interest to
On Mon, 09 Apr 2007 00:58:53 +0200, "Richard Knutsson"
<[EMAIL PROTECTED]> said:
> Wow, I'm impressed. Think you got the record on how many mails you
> referenced to in a reply...
TWO actually. I guess you are easily impressed.
A simple cut and paste error.
> You have got some rude answers
Wow, I'm impressed. Think you got the record on how many mails you
referenced to in a reply... But dude, please calm down, the caps-lock is
not the answer. You have got some rude answers and you have called them
back on it + you have repeated the same statement several times, that is
not the
Christer Weinigel: Until YOU, have actually used the REISER4 filesystem
yourself, I think YOU OWE IT to the people on the linux-kernel mailing
list, to, AS YOU SAY, shut the fuck up.
Even reading up on the REISER4 filesystem would help.
Applying a little intelligence would undoubtedly help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theodore Tso wrote:
> The reason why I ignore the tar+gzip tests is that in the past Hans
> has rigged the test by using a tar ball which was generated by
> unpacking a set of kernel sources on a reiser4 filesystem, and then
> repacking them using
The reason why I ignore the tar+gzip tests is that in the past Hans
has rigged the test by using a tar ball which was generated by
unpacking a set of kernel sources on a reiser4 filesystem, and then
repacking them using tar+gzip. The result was a tar file whose files
were optimally laid out so
On Sat, Apr 07, 2007 at 01:10:31PM -0400, [EMAIL PROTECTED] wrote:
> On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
>
> > > Think about it,... read speeds that are some FOUR times the physical
> > > disk read rate,... impossible without the use of compression (or
> > > something
On Sun, Apr 08, 2007 at 06:21:29AM -0700, [EMAIL PROTECTED] wrote:
> Jose,
> since you clearly have nothing useful to say. Why don't you let Teddy
> talk for himself.
John,
You should first apply your own advice to yourself. Annoying everyone
with the exact same mail 10 times a day is really
Jose,
since you clearly have nothing useful to say. Why don't you let Teddy
talk for himself.
On Sun, 8 Apr 2007 13:48:11 +0100, "Jose Celestino" <[EMAIL PROTECTED]>
said:
> Words by [EMAIL PROTECTED] [Sat, Apr 07, 2007 at 09:13:32PM
> -0700]:
> > Teddy,
> >
> > It is a pity you don't
Words by [EMAIL PROTECTED] [Sat, Apr 07, 2007 at 09:13:32PM -0700]:
> Teddy,
>
> It is a pity you don't address the full set of results, when you make
> your snide comments.
>
> Now since you have them,... why don't you make reasoned comment about
> them.
>
> You can read more here:
>
John,
Words by [EMAIL PROTECTED] [Sat, Apr 07, 2007 at 09:13:32PM -0700]:
Teddy,
It is a pity you don't address the full set of results, when you make
your snide comments.
Now since you have them,... why don't you make reasoned comment about
them.
You can read more here:
John,
it is not
Jose,
since you clearly have nothing useful to say. Why don't you let Teddy
talk for himself.
On Sun, 8 Apr 2007 13:48:11 +0100, Jose Celestino [EMAIL PROTECTED]
said:
Words by [EMAIL PROTECTED] [Sat, Apr 07, 2007 at 09:13:32PM
-0700]:
Teddy,
It is a pity you don't address the full
On Sun, Apr 08, 2007 at 06:21:29AM -0700, [EMAIL PROTECTED] wrote:
Jose,
since you clearly have nothing useful to say. Why don't you let Teddy
talk for himself.
John,
You should first apply your own advice to yourself. Annoying everyone
with the exact same mail 10 times a day is really
On Sat, Apr 07, 2007 at 01:10:31PM -0400, [EMAIL PROTECTED] wrote:
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
Think about it,... read speeds that are some FOUR times the physical
disk read rate,... impossible without the use of compression (or
something similar).
The reason why I ignore the tar+gzip tests is that in the past Hans
has rigged the test by using a tar ball which was generated by
unpacking a set of kernel sources on a reiser4 filesystem, and then
repacking them using tar+gzip. The result was a tar file whose files
were optimally laid out so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theodore Tso wrote:
The reason why I ignore the tar+gzip tests is that in the past Hans
has rigged the test by using a tar ball which was generated by
unpacking a set of kernel sources on a reiser4 filesystem, and then
repacking them using
Christer Weinigel: Until YOU, have actually used the REISER4 filesystem
yourself, I think YOU OWE IT to the people on the linux-kernel mailing
list, to, AS YOU SAY, shut the fuck up.
Even reading up on the REISER4 filesystem would help.
Applying a little intelligence would undoubtedly help
Wow, I'm impressed. Think you got the record on how many mails you
referenced to in a reply... But dude, please calm down, the caps-lock is
not the answer. You have got some rude answers and you have called them
back on it + you have repeated the same statement several times, that is
not the
On Mon, 09 Apr 2007 00:58:53 +0200, Richard Knutsson
[EMAIL PROTECTED] said:
Wow, I'm impressed. Think you got the record on how many mails you
referenced to in a reply...
TWO actually. I guess you are easily impressed.
A simple cut and paste error.
You have got some rude answers and you
[EMAIL PROTECTED] writes:
> Lennart. Tell me again that these results from
>
> http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
> http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
>
> are not of interest to you. I still don't understand why you have your
> head in the sand.
Teddy,
It is a pity you don't address the full set of results, when you make
your snide comments.
Now since you have them,... why don't you make reasoned comment about
them.
You can read more here:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] wrote:
> To get a feel for the performance increases that can be achieved by
> using compression, we look at the total time (in seconds) to run the
> test:
You mean the performance increases of writing a file which is mostly
all zero's?
On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] wrote:
> Lennart. Tell me again that these results from
>
> http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
> http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
Hmm, copying kernel sources around. Not that
Lennart. Tell me again that these results from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are not of interest to you. I still don't understand why you have your
head in the sand.
.-.
|
[EMAIL PROTECTED] writes:
> I am quite sure that the kernel RPM file is *already* compressed, at least
> somewhat.
Sure - that's the point - it's better to have the tool compress
data when it makes sense.
OTOH I think Reiser4 fs is not about transparent compression, it's
rather about the
On Thu, Apr 05, 2007 at 09:32:11PM -0700, [EMAIL PROTECTED] wrote:
> Don't you agree, that "If they are accurate, THEN they are obviously
> very relevant."
Nope, if they are accurate and they have something to do with your
particular usage and applications, then they are relevant. But it
On Fri, 06 Apr 2007 19:47:36 PDT, [EMAIL PROTECTED] said:
> On Fri, 6 Apr 2007 11:21:19 -0400, "Jan Harkes" <[EMAIL PROTECTED]>
> > With compression there is a pretty high probability that one corrupted
> > byte or disk block will result in loss of a considerably larger amount
> > of data.
>
>
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
>
> Gzip - 3 files (zeros only, raw DV data from video camera, x86_64
> kernel rpm file), 10 MB of data (10*1024*1024),
> $ l -Ggh zeros dv bin
> -rw-r--r-- 1 10M Apr 7 15:30 bin
> -rw-r--r-- 1 10M Apr 7 15:31 dv
> -rw-r--r-- 1 10M Apr
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
> > Think about it,... read speeds that are some FOUR times the physical
> > disk read rate,... impossible without the use of compression (or
> > something similar).
>
> It's really impossible with compression only unless you're writing
On 4/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times the physical disk read rate, 63,160 K/sec, of the hard drive.
On Sat, 7 Apr 2007 13:59:14 +0100, "Dale Amon" <[EMAIL PROTECTED]> said:
> Jan does have a point about bad blocks. A couple years ago
> I had a relatively new disk start to go bad on random blocks.
> I detected it fairly quickly but did have some data loss.
>
> All the compressed archives which
Krzysztof -- Aren't you missing the point? Twice the speed would be
great,... even a 50% increase,... even a 0% increase.
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times
[EMAIL PROTECTED] writes:
> Why do you think I hate reiserfs developers? That is an insane claim.
> Why would I hate reiser3 developers?
> Why would I hate reiser4 developers?
> Why would I even dislike them?
>
> I think Hans Reiser is a genius. Is that what you mean by hate?
I think they could
Jan does have a point about bad blocks. A couple years ago
I had a relatively new disk start to go bad on random blocks.
I detected it fairly quickly but did have some data loss.
All the compressed archives which were hit were near
total losses; most other files were at least partially
Hi Willy,...
> With decent CPU, you can reach higher read/write data rates than what a
> single off-the-shelf disk can achieve. For this reason, I think that
> reiser4 would be worth trying for this particular usage.
Glad to see you are willing to give Reiser4 a go.
Good man.
On Fri, Apr 06, 2007 at 10:58:45PM -0700, [EMAIL PROTECTED] wrote:
> You know,... you cut out this bit:
>
> -
>
> > The following benchmarks are from
> >
> > http://linuxhelp.150m.com/resources/fs-benchmarks.htm or,
> >
On Fri, Apr 06, 2007 at 10:58:45PM -0700, [EMAIL PROTECTED] wrote:
You know,... you cut out this bit:
-
The following benchmarks are from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm or,
Hi Willy,...
With decent CPU, you can reach higher read/write data rates than what a
single off-the-shelf disk can achieve. For this reason, I think that
reiser4 would be worth trying for this particular usage.
Glad to see you are willing to give Reiser4 a go.
Good man.
Jan does have a point about bad blocks. A couple years ago
I had a relatively new disk start to go bad on random blocks.
I detected it fairly quickly but did have some data loss.
All the compressed archives which were hit were near
total losses; most other files were at least partially
[EMAIL PROTECTED] writes:
Why do you think I hate reiserfs developers? That is an insane claim.
Why would I hate reiser3 developers?
Why would I hate reiser4 developers?
Why would I even dislike them?
I think Hans Reiser is a genius. Is that what you mean by hate?
I think they could hire
Krzysztof -- Aren't you missing the point? Twice the speed would be
great,... even a 50% increase,... even a 0% increase.
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times
On Sat, 7 Apr 2007 13:59:14 +0100, Dale Amon [EMAIL PROTECTED] said:
Jan does have a point about bad blocks. A couple years ago
I had a relatively new disk start to go bad on random blocks.
I detected it fairly quickly but did have some data loss.
All the compressed archives which were hit
On 4/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times the physical disk read rate, 63,160 K/sec, of the hard drive.
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
Think about it,... read speeds that are some FOUR times the physical
disk read rate,... impossible without the use of compression (or
something similar).
It's really impossible with compression only unless you're writing
only
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
Gzip - 3 files (zeros only, raw DV data from video camera, x86_64
kernel rpm file), 10 MB of data (10*1024*1024),
$ l -Ggh zeros dv bin
-rw-r--r-- 1 10M Apr 7 15:30 bin
-rw-r--r-- 1 10M Apr 7 15:31 dv
-rw-r--r-- 1 10M Apr 7 15:31
On Fri, 06 Apr 2007 19:47:36 PDT, [EMAIL PROTECTED] said:
On Fri, 6 Apr 2007 11:21:19 -0400, Jan Harkes [EMAIL PROTECTED]
With compression there is a pretty high probability that one corrupted
byte or disk block will result in loss of a considerably larger amount
of data.
Bad blocks
On Thu, Apr 05, 2007 at 09:32:11PM -0700, [EMAIL PROTECTED] wrote:
Don't you agree, that If they are accurate, THEN they are obviously
very relevant.
Nope, if they are accurate and they have something to do with your
particular usage and applications, then they are relevant. But it
[EMAIL PROTECTED] writes:
I am quite sure that the kernel RPM file is *already* compressed, at least
somewhat.
Sure - that's the point - it's better to have the tool compress
data when it makes sense.
OTOH I think Reiser4 fs is not about transparent compression, it's
rather about the plugins
Lennart. Tell me again that these results from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are not of interest to you. I still don't understand why you have your
head in the sand.
.-.
|
On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] wrote:
Lennart. Tell me again that these results from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
Hmm, copying kernel sources around. Not that interesting.
On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] wrote:
To get a feel for the performance increases that can be achieved by
using compression, we look at the total time (in seconds) to run the
test:
You mean the performance increases of writing a file which is mostly
all zero's?
Teddy,
It is a pity you don't address the full set of results, when you make
your snide comments.
Now since you have them,... why don't you make reasoned comment about
them.
You can read more here:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
[EMAIL PROTECTED] writes:
Lennart. Tell me again that these results from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are not of interest to you. I still don't understand why you have your
head in the sand.
Oh,
On Fri, 6 Apr 2007 23:30:49 -0400, "Jan Harkes" <[EMAIL PROTECTED]>
said:
>
> Since you decide to publically respond to a private email, but not only
> you did not 'discuss' anything I wrote and in fact cut out most of the
> useful information in my reply I guess I will have to repeat my
>
Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.
Once I send out this email, I'll just add you to my friendly killfile
(as
On Fri, 6 Apr 2007 11:21:19 -0400, "Jan Harkes" <[EMAIL PROTECTED]>
said:
> Do you really have to repeat the results in every email you sent?
The following benchmarks are from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm or,
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
On Fri, 6 Apr 2007 11:21:19 -0400, Jan Harkes [EMAIL PROTECTED]
said:
Do you really have to repeat the results in every email you sent?
The following benchmarks are from
http://linuxhelp.150m.com/resources/fs-benchmarks.htm or,
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.
Once I send out this email, I'll just add you to my friendly killfile
(as
On Fri, 6 Apr 2007 23:30:49 -0400, Jan Harkes [EMAIL PROTECTED]
said:
Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.
On Thu, 05 Apr 2007 18:34:48 PDT, [EMAIL PROTECTED] said:
> If they are accurate, THEN they are obviously very relevant.
Erm. No. They're not "obviously" very relevant.
I could hypothetically create a benchmark, that's accurate and repeatable,
that shows that reiser4 is able to wash a herd
Hi Peter,
You say that the results may be accurate, but "Whether or not they're
*relevant* is a totally different ball of wax." and
"Whether or not they're relevant depends on how well they happen to
reflect your particular usage pattern."
Well, surprise, surprise,.. everyone knows that.
Have
[EMAIL PROTECTED] wrote:
Hi Peter,
You say that the results may be accurate, but not relevant.
NO, I said that whether they're accurate is another matter.
If they are accurate, THEN they are obviously very relevant.
Crap-o-la. Whether or not they're relevant depends on how well they
Hi Peter,
You say that the results may be accurate, but not relevant.
.-.
| FILESYSTEM | TIME |DISK |
| TYPE |(secs)|USAGE|
.-.
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
|REISER4 | 3462 | 692 |
|EXT2| 4092 | 816 |
[EMAIL PROTECTED] wrote:
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are accurate?
[EMAIL PROTECTED] wrote:
Anyway, I have patched the 2.6.20 kernel and have a partition formatted
with Reiser4.
However, I am having trouble getting LILO or GRUB working (with
Reiser4).
Could you guys who know all about this, help me, or point me to some
help.
Make your /boot a separate
Hi Ignatich,
After seeing the following benchmarks at
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
The Reiser4 benchmarks are so good, I have decided to try the Reiser4
filesystem.
.-.
|
Hi Ignatich,
After seeing the following benchmarks at
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
The Reiser4 benchmarks are so good, I have decided to try the Reiser4
filesystem.
.-.
|
[EMAIL PROTECTED] wrote:
Anyway, I have patched the 2.6.20 kernel and have a partition formatted
with Reiser4.
However, I am having trouble getting LILO or GRUB working (with
Reiser4).
Could you guys who know all about this, help me, or point me to some
help.
Make your /boot a separate
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are accurate?
[EMAIL PROTECTED] wrote:
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
Hi Peter,
You say that the results may be accurate, but not relevant.
.-.
| FILESYSTEM | TIME |DISK |
| TYPE |(secs)|USAGE|
.-.
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
|REISER4 | 3462 | 692 |
|EXT2| 4092 | 816 |
[EMAIL PROTECTED] wrote:
Hi Peter,
You say that the results may be accurate, but not relevant.
NO, I said that whether they're accurate is another matter.
If they are accurate, THEN they are obviously very relevant.
Crap-o-la. Whether or not they're relevant depends on how well they
Hi Peter,
You say that the results may be accurate, but Whether or not they're
*relevant* is a totally different ball of wax. and
Whether or not they're relevant depends on how well they happen to
reflect your particular usage pattern.
Well, surprise, surprise,.. everyone knows that.
Have a
On Thu, 05 Apr 2007 18:34:48 PDT, [EMAIL PROTECTED] said:
If they are accurate, THEN they are obviously very relevant.
Erm. No. They're not obviously very relevant.
I could hypothetically create a benchmark, that's accurate and repeatable,
that shows that reiser4 is able to wash a herd of
80 matches
Mail list logo
