Date: Mon, 22 Mar 2010 13:49:28 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Scott Long <scottl@samsco.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, Alexander Motin <mav@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS Message-ID: <20100322134928.83045xnbh4nkqzok@webmail.leidinger.net> In-Reply-To: <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Scott Long <scottl@samsco.org> (from Sat, 20 Mar 2010 12:17:33 -0600):
> code was actually taking advantage of the larger I/O's. The
> improvement really
> depends on the workload, of course, and I wouldn't expect it to be noticeable
> for most people unless they're running something like a media server.
I don't think this is limited to media servers, think about situations
where you process a large amount of data seuqntially... (seuqntial
access case in a big data-warehouse scenario or a 3D render farm which
get's the huge amount of data from a shared resource ("how many
render-clients can I support at the same time with my disk
infrastructure"-scenario) or some of the bigtable/nosql stuff which
seems to be more and more popular at some sites). There are enough
situations where sequential file access is the key performance metric
so that I wouldn't say that only media servers depend upon large
sequential I/O's.
Bye,
Alexander.
--
That's life.
What's life?
A magazine.
How much does it cost?
Two-fifty.
I only have a dollar.
That's life.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100322134928.83045xnbh4nkqzok>