EldoS | Feel safer!

Software components for data protection, secure storage and transfer

CbFsGetVolumeSize Callback question

Posted: 10/15/2009 12:18:47
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

In the GetVolumeSize callback there are four parameters that are sent back to the driver from the callback. They are;
__int64* TotalAllocationUnits,
__int64* AvailableAllocationUnits,
PDWORD SectorsPerAllocationUnit,
PDWORD BytesPerSector
Are there any limits on the size of these variables besides the natural limits imposed by the size of the variable itself?
For example, BytesPerSector is a pointer to a DWORD variable which in C++ is an unsigned 32 bit integer, so it should be able to take on values between 0 and 4294967295 (2 to the 32nd minus 1). I seem to be running into a problem when I pass back a BytesPerSector value of 1000000. Has anybody ever encountered such a problem?
Posted: 10/15/2009 12:37:08
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I tried some different values and it seems like anything over 4096 in the BytesPerSector value causes some sort of problem. Values under 4096 seem to work. Any thoughts on this?
Posted: 10/15/2009 14:16:25
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

In my code, when the block size that my system returns to me is bigger than 4096, I adjust the values that I am returning to the driver so that the block size is 4096 and the Available Allocation Units and the Total Allocation Units are the appropriate number of 4096 byte blocks. This seems to solve all the problems I was having and seems logical to me. If any of you see some potential gotcha! that I am missing please let me know.
Posted: 10/16/2009 01:15:35
by Eugene Mayevski (Team)

Page size is usually a multiple of 512. 8192 bytes per sector should also work for you as this is the size used by CD ROMs.

Sincerely yours
Eugene Mayevski
Posted: 10/16/2009 01:27:33
by Volodymyr Zinin (Team)

Hello Sid,

The CallbackFS driver doesn't allow to return any erroneous data. In this case it finishes the "get volume size" request with error. So you need always to return a correct data from this callback in order you FS works properly.
Here the checks the driver does after the GetVolumeSize callback has been called:
if (!(SizeInfo.BytesPerSector > 0 &&
      SizeInfo.BytesPerSector % CBFS_SECTOR_ALIGNMENT == 0 &&
      SizeInfo.BytesPerSector <= CBFS_MAX_SECTOR_SIZE &&
      SizeInfo.SectorsPerAllocationUnit > 0 &&
      SizeInfo.SectorsPerAllocationUnit <= CBFS_MAX_SECTORS_PER_ALLOCATION_UNIT &&
     SizeInfo.TotalAllocationUnits.QuadPart >= SizeInfo.AvailableAllocationUnits.QuadPart &&
     CbFsMaxLarge.QuadPart / SizeInfo.SectorsPerAllocationUnit / SizeInfo.BytesPerSector >= SizeInfo.TotalAllocationUnits.QuadPart)) {

Posted: 10/16/2009 10:46:43
by Kurt Griffiths (Standard support level)
Joined: 12/08/2008
Posts: 34

Is there any benefit to using large sector and/or sectors-per-allocation-unit values? What are the recommended values?
Posted: 10/17/2009 02:54:35
by Volodymyr Zinin (Team)

Perhaps some programs optimize their I/O by checking storage parameters, so you can specify some truthful parameters that represent the underlying storage used from your callbacks. But because there are a lot of "real" (not virtual) storages now that don't have "obvious" storage structure (RAID, etc) maybe storage parameters are not taken into account at all.
Posted: 10/26/2009 17:31:52
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Sorry to take so long to get back to you.

Vladimir your comment about erroneous information doesn't really apply because the information I send back is known only to my system. These files are "virtual files" that exist in reality in my database and nowhere on any real device that Windows knows about, so CBFS or Windows cannot be doing any error checking against some entity that they know about because they don't know about my files. The only error check they could possibly be doing would be some sort of "sanity" check and that is apparently what was happening when I passed back numbers that weren't the right multiples.

Anyway, I'm satisified with the way I have things working now.



Topic viewed 2829 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!