Date: Mon, 5 Feb 2001 21:46:17 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
To: Terry Lambert <tlambert@primenet.com>
Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), gibbs@scsiguy.com (Justin T. Gibbs), bright@wintelcom.net (Alfred Perlstein), rjesup@wgate.com (Randell Jesup), mjacob@feral.com (Matthew Jacob), msmith@FreeBSD.ORG (Mike Smith), des@ofug.org (Dag-Erling Smorgrav), dnelson@emsphone.com (Dan Nelson), tanimura@r.dl.itc.u-tokyo.ac.jp (Seigo Tanimura), arch@FreeBSD.ORG
Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386)
Message-ID: <200102060546.f165kHq58398@earth.backplane.com>
References: <200102060248.TAA08217@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At risk of throwing yet another iron into coals.... The problem here is to try to give a 'hint' to the high level VFS/BIO and VM systems. The hint doesn't have to be correct, it just has to be close 'most of the time'. What this means is that we don't have to create massive infrastructure to get it exactly right. Something as simple as an alignment size covers a wide range of topologies, including all standard RAID topologies. We don't have to propogate information about actual seek boundries, or reassigned sectors, for example. We certainly do not have to propogate the information on-the-fly... we can get 95% of the way there at mount time, and that's good enough. We can also simply assume a reasonable rule for intermediate topologies such as CCD, VN, or a filesystem... we allow the intermediate layers to modify the parameters on their way up, and we assume they will do so prudently. And we can assume for the most part that contiguous blocks translate to contiguous blocks 'most of the time', even when reading and writing a file. (And I will note here that the clustering code is already aware of the most common case -- a logically contiguous file that is not necessarily physically contiguous, and the system does the right thing). I think the idea Poul originally articulated -- having simple information like recommended I/O size, recommended cluster size, and/or maximum I/O size, is the correct solution. Getting fancy might buy us a percent or two... it isn't worth the effort. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102060546.f165kHq58398>