:So, Matt, any comments?
:On  7 Jun, Poul-Henning Kamp wrote:
:> In message <[EMAIL PROTECTED]>,
:>      Mikhail Teterin writes:
:> The swap backing in  md(4) is a straight copy of  the code which lived
:> in vn(4). I'm not terribly familiar with that code, but I would expect
:> that it would work with no swap space as well.
:> Your man is probably Matt Dillon...
:       -mi

    You can create an MD partition with wired memory - no swap backing
    at all, if you want.  Obviously you can make such a partition as 
    large as you might otherwise want to make it.


    The swap-backed VN device did not cache the data in memory per-say,
    it simply treated the swap device as the backing device for the data.
    So in that respect MD works the same as VN when used with swap backing

    I think it is possible to get an effect similar to MFS in regards to
    trying to keep as much in ram as possible.  We would have to turn off
    write_behind for the specific MD case (not too hard, clustering is
    already controlled by the backing device so we just need to add a flag
    for write_behind), we would have to make MAP_NOSYNC the default for
    mmap'd data (for such devices), turn on softupdates, and we might also
    want to make write() release the buffer (leaving the pages in the
    VM PAGE cache) rather then writing it out... though that would be a
    lot more work.


    There are a few things you can do right now as a temporary workaround.
    It isn't perfect... the data eventually gets written out, but the
    writes will be rather severely decoupled.

        * turn off write_behind (this is a global setting unfortunately)

            sysctl -w vfs.write_behind=0

        * Create the MD/VN filesystem.  Either turn on softupdates or
          mount it async.

        * Turn on vmiodirenable

            sysctl -w vfs.vmiodirenable=1

    Note that the performance one saw with MFS was mainly due to MFS
    trying to cache everything in ram - to the detriment of other resources
    in the system and also to safety (the MFS filesystem would be 
    completely lost in a crash).  I know people who used MFS filesystems
    as mail queues but I would never do that sort of thing myself.


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

Reply via email to