:
: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
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
