lkml.org 
[lkml]   [2000]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: e2fs performance as function of block size


Alan Cox wrote:
>
> > Sirs,
> > performing extensive tests on linux platform performance, optimized as
> > database server, I got IMHO confusing results:
> > in particular e2fs initialized to use 1024 block/fragment size showed
> > significant I/O gains over 4096 block/fragment size, while I expected t=
> > he
> > opposite. I would appreciate some hints to understand this.
>
> It may be that your database is writing out 1K sized blocks on random
> boundaries. If so then the behaviour you describe would be quite reasonable.

Alan,

Perhaps, but I have reported this before and seen something similiar.
It's as though the disk drivers are optimized for this case (1024). I
get better performance running NWFS at 1024 block size vs. all the other
sizes, even with EXT2 configured to use 4096, etc. At first glance,
when I was changing block sizes, I did note that by default, EXT2 set to
1024 would mix buffer sizes in the buffer cache, which skewed caching
behavior, but there is clearly some optimization relative to this size
inherent in the design of Linux -- and it may be a pure accident. This
person may be mixing and matching block sizes in the buffer cache, which
would satisfy your explanation.

Jeff

>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:47    [W:0.062 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site