Date: Sat, 14 Nov 2020 22:50:10 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, Scott Long <scottl@samsco.org>, Alexander Motin <mav@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: MAXPHYS bump for FreeBSD 13 Message-ID: <15969.1605394210@critter.freebsd.dk> In-Reply-To: <X7BSrM9bCna33ks4@kib.kiev.ua> References: <aac44f21-3a6d-c697-bb52-1a669b11aa3b@FreeBSD.org> <X7Aj0a6ZtIQfBscC@kib.kiev.ua> <634E35E9-9E2B-40CE-9C70-BB130BD9D614@samsco.org> <X7AzRMZ5FSRpzXqo@kib.kiev.ua> <CANCZdfroqvHhwBxhbB1SqcZgM6o_pcAFxWqPQ3Y4Z%2BZqd1FCTA@mail.gmail.com> <X7BSrM9bCna33ks4@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- Konstantin Belousov writes: > DFLTPHYS seems to be only used by drivers (and some geoms), and typical > driver' usage of it is to clamp the max io request more than MAXPHYS. > I see that dump code tries to not write more than DFLTPHYS one time, to > ease life of drivers, and physio() sanitize maxio at DFLTPHYS, but this > is for really broken drivers. DFLTPHYS is the antique version of g_provider->stripesize, and should be replaced by it throughout. The history behind DFLTPHYS is that tape-drives were limited to MAXPHYS sized tape-blocks, so you wanted it large. For performance reasons disk operations should not span cylinders, a topic I'm sure Kirk can elaborate on if provoked, so DFLTPHYS was reduce them to a tunable size. Peak performance was when fs-blocks divided DFLTPHYS and DFLTPHYS divided the cylinder of the disk. Seagate ST82500[1] with standard formatting had 0x616 sectors per cylinder, (19 heads, 82 sectors each). Formatting with a generous 22 spare sectors per cylinder brought the "usable" cylindersize down to precisly 0x600 sectors, which resulted in around 5-10% higher overall system performance on a heavily loaded Tahoe. Poul-Henning [1] The STI82500 "Sabre" is amusingly available for order in certain web-shops but, alas, "not currently in stock". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15969.1605394210>