Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Dec 1999 11:07:46 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Zhihui Zhang <zzhang@cs.binghamton.edu>
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG
Subject:   Re: Why VMIO directory is a bad idea?
Message-ID:  <199912101907.LAA59861@apollo.backplane.com>
References:   <Pine.GSO.3.96.991210084142.9306A-100000@sol.cs.binghamton.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
:(1) If the directory file is less than one page, there will be a waste of
:memory due to internal fragmentation.  Why do not we set a limit, say one
:page, on when we start VMIO a directory? 

    It is true that when we use VMIO to back directories that a minimum of
    one page of memory is used even for a small directory.  However, unlike
    B_MALLOC space in the buffer cache the VM page cache is much better
    suited towards figuring out when cached VM pages can be reused.  So
    even though there is waste the page may still be reused by the system 
    fairly quickly if need be.   When we use B_MALLOC space in the buffer
    to store a small directory 'efficiently', it tends to get reused too
    quickly due to the small size of the buffer cache which results in
    another physical I/O the next time the directory needs to be accessed.

    Given the choice being some wasteage (which is less then you think)
    and having to do another physical I/O, it is clear that the advantage
    is to keep the waste and avoid the physical I/O.

:(2) If VMIO directory is not desirable for some reasons, how about bump up
:the usecount of the buffer used by a directory file to let it stay in the
:queue longer?

    This is how the old algorithm worked.  It failed utterly to address
    the problem and in fact led to a considerable amount of complexity and
    wasted cpu cycles when the buffer cache became unbalanced (due
    to excessive write loading or directory scanning loading). 

:(3) Or maybe we can add a parameter to the filesytem, telling it to try to
:preallocate some contiguous disk space for all directory files. I guess
:that the cost per bit on disk is less than the cost per bit in memory.

    I believe the filesystem already does this.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:Can anyone give me an idea on how big a directory could be in some
:environment?
:
:Any comments or ideas are appreciated.
:
:-Zhihui


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912101907.LAA59861>