Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jul 1999 18:48:18 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        David Miller <dmiller@search.sparks.net>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: 650 MB MFS?
Message-ID:  <199907180148.SAA88154@apollo.backplane.com>
References:   <Pine.BSF.3.96.990717211935.23394C-100000@search.sparks.net>

next in thread | previous in thread | raw e-mail | index | archive | help
:
:I'm not sure what good that will do me.  The point of the exercise is to
:ensure that cdrecord never has to wait on enough seeks to create coasters.
:Putting it all in ram before starting should do this, but a different
:interface to the same data on disk doesn't.
:
:Unless I'm missing something, which is usually the case:)
:
:Thanks for the answers Matt!
:
:--- David

    MFS isn't very efficient - when you read the data it will be
    stored in memory twice.   This is because MFS's 'disk' is
    a process's VM space, which happens to be memory which is
    *different* memory then the VM cache.  So each page is stored
    in memory twice.

    If you have enough ram... say you have 1GB of ram, and you
    create a normal image file on disk, the system will be able
    to hold the entire contents of the file in the VM cache
    as a matter of course.

    This would be fairly easy to test.  Create the image file,
    then do a read pass on it:

	dd if=imagefile of=/dev/null bs=32k

    Then do another read pass on it while running 'iostat 1'.

	xterm1> iostat 1
	xterm2> dd if=imagefile of=/dev/null bs=32k

    If you don't get significant disk activity then the entire
    file has been cached in ram and you should be able to cdrecord
    it.

    You can test both mechanisms by running 'iostat 1' while
    trying each one.  Then use whichever one is better.

    If you don't have a gig of ram, MFS isn't going to help
    you since the pages will be forced out to swap and cause
    disk I/O to occur when they are brought back in.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


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?199907180148.SAA88154>