ext3 again takes the slowest performing title overall as expected...in
fact it appears not much as changed fs vs fs wise since Bruce Guenter's
tests. But I am surprised at the overall performance regressions in
comparison to 2.6.5/6 kernels with regards to deliveries vs amount of
writers.
Heitor A.M. Cardozo wrote:
Christopher Chan wrote:
Heitor A. M. Cardozo wrote:
Christopher Chan wrote:
Heitor A. M. Cardozo wrote:
Hi,
A draft with results of my benchmark based on fsbench is available
in http://www.htiweb.inf.br/benchmark/fsbench.htm.
The methodology and the conclusion
On Tue, 4 Dec 2007, Christopher Chan wrote:
ext3 again takes the slowest performing title overall as expected...in
fact it appears not much as changed fs vs fs wise since Bruce Guenter's
tests. But I am surprised at the overall performance regressions in
comparison to 2.6.5/6 kernels with
that last sentence should have been 'cannot beat'
I can believe it. Linux SW RAID is _VERY_ fast. The advantage of 3ware
HW RAID is in its convienence and robustness when Bad Things (tm)
happen, not its performance, in my experience.
I have used both 3ware, linux software raid and others.
Christopher Chan wrote:
ext3 again takes the slowest performing title overall as expected...in
fact it appears not much as changed fs vs fs wise since Bruce
Guenter's tests.
I agree but the values are more acceptable in comparision with others
filesystems. On Bruce tests it shows a very bad
Heitor A.M. Cardozo wrote:
Christopher Chan wrote:
ext3 again takes the slowest performing title overall as expected...in
fact it appears not much as changed fs vs fs wise since Bruce
Guenter's tests.
I agree but the values are more acceptable in comparision with others
filesystems. On
Mensagem original
Assunto: Re:[CentOS] Filesystem for Maildir
De: Christopher Chan [EMAIL PROTECTED]
Para: CentOS mailing list centos@centos.org
Data: terça-feira, 04 de dezembro de 2007 12:06:43
Heitor A.M. Cardozo wrote:
Christopher Chan wrote:
ext3 again takes
Here they are: The reader/writer times are in milliseconds and they are
the amount of time needed to read/write one message.
jfs filesystem results:
Reader time Writer time Deliveries per
second
No. of writers: one 0.058 6.339 157.754
ext3 again takes the slowest performing title overall as
expected...in fact it appears not much as changed fs vs fs wise
since Bruce Guenter's tests.
I agree but the values are more acceptable in comparision with
others filesystems. On Bruce tests it shows a very bad performance
for
Christopher Chan wrote:
Heitor A. M. Cardozo wrote:
Christopher Chan wrote:
Heitor A. M. Cardozo wrote:
Hi,
A draft with results of my benchmark based on fsbench is available
in http://www.htiweb.inf.br/benchmark/fsbench.htm.
The methodology and the conclusion i will publish later,
Heitor A. M. Cardozo wrote:
Hi,
A draft with results of my benchmark based on fsbench is available in
http://www.htiweb.inf.br/benchmark/fsbench.htm.
The methodology and the conclusion i will publish later, however, it
shows that the XFS obtained better performance and EXT3 had results that
Christopher Chan wrote:
Heitor A. M. Cardozo wrote:
Hi,
A draft with results of my benchmark based on fsbench is available in
http://www.htiweb.inf.br/benchmark/fsbench.htm.
The methodology and the conclusion i will publish later, however, it
shows that the XFS obtained better performance
Heitor A. M. Cardozo wrote:
Christopher Chan wrote:
Heitor A. M. Cardozo wrote:
Hi,
A draft with results of my benchmark based on fsbench is available in
http://www.htiweb.inf.br/benchmark/fsbench.htm.
The methodology and the conclusion i will publish later, however, it
shows that the XFS
Hi,
A draft with results of my benchmark based on fsbench is available in
http://www.htiweb.inf.br/benchmark/fsbench.htm.
The methodology and the conclusion i will publish later, however, it
shows that the XFS obtained better performance and EXT3 had results that
can now compete in this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Nov 28, 2007 at 08:51:25AM -0800, Bill Campbell wrote:
We haven't had any notable performance problems using this at a regional
ISP customer's site with about 10,000 e-mail users and several machines in
a cluster delivering mail to Maildir
On Thu, Nov 29, 2007, Rodrigo Barbosa wrote:
On Wed, Nov 28, 2007 at 08:51:25AM -0800, Bill Campbell wrote:
We haven't had any notable performance problems using this at a regional
ISP customer's site with about 10,000 e-mail users and several machines in
a cluster delivering mail to Maildir
On Fri, Nov 30, 2007, Christopher Chan wrote:
Bill Campbell wrote:
On Thu, Nov 29, 2007, Rodrigo Barbosa wrote:
On Wed, Nov 28, 2007 at 08:51:25AM -0800, Bill Campbell wrote:
We haven't had any notable performance problems using this at a regional
ISP customer's site with about 10,000 e-mail users
Bill Campbell wrote:
On Thu, Nov 29, 2007, Rodrigo Barbosa wrote:
On Wed, Nov 28, 2007 at 08:51:25AM -0800, Bill Campbell wrote:
We haven't had any notable performance problems using this at a regional
ISP customer's site with about 10,000 e-mail users and several machines in
a cluster
Very. We have a single Linux box facing the Internet which
runs everything through postfix, amavisd, and clamav to weed out
the phishing and worms that attack the Microsoft virus, Windows,
then hands off messages that pass to the internal cluster using
round-robin DNS as the poor-mans load
Christopher Chan wrote:
Heitor Augusto M Cardozo wrote:
Christopher Chan wrote:
Heitor Augusto M Cardozo wrote:
Hi all,
In last year, i had made some research and benchmarks based on
CentOS 4 to know which filesystem is better for Maildir: ReiserFS,
XFS or EXT3.
My conclusion was as
What does fsbench say? It has the best writing performance too?!?
No, according to the fsbench results, ReiserFS wins on Read Performance,
but XFS is, approximately, four times more faster on write.
I said that the ReiserFS have the best performance based on my
read/write server statics,
On Wed, Nov 28, 2007, Christopher Chan wrote:
What does fsbench say? It has the best writing performance too?!?
No, according to the fsbench results, ReiserFS wins on Read Performance,
but XFS is, approximately, four times more faster on write.
I said that the ReiserFS have the best
Bill Campbell wrote:
On Wed, Nov 28, 2007, Christopher Chan wrote:
What does fsbench say? It has the best writing performance too?!?
No, according to the fsbench results, ReiserFS wins on Read Performance,
but XFS is, approximately, four times more faster on write.
I said that the ReiserFS
Heitor Augusto M Cardozo napsal(a):
Yes, the BBU is installed and write_cache is enable. I will test JFS to
compare.
Could you share the results then?
Thanks,
David
___
CentOS mailing list
CentOS@centos.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Nov 27, 2007 at 11:28:58AM -0200, Heitor Augusto M Cardozo wrote:
- EXT3: reliable but very slow to read many small files.
- ReiserFS: best performance but unreliable and bad recovery tools.
- XFS: My choice, good performance and
Heitor Augusto M Cardozo wrote:
Christopher Chan wrote:
Heitor Augusto M Cardozo wrote:
Hi all,
In last year, i had made some research and benchmarks based on CentOS
4 to know which filesystem is better for Maildir: ReiserFS, XFS or
EXT3.
My conclusion was as follows:
- EXT3: reliable
On CentOS 5.0, a had the same benchmarks and now, EXT3 and XFS seems
to had better or equivalent performance on Read and Create Random
files. One of this tests, using bonnie++, show this:
# bonnie++ -d /mnt/sdc1/testfile -s 8192 -m `hostname` -n
50:15:5000:1000
bonnie++? Not
We use ext3 for maildir. I have not had any issues to date. This is
also on fibre SAN drives, not ATA.
On Nov 26, 2007, at 12:22 PM, Heitor Augusto M Cardozo wrote:
Hi all,
In last year, i had made some research and benchmarks based on
CentOS 4 to know which filesystem is better for
Heitor Augusto M Cardozo wrote:
Hi all,
In last year, i had made some research and benchmarks based on CentOS 4
to know which filesystem is better for Maildir: ReiserFS, XFS or EXT3.
My conclusion was as follows:
- EXT3: reliable but very slow to read many small files.
- ReiserFS: best
29 matches
Mail list logo