Jump to content











Photo
- - - - -

ImDisk and UrBackup Server


  • Please log in to reply
3 replies to this topic

#1 uroni

uroni
  • Members
  • 2 posts
  •  
    Germany

Posted 01 January 2017 - 03:19 PM

Hi,

 

the latest UrBackup Server version uses ImDisk to mount VHD and compressed VHD files it previously backed up.

 

This works very well, so from me and the (future) users a big thank you!

 

Some potential issues and perhaps things that can be improved (but must not as it already works as is):

 

  • The UrBackup Server installers now bundle ImDisk. Please tell me if I should change something there, or if I should stop bundling it, specifically because it conflicts if the User installs/uninstalls ImDisk separately
  • Specifically bundling would be easier if it had a "proper" installer (like NSIS or MSI). If you need some help I would be glad to
  • It stops ImdiskSvc in order to service the user space named pipe itself. It would be better if there were more than one named pipe so ImdiskSvc can continue to run
  • I am passing the VHD(z) name as hostname, which works, but isn't as you intented probably ;). The ImDisk server code is here btw: https://github.com/u...n/ImdiskSrv.cpp

If you need help getting a new driver version attestation signed, I'd be able to do that.

 

Thanks!

 



#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1339 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 01 January 2017 - 04:33 PM

Hi,

Interesting project. I don't really follow why you need your own named pipe. If you really want to use a named pipe for the communication itself, you simply create a proxy type virtual disk but do not specify any proxy type like IP or serial port. The "file name" you pass to the ImDiskCreateDevice or similar function will then be the path to the pipe your service has created so that the ImDisk driver will contact your service instead of the ImDskSvc pipe.

But I would recommend you to use shared memory proxy method instead of pipes for local communication because pipes are generally quite inefficient for things like this.

Hopefully during 2017 I will be able to implement my new idea with a special communication device that could be directly opened from a user mode service and where the driver can detect when the user mode service exits for any reason. That will help implementations to be more robust and CPU efficient, but it will require some work so it will take a while.

#3 uroni

uroni
  • Members
  • 2 posts
  •  
    Germany

Posted 02 January 2017 - 02:28 PM

Thanks for telling me how it can be improved! I was using ImDiskSvc and devio as examples on how a user space program can implement the block device, so I ended up with the same structure.

 

If you are changing it to another method, I guess it would be best to wait for that now before changing it again.



#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1339 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 02 January 2017 - 04:11 PM

Thanks. But you could of course still implement the current shared memory method. That's the method I would say most proxy services for ImDisk use these days so that method will definitely not disappear even if I implement something else. You can look at the shared memory option in devio.exe source code how this is implemented. The ImDskSvc service is not needed at all with this method.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users