Date: Sun, 21 Mar 2010 19:03:56 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS Message-ID: <4BA6517C.3050509@FreeBSD.org> In-Reply-To: <39C5864C-8A6B-4137-8743-D7B9F30F5939@samsco.org> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <39C5864C-8A6B-4137-8743-D7B9F30F5939@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > On Mar 20, 2010, at 1:26 PM, Alexander Motin wrote: >> As you should remember, we have made it in such way, that all unchecked >> drivers keep using DFLTPHYS, which is not going to be changed ever. So >> there is no problem. I would more worry about non-CAM storages and above >> stuff, like some rare GEOM classes. > > And that's why I say that everything needs to be audited. Are there CAM drivers > that default to being silent on cpi->maxio, but still look at DFLTPHYS and MAXPHYS? If some (most of) drivers silent on cpi->maxio - they will be limited by safe level of DFLTPHYS, which should not be changed ever. There should be no problem. > Are there non-CAM drivers that look at MAXPHYS, or that silently assume that > MAXPHYS will never be more than 128k? That is a question. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BA6517C.3050509>