Jump to content











Photo
- - - - -

Proxy-mounted disks and FILE_FLAG_NO_BUFFERING writing

proxy file_flag_no_buffering

  • Please log in to reply
3 replies to this topic

#1 Victor Milovanov

Victor Milovanov

    Newbie

  • Members
  • 15 posts
  •  
    United States

Posted 24 June 2015 - 02:29 AM

Just double-checked, that it is not my code problem. I see it on both 1.8.x and 1.9.4.

When I mount something like this as a disk:

using (var stream = new MemoryStream(checked((int)size)))
using (var provider = new DevioProviderFromStream(stream, ownsStream: false))
using (var service = new DevioShmService(provider, OwnsProvider: false))
{
  service.StartServiceThreadAndMountImDisk(ImDiskFlags.Auto, mountPoint);
  wait for key...
}

Then format disk, and try to write to a file on it with FILE_FLAG_NO_BUFFERING option set (file already exists, and has non-zero size by the time I do that). It always fails, complaining about something like System.ArgumentException: Handle does not support synchronous operations, which deep inside appears to be unaligned access, just like in this topic: http://reboot.pro/to...ag_no_buffering

 

The same test with FILE_FLAG_NO_BUFFERING works perfectly on real disks, and ImDisk-mounted disks, mounted directly (e.g. not via proxy).

 

This problem appears on the very first write, where I try to write 1MiB of data at file offset 0, so I assume alignment should not be a problem.


Edited by Victor Milovanov, 24 June 2015 - 02:31 AM.


#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 25 June 2015 - 09:22 AM

I wonder what it could be that reports this error. I assume that it can't come from the proxy communication itself. There are only a few possible status values that can be returned in response to failures reported through the proxy communication. Then, there are not many system calls that could fail with status before the communication either, just a few memory copy instructions and similar. The only thing that I could think of would be if there is some memory copying that fails and raises an exception which is caught somewhere else and returned as an error status. That should be possible to catch with a kernel debugger.

 

One thing you could try, is to use TCP/IP communication instead of shared memory communication. (Create an object of class DevioTcpService instead of DevioShmService.) Does it work if you do that? If so, we could focus on the proxy communication itself.



#3 Victor Milovanov

Victor Milovanov

    Newbie

  • Members
  • 15 posts
  •  
    United States

Posted 08 July 2015 - 04:16 AM

Hm, I tried to do

new DevioTcpService(new IPAddress(new byte[] { 127, 0, 0, 1 }), 4823, provider, OwnsProvider: false);

But then it fails on

 

StartServiceThreadAndMountImDisk:

 

Setting up listener at 127.0.0.1:4823
Raising service ready event.
Unhandled exception in service thread: System.Net.Sockets.SocketException (0x80004005): A blocking operation was interru
pted by a call to WSACancelBlockingCall
   at System.Net.Sockets.Socket.Accept()
   at System.Net.Sockets.TcpListener.AcceptSocket()
   at LTR.IO.ImDisk.Devio.Server.Services.DevioTcpService.RunService() in Z:\Kod\imdisk\ImDiskNet\DevioNet\Server\Servic
es\DevioTcpService.vb:line 80
 
Unhandled Exception: System.ComponentModel.Win32Exception: The remote computer refused the network connection
   at LTR.IO.ImDisk.Devio.Server.Services.DevioServiceBase.StartServiceThreadAndMountImDisk(ImDiskFlags Flags, String Mo
untPoint) in Z:\Kod\imdisk\ImDiskNet\DevioNet\Server\Services\DevioServiceBase.vb:line 288
   at ...
 
I explicitly opened port 4823 through Windows Firewall with Advanced Security, but that does not change anything.
 
I use ImDisk Net 1.0.7 and Devio Net 1.0.6

Edited by Victor Milovanov, 08 July 2015 - 04:31 AM.


#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 11 July 2015 - 03:41 PM

Just as a kind of recommendation, don't build your own IPAdress objects for things like 127.0.0.1, 255.255.255.255 and similar. Use the .NET provided values instead. I also see no reason for passing "false" as "OwnsProvider" parameter. I recommend:

new DevioTcpService(IPAddress.Loopback, 4823, provider, OwnsProvider: true);

Then, I guess your actual problem likely has something to do with firewalls anyway. At least I don't see any obvious reason why it would fail in this way otherwise.







Also tagged with one or more of these keywords: proxy, file_flag_no_buffering

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users