OSFMount - wait to finish mouting a virtual disk in a batch file

[mrelements]

I use the OSFMount in a batch file and need to wait until mounting has finished.
Is there a way I can do this?

I also tried it from command line and when I tried id first, it looks like the call waited until mounting has finished, but when I did the unmounting/mounting a couple of times, the call to mount nearly immediately returned but it still took 10-20s until the mounting really has finished.

This is how my command looks like:

OSFMount.com -a -t vm -f C:\temp\testImage.img -o rw -m S:

Thanks for any help!

[Richard (PassMark)]

That shouldn't be the behavior as described. Did you check the return/exit code from OSFMount to make sure there wasn't an error during the process? Note however, the initial load of the image into the RAM is upon first read/write (not upon mount) to the device, so if it is a large image, then it can take some time transfer the file from the local drive into RAM. It is also possible that if you have open or pending operations to the drive that could possibly prevent OSFMount from cleanly dismounting the drive.

[mrelements]

Thank your for your reply.
Well there is not really a return code.
Here is what it looks like, when I mount the virtual disk from command line:

C:\Tools\OSFMount>OSFMount.com -a -t vm -f C:\temp\testImage.img -m S: -o rw
Creating device...
Created device 7: S: -> C:\temp\testImage.img
Notifying applications...
Done.

C:\Tools\OSFMount>

This whole statement takes around 5-10s, but the virtual disk is accessible after around 50s. The time is not the problem because the file to load is around 16GB.

What do you mean with first read/write? So does the behavior above sound correct to you?

And there shouldn't be any pending operations because I dismounted the virtual disk before I mounted it again, with the following command: OSFMount.com -D -m S:

Thanks for your help!

[Richard (PassMark)]

I couldn't reproduce the issue, at least with images ranging from 4-6 GB in size on a 16GB installed RAM system. We were able to access the disk right away after OSFMount returned control.

Can you try on a different machine?
Or try on a smaller image to see if there is any difference.

What do you mean with first read/write?

The image file is transferred into RAM upon first access to the disk and not actually during mount. However, it will usually seem seamless to the user as when OSFMount notifies the system of a new disk being added, there will be other system processes that will probably query information on the disk (e.g. for filesystem and size) that will provoke the first read.

[mrelements]

Thanks for the information!

I tried it on a different machine with 16GB installed RAM and a 7.5GB image, but still the same problem.
But when I try it with a 4GB image on the machine with 32GB installed RAM, then I can access the disk right after OSFMount returned, or maybe with a small gap < 1s.

So it looks like the problem is only noticeable with bigger image sizes.

The problem is, we really need a 16GB image size so unfortunately, OSFMount doesn't look like the right solution for us.
But thank's anyway for your help!

[David (PassMark)]

We are in the process of upgrading some of our machines to 32GB of RAM. Then we can do some additional testing with bigger RAM drives.

We are wondering if it might be a caching effect. From the point of view of OSFMount the operation might be complete. But the O/S is actually still running the task in the background from cache. Just speculation. We don't really know at this point. What type of disk was the testImage.img file stored on?

[Richard (PassMark)]

Upon further investigation, I'm pretty confident the issue is with what we thought it is. For the most part the bottleneck is the read speed for the drive the image is located on since the image needs to be loaded into RAM before being used. (To a lesser extent, there is some cache affects, i.e. the read and write operations are all queued up by the OS/system and control is returned to OSFMount while the operations are still in process). The delay time you are experiencing can be calculated by taking (Total Size of Image) / (Bytes Read / Sec of drive with the image). Some made up examples:

M2 NVMe SSD with 2500 MB/s Read Access, 16 GB / 2500 MB/s = ~6.4 seconds ...
SATA SSD with 600 MB/s Read Access,16 GB / 600 MB/s = ~26 seconds ...
HDD with 160 MB/s Read Access, 16 GB / 1610 MB/s = ~100 seconds ...

If you know what type of drive/model you have you can look up the read speeds for it. You can also verify this by opening Task Manager and locating the correct "System" process (sort by memory used) and looking at the Disk use for the same process while you run your "OSFMount.com ..." command.

-----------

The question is now do you really need the image in Memory, or more concern that you can read/write the image? If you don't care for the image to be in memory, you can use "-t file" option instead and OSFMount will mount the image and you should have "immediate" access to the new drive.

We'll look to see if we can optimize loading of the image back ram disk. There are probably a couple things that we can do that may shave a few percent off the time required, e.g bigger transfer buffer. In the future, we may look at partially loading the image or loading only parts of the image that are being accessed.

[mrelements]

Thanks a lot for your time used to investigate this case!

The file testImage.img was stored on a Samsung SSD 850 PRO 512GB harddisk.
The specs say, that the read speed is 550 MB/s, but when I check the Task Manager, it shows a speed around 420 MB/s, but this is of course my problem not yours

But thanks anyway for the detailed information! It's always good to understand what happens!

Yes, we do need the image in memory, because we do make changes to files on it but don't want them to be stored permanently.
And also even with a SSD harddisk, memory is always faster and this is also important to us.

OK, thanks a lot! Just to let you know, the time used to load the image into memory isn't really a big problem, but the main problem is still that we don't know when the image is completely loaded.
And about your future plans, this sounds quite promising!

Thank you!

[DanD]

I would suggest using the Local Computer Policy (gpedit.msc) > Computer Configuration > Windows Settings > Scripts (Startup / Shutdown). Place the script in the Startup > View files folder (%SYSTEMROOT%\System32\GroupPolicy\Machine\Scripts \Startup)