OS/2, eCS & ArcaOS - Technical > Programming

DosDevIOCtl API references?

(1/3) > >>

Dariusz Piatkowski:
Can someone point me to good references with whatever sample code one can find on the subject of DosDevIOCtl API?

I have the DEV Toolkit stuff here, along with a few OS/2 DEV books, but really they all seem to just re-hash what's in the Toolkit docs, which isn't much.

I am specifically asking because of the following: modifying DISKIO has allowed for greater range of device coverage (as far as the bigger numbers that newer devices provided and the various overflow issues the older version of DISKIO had). However, all that is predicated on the 512 byte sector size, and that was fine in the case of the old spinning drives.

The SSDs for the most part require a 4K sized sector. Not that they will NOT run with different setups, but due to the memory sizes 4K is the preferred option.

So here is the thing: attempting to re-define DISKIO code to deal with 4K sector sizes eventually produces a RC=87 from DosDevIOCtl, which means: "87_ERROR_INVALID_PARAMETER"...great!!!, but what does that mean??? LOL

I'm seeing this failure only in the Bus/Cache testing code and I think I understand why, but I haven't fully grasped it all.

Anyways, tossing the 4k setups in place causes the RC=87 failure which I'm trying to understand the reason for.


Dave Yeo:
Didn't large sectors on DVD's need a filter? And does OS/2 see those sectors as 4k?

Dariusz Piatkowski:
No idea Dave, but I do see code in DISKIO that uses static sector size values for CD testing specifically.

For example this is called to get CD sizing:

--- Code: ---...
   rc = DosDevIOCtl(handle, 0x82, 0x60, NULL, 0, NULL, (PVOID)&cdinfo, sizeof(cdinfo), &datasize);

--- End code ---

DosDevIOCtl (DevHandle,           /* Handle to device */
                   ulCategory,          /* Category of request */
                   ulFunction,          /* Function being requested */
                   uchParms,            /* Input/Output parameter list */
                   sizeof(uchParms),    /* Maximum output parameter size */
                   &ulParmLen,          /* Input:  size of parameter list */
                                        /* Output: size of parameters returned */
                   uchDataArea,         /* Input/Output data area */
                   sizeof(uchDataArea), /* Maximum output data size */
                   &ulDataLen);         /* Input:  size of input data area */
                                        /* Output: size of data returned   */

0x82 - therefore is 'Category of request', and 0x60 is 'Function being requested', but where can I find what these actually mean?

Basically, what I want to understand is how to change DISKIO logic to dynamically determine these values during execution so that HDDs and SSDs can be correctly tested.

I am focusing on sector size b/c the values used right now are all static.

Now, it may be that the answer is in asking perhaps a different question altogether: why didn't we use something like DosQueryFSInfo API to dynamically figure this out?

If I look at the API details the return data structure spells this out...and so why not use that information to then dynamically build the matching logic for performance testing various sector sized devices?

Here is the pertinent detail on the File-system device allocation data structure:

--- Code: ---typedef struct _FSALLOCATE {
  ULONG      idFileSystem;  /*  File system identification. */
  ULONG      cSectorUnit;   /*  Number of sectors per allocation unit. */
  ULONG      cUnit;         /*  Number of allocation units. */
  ULONG      cUnitAvail;    /*  Number of allocation units available. */
  USHORT     cbSector;      /*  Number of bytes per sector. */

--- End code ---

Dave Yeo:
I'm pretty sure for hard drives, we're stuck with 512 byte sectors. For example, on the testers list there was the recent thread "AHCI and USB 4TB Disk support" where someone had used XP and some driver to format a USB 4TB disk with FAT32. He found XP was fine with it. His NAS read it fine but the first write screwed it up. Investigation showed it used 4096 byte sectors, with the XP driver, and it was not supported by OS/2.
If we could use 4096 byte sectors, the CHS limit would be 16TB instead of 2TB and someone would have implemented it.
CD's and DVD's are a different kettle of fish and someone did mention needing a flt driver to handle the 4096 byte sectors.
The AHCI driver also has a switch, /4, for use with disks etc that are internally 4096 byte sectors, it forces the geometry to align the sectors correctly so JFS 4096 byte sectors map one to one. If you are using disks/ssd with 4096 byte sectors, it is important to align things correctly for performance, so writing one file sector aligns with 1 disk sector rather then having to write 2 sectors.

Dariusz Piatkowski:
Oh Dave, you bet. My thinking about the 4K sector size is for exactly all the reasons you mentioned, with one significant exception.

DFsee has since about the early 15.x releases supported the creation of custom drive geometry such that the GEO would align itself to the 4K sector size that is needed for the SSD drives to deliver maximum performance.

JvW and I specifically discussed this around the time I was deploying my SSD for the very first time. I had ultimately ran into some problems (due to other issues) and wasn't able to test things out further...and well, since I was left w/o a functioning system my focus at that time was to simply finalize the move to the new drive and get-on with it!

Alright, now the situation is a little different.

I have my 860Evo SSD and figured I would really try to chase all the little pieces down to understand what (if any) benefits there are to be un-locked on our platform.

As such, I used DFsee again to force drive geometry for a large SSD (up to about 2T), that meant getting 4K sector sizes.

Here is the DFsee drive GEO controls screen I'm talking about:

--- Code: ---┌───────────┤ Select pre-defined geometries, or set a custom one ├────────[X]┐
│                                                                            │
│ Geometry info for :     Whole  Phys. disk 4 FDISK  size:  465.8 GiB        │
│                                                                            │
│  476930 MiB as reported by the OS                                          │
│                                                                            │
│  476930 MiB for logical geometry :      15960    255       240             │
│                                                                            │
│                                     #Cylinders   #Heads    #Sect/track     │
│ ( ) Custom geometry, using values:  calculated   255       240             │
│                                                                            │
│ ( ) Classic desktop/3.5"  255/63   OS/2 limit  502 GB \   for other OSes   │
│ ( ) Classic laptops/2.5"  240/63   OS/2 limit  472 GB  \  no real limit    │
│ ( ) USB/SSD/4Kb-sectors   255/32   OS/2 limit  267 GB  /                   │
│ ( ) Std SSD/4Kb-sectors    64/32   OS/2 limit   67 GB /                    │
│ (*) Big SSD/4Kb-sectors  255/240   OS/2 limit 1912 GB \   for other OSes   │
│ ( ) Huge rotating disk   255/127   OS/2 limit 1012 GB  >  no limits, but   │
│ ( ) Huge rotating disk   255/255   OS/2 limit 2032 GB /   not recommended  │
│                                                                            │
│ ╔══════════════╗   Resulting Cylinder size:   29.9 MiB    ┌─────────────┐  │
│ │ Set Geometry │                                          │ Cancel/Done │  │
│ ╚══════════════╝   Alignment / Track  size:  120.0 KiB    └─────────────┘  │
│                                                                            │
└──────┤F1=Help F4=OK F12=Min Alt+F7=Move Alt+F10=Max Alt+C=Copy2Clip├───────┘

--- End code ---

So check this out, two runs of my modified DISKIO code which measure the performance for 512 byte (normal HDD stuff we are all used to) and the SSD specific 4K byte sector sizes:

1) 512 Byte

--- Code: ---Hard disk 4: 255 sides, 60801 cylinders, 63 sectors per track = 476937 MB

Drive cache/bus transfer rate: 280440 k/sec

Data transfer rate on cylinder 0   : 358500 k/sec

Data transfer rate on cylinder 60799: 339230 k/sec

CPU usage by full speed disk transfers: 5%

Average latency time: 0.4 ms

Multithreaded disk I/O (4 threads): 323144 k/sec, 6% CPU usage

--- End code ---

2) 4K byte

--- Code: ---Hard disk 4: 255 sides, 15960 cylinders, 240 sectors per track = 476929 MB

Drive cache/bus transfer rate: 188003 k/sec

Data transfer rate on cylinder 0   : 424791 k/sec

Data transfer rate on cylinder 15958: 414888 k/sec

CPU usage by full speed disk transfers: 4%

Average latency time: 0.0 ms

Multithreaded disk I/O (4 threads): 241640 k/sec, 3% CPU usage

--- End code ---

Now, the cache/bus test result is suspect and I'm trying to figure this one out since that logic forces things into a 512 byte sector size and therefore cache fill and read metrics themselves.

However, if you look at the remaining data xfer rates, boy, massive difference. Heck, 360M => 425M and 340M => 415M, that's substantial.

These results can be reproduced and they show in other disk access tests as well.

Now back to one of the points you raised in your last post. There still is an ultimate limit on how big of a storage we can access in OS/2 (about 2T). If anything, the sector size increase allows us to max out the remaining hard controls, such as the: sides, cylinders and number of sectors.

I did read the posts on the testers list and as much as I wanted to respond with my findings, I didn't quite have all my work completed, so it would have been all speculation. However now, I do actually have some numbers, although more DISKIO work needs to be done for these numbers to be completely reliable.

I think I'll do a few tries of the DosQueryFSInfo API to see if the sector sizes being returned are true. If they are (and I have no reason to believe they would not be) I will try to change DISKIO logic to dynamically fetch these and adjust the testing accordingly.

Well I got my answer fast enough for whether the DosQueryFSInfo API will work. The answer is NOPE, not for the purposes I want. Specifically this is a FileSystem API whereas the reall info I'm after is the DEVICE sizing itself...so it looks like it's back to the DosDevIOCtl for now...


[0] Message Index

[#] Next page

Go to full version