Bug 27599

sec@ice.42.org writes:
> --- /usr/export/src/share/man/man4/md.4	Sun Dec 31 03:11:56 2000
> +++ ./md.4	Thu May 24 00:56:57 2001
> @@ -59,6 +59,11 @@
>  with the kernel option
>  .Dv MD_NSECT .
>  .Pp
> +Be warned that due to kernel constraints such a
> +.Nm
> +disk cannot be bigger than a certain maximum size.
> +This size can be found in the 'Limit' column of 'vmstat -m'.
> +.Pp

It looks to me like the man page already states this:

     The default maximum size of a md disk backed by malloc(9) is 20,000 sec-
     tors of 512 bytes each.  This can be changed with the kernel option
     MD_NSECT.

Perhaps it might make sense to mention vmstat(8), but I don't think
it's appropriate to add another paragraph, most of which just repeats
what has already been said.

					Dima Dorfman
					dima@unixfreak.org


>  At boot time the
>  .Nm
>  driver will search for pre-loaded modules of type
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-doc" in the body of the message
>

On Wed, May 23, 2001 at 08:57:23PM -0700, Dima Dorfman wrote:
> sec@ice.42.org writes:
> > --- /usr/export/src/share/man/man4/md.4	Sun Dec 31 03:11:56 2000
> > +++ ./md.4	Thu May 24 00:56:57 2001
> > @@ -59,6 +59,11 @@
> >  with the kernel option
> >  .Dv MD_NSECT .
> >  .Pp
> > +Be warned that due to kernel constraints such a
> > +.Nm
> > +disk cannot be bigger than a certain maximum size.
> > +This size can be found in the 'Limit' column of 'vmstat -m'.
> > +.Pp
> 
> It looks to me like the man page already states this:
> 
>      The default maximum size of a md disk backed by malloc(9) is 20,000 sec-
>      tors of 512 bytes each.  This can be changed with the kernel option
>      MD_NSECT.
> 
> Perhaps it might make sense to mention vmstat(8), but I don't think
> it's appropriate to add another paragraph, most of which just repeats
> what has already been said.

I'm sorry, but you misunderstand. The problem I mention has nothing to
do with MD_NSECT. You can raise MD_NSECT all the way, but the mentioned
'Limit' column of 'vmstat -m' Is unaffected by that. That is exactly
where this comes from. The default MD_NSECT is small enough to avoid any
problems, but when you increase it, you run into that other, not yet
documented limit which will HANG your machine.
If my english isn't clear enough, feel free to improve it. But please
add a warning to the manpage.

CU,
    Sec
-- 
There are too many priorities. One has to prioritize priorities. -- Wietse

Stefan `Sec` Zehl <sec@42.org> writes:
> On Wed, May 23, 2001 at 08:57:23PM -0700, Dima Dorfman wrote:
> > sec@ice.42.org writes:
> > > --- /usr/export/src/share/man/man4/md.4	Sun Dec 31 03:11:56 2000
> > > +++ ./md.4	Thu May 24 00:56:57 2001
> > > @@ -59,6 +59,11 @@
> > >  with the kernel option
> > >  .Dv MD_NSECT .
> > >  .Pp
> > > +Be warned that due to kernel constraints such a
> > > +.Nm
> > > +disk cannot be bigger than a certain maximum size.
> > > +This size can be found in the 'Limit' column of 'vmstat -m'.
> > > +.Pp
> > 
> > It looks to me like the man page already states this:
> > 
> >      The default maximum size of a md disk backed by malloc(9) is 20,000 se
> c-
> >      tors of 512 bytes each.  This can be changed with the kernel option
> >      MD_NSECT.
> > 
> > Perhaps it might make sense to mention vmstat(8), but I don't think
> > it's appropriate to add another paragraph, most of which just repeats
> > what has already been said.
> 
> I'm sorry, but you misunderstand. The problem I mention has nothing to
> do with MD_NSECT. You can raise MD_NSECT all the way, but the mentioned
> 'Limit' column of 'vmstat -m' Is unaffected by that. That is exactly
> where this comes from. The default MD_NSECT is small enough to avoid any
> problems, but when you increase it, you run into that other, not yet
> documented limit which will HANG your machine.
> If my english isn't clear enough, feel free to improve it. But please
> add a warning to the manpage.

Okay, I did misunderstand.  But it still says what you want:

     The malloc(9) backed disks are severely limited in size by constraints
     imposed by malloc(9).  The limit imposed depends on the amount of physi-
     cal RAM in the machine, and covers all malloc(9) backed instances of md
     devices.

but perhaps that could do with some elaboraton.  How about this:

     The malloc(9) backed disks are severely limited in size by constraints
     imposed by malloc(9).  Specifically, only one malloc bucket s used, which
     means that all md devices with malloc(9) backing must share the malloc
     per-bucket quota.  The exact size of this quota varies, in particuar with
     the amount of RAM in the system.  The exact value can be determined with
     vmstat(8).


> 
> CU,
>     Sec
> -- 
> There are too many priorities. One has to prioritize priorities. -- Wietse
>

On Sat, Jun 16, 2001 at 03:52:52PM -0700, Dima Dorfman wrote:
> Okay, I did misunderstand.  But it still says what you want:
> 
>      The malloc(9) backed disks are severely limited in size by constraints
>      imposed by malloc(9).  The limit imposed depends on the amount of physi-
>      cal RAM in the machine, and covers all malloc(9) backed instances of md
>      devices.
> 
> but perhaps that could do with some elaboraton.  How about this:
> 
>      The malloc(9) backed disks are severely limited in size by constraints
>      imposed by malloc(9).  Specifically, only one malloc bucket s used, which
>      means that all md devices with malloc(9) backing must share the malloc
>      per-bucket quota.  The exact size of this quota varies, in particuar with
>      the amount of RAM in the system.  The exact value can be determined with
>      vmstat(8).

Yes, that sounds much better, thanks. Maybe alter the last sentence to
"The exact value can be determined from the 'Limit' column of vmstat(8)"

But you don't have to. Your suggestion would be fine for me, too.

CU,
    Sec
-- 
I think the IDE issue is a good point.  People with IDE hardware in
their machines should be punished by making them wait to boot...
                                               -- terry@lambert.org

Comment 5 dd 2001-06-18 23:00:38 UTC

State Changed
From-To: open->closed

Committed, thanks!