No announcement yet.

OSFmount: save|flush change content

  • Filter
  • Time
  • Show
Clear All
new posts

  • OSFmount: save|flush change content

    I want OSFmount to save the changed content of the RAM drive back to the disk's .img file. How can I do that from a script, w/o the GUI?

    Echo off

    :: Create RAM disk -a -t vm -m K: -o format:ntfs:"RAM Volume" -s 1G

    :: copy some files:
    xcopy %userprofile%\Desktop\*.* K:

    :: create .img file and save it to disk:
    echo Use the GUI-App to save the RAM disk to %userprofile%\desktop\RAMDISK.img and exit program ...

    :: dismount / flush -d -m K:
    :: Flushing file buffers... Where to?

    :: re-mount -a -m K: -f %userprofile%\desktop\RAMDISK.img -t vm -o rw

    :: make changes, delete files:
    del K:*.* /F /Q

    :: verify:
    Dir K:

    :: dismount / flush. IMHO THIS SHOULD FLUSH CHANGES TO .IMG ON DISK -d -m K:

    :: re-mount -a -m K: -f %userprofile%\desktop\RAMDISK.img -t vm -o rw

    :: verify. ALL FILES STILL THERE
    Dir K:

    :: Clean up -d -m K:
    del %userprofile%\Desktop\RAMDISK.img

    echo on

  • #2
    Can you just start with an blank/empty image file then pre-load it into the RAM drive?


    • #3
      Originally posted by David (PassMark) View Post
      Can you just start with an blank/empty image file then pre-load it into the RAM drive?
      Yes, I could start with a blank, newly created image file on server boot, then xcopy or robocopy all needed files from the HDD to the RAM drive, and write a shutdown script that copies everything back from RAM to HDD before re-boot or backup. My question is, if it is possible for OSFmount to flush changed files automatically directly into the image file on the HDD, thus updating it. Or at least upon -d dismounting it. I know this functionallity from 'Softperfect RAM disk', but I'd prefer to go with OSFmount.


      • #4
        If you mount a disk that is backed by an image file, then the changes are written back to the image file automatically (with some caching).

        I did a quick test on the speed difference.

        Pure ram drive (1GB, physical disk emulation, FAT32)
        Read: 3896 MB/sec
        Write: 2902 MB/sec
        IOPS32KQD20: 3240 MB/sec
        IOPS4KQD1: 667 MB/sec

        Image backed drive (1GB, physical disk emulation, FAT32, image backed to WD 512GB NVMe SSD)
        Read: 3442 MB/sec
        Write: 3180 MB/sec
        IOPS32KQD20: 3019 MB/sec
        IOPS4KQD1: 279 MB/sec

        And for comparison here are the speeds of the WD 512GB NVMe SSD
        Read: 4394 MB/sec
        Write: 3751 MB/sec
        IOPS32KQD20: 1878 MB/sec
        IOPS4KQD1: 95 MB/sec

        Results aren't entirely accurate due to some background activity and single sample. Volume based emulation is also faster than physical emulation.
        But the point is that you aren't giving up much performance by using a disk image and not a RAM drive. Are directly using a modern SSD can actually be faster than a RAM drive (depending on settings).

        The exception to this is when you are dealing with a large number of really small disk reads and writes from a single thread (the IOPS4KQD1 result). RAM drive is much quicker for this.

        If you are using a pure RAM drive then there is no automatic writing of the contents to a disk image from scripting (the graphical user interface does prompt the user for this however). If it was important enough for someone to cover the development cost, we could implement this.


        • #5
          Also just for fun I did the same benchmark run for a volume emulation.

          Pure ram drive (1GB, disk volume emulation, FAT32)
          Read: 8469 MB/sec
          Write: 4908 MB/sec
          IOPS32KQD20: 6048 MB/sec
          IOPS4KQD1: 1603 MB/sec

          So much quicker without the need to deal with the overhead of emulating a physical drive.