On Sat, Apr 14, 2001 at 09:34:26AM -0500, Matthew D. Fuller wrote:
> On Thu, Apr 12, 2001 at 02:24:36PM -0700, a little birdie told me
> that Matt Dillon remarked
> > 
> >     Without vmiodirenable turned on, any directory exceeding
> >     vfs.maxmallocbufspace becomes extremely expensive to work with
> >     O(N * diskIO).  With vmiodirenable turned on huge directories
> >     are O(N), but have a better chance of being in the VM page cache
> >     so cost proportionally less even though they don't do any
> >     better on a relative scale.
> 
> Speaking of vmiodirenable, what are the issues with it that it's not
> enabled by default?  ISTR that it's been in a while, and most people
> pointed at it have reported success with it, and it seems to have solved
> problems here and there for a number of people.  What's keeping it from
> the general case?

Attached is a message from Matt Dillon from an earlier -hackers discussion.

G'luck,
Peter

-- 
The rest of this sentence is written in Thailand, on

>From [EMAIL PROTECTED] Fri Mar 23 02:15:39 2001
Date: Thu, 22 Mar 2001 16:14:11 -0800 (PST)
From: Matt Dillon <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
To: "Michael C . Wu" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: tuning a VERY heavily (30.0) loaded s cerver


:(Why is vfs.vmiodirenable=1 not enabled by default?)
:

    The only reason it isn't enabled by default is some unresolved
    filesystem corruption that occurs very rarely (with or without
    it) that Kirk and I are still trying to nail down.  I want to get
    that figured out first.

    It is true that some people have brought up memory use issues, but
    I don't consider memory use to really be that much of an issue.  This is
    a cache, after all, so the blocks can be reused at just about
    any time.  And directory blocks do not get cached
    well at all with vmiodirenable turned off.  So the net result
    should be an increase in performance even on low-memory boxes.

                                        -Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to