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/
This archive was generated by hypermail 2b29 : Thu Nov 23 2000 - 21:00:22 EST