OS/2, eCS & ArcaOS - Technical > Programming

DosDevIOCtl API references?

<< < (2/3) > >>

Lars:
OS/2 will always be stuck with a sector size of 512 unless you rewrite larger parts of the kernel. In theory, at least the .ADD drivers would be able to deal with other sector sizes as there is a "sectorsize" field. But the reality is that all code assumes a sector size of 512 bytes because the kernel does not make good use of this field.

ALIGNING on 4 kBytes is very simple: just align the 512-byte sized sectors to a multiple of eight :-)
That still does not mean that OS/2 would be able to address 4 Kbyte sectors. It expects the HW to still be able to handle 512 byte Sectors. The HW can be intelligent and internally remap this to a 4 KByte sized sector number with an appropriate offset into that 4 kByte sector.

Now you will likely bring forward the argument that using a sector size of 4 kByte is all so great with diskio. I would think that's because of the way diskio works. If you specify a sector size of 4 kBytes, in reality, OS/2 will schedule 8 transfers for a 512 byte sector size BUT the first sector will happen to start at a 4kByte boundary. THAT will lead to the HW disk cache reading in the full 4 kByte internal sector size. Therefore, the next 7 transfers will be faster because the data is already in the HW disk cache.
In reality, when reading arbitrary, random sectors, this advantage will disappear and you will be left with the exact same performance.

Don't go any further. It's of no use.

Dave Yeo:
The advantage of aligning the sectors, mostly in a SSD, is less writes. Ignoring metadata, write a one byte file, JFS transfers a 4Kb block, one sector gets written, instead of 2 sectors if not aligned. With a SSD, there is a limited number of writes possible and there is also the garbage collection where data is shifted around for wear leveling. Less garbage collection equals faster and less writes equals longer lasting SSD.
For a real hard drive, aligning the sectors could cut down on fragmentation, writing one sector vs writing 2 sectors in different parts of the drive for a one byte file write.
JFS is actually kind of a crappy file system for SSD's. The journal writes cause more wear and I believe OS/2 supports writing the atime (last access time) so even reading a file updates the time metadata in the inode. OTOH, that JFS (and HPFS) use extends is good on a SSD.
Linux actually has a mount operation to turn off writing the atime and can put the journal on a different device.
Note, I'm not sure if OS/2 writes the atime.

Lars:
Ok, this is a valid point. If the filesystem insists on reading a minimum of 4 kB (even if you only need 1 byte of those 4  kB) then you are right and alignment of physical 4 kB sectors to multiple of eight 512-byte sectors for a track start and the number of sectors per track being a multiple of eight (as for example: 240) will prevent touching two physical 4 kB sectors.

I seem to remember that HPFS is much more efficient in this respect. It only asks for one single (512 byte) sector if you only want to read 1 byte.
In short: HPFS should show no difference in speed in diskio for the given case.

Anybody know why 240 was picked but not 248 [which would be the maximum multiple of 8] ? Is the world already planning for 8 kB physical sector size ?

Lars:

--- Quote from: Dariusz Piatkowski on March 23, 2021, 03:33:20 pm ---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 ---


--- End quote ---

You will find this in this zip:
https://hobbes.nmsu.edu/download/pub/os2/system/drivers/storage/IBM1S506_10-117.zip

when you read through the enclosed readme.txt, you'll find:
0x82: IOCTL_CDROMDISK2
0x60: CDROMDISK2_DRIVELETTERS

and the used structure:
  Data Packet format:

   struct DriveLetters {
      USHORT        DriveCount;         // number of supported CD-ROM drives
      USHORT        DriveFirst;         // letter of the first CD-ROM drive
   };

This call is to query how many CD-ROM drives you have and what are their drive letters (they are consecutive).
In short: this info never made it into the OS/2 programming specs as it was added to the relevant drivers much later.

You will likely want to use:
0x80: IOCTL_OEMHLP
0x0E: OEMHLP_QUERYDISKINFO

the data (? or parm ?) structure is:

OEMHLPDISKINFO and is described in file bsedev.h in the toolkit. I would expect it to always return 512 as the sector size but I am not sure (I forgot what it uses to get to its info, it possibly directly issues ATA commands to the device to get the internal info).

Dariusz Piatkowski:
Hi Lars!


--- Quote from: Lars on March 24, 2021, 05:31:25 pm ---...You will likely want to use:
0x80: IOCTL_OEMHLP
0x0E: OEMHLP_QUERYDISKINFO

the data (? or parm ?) structure is:

OEMHLPDISKINFO and is described in file bsedev.h in the toolkit. I would expect it to always return 512 as the sector size but I am not sure (I forgot what it uses to get to its info, it possibly directly issues ATA commands to the device to get the internal info).

--- End quote ---

Thank you sir...this is exactly what I was looking for. I did find the data structure in bsedev.h file, it appears to have the sector sizing along with a pile of other stuff. I may have seen this in the DANI drivers and/or utilities code before as well, most likely didn't even realize the details it contained and the relevance to what I was looking for.

Good stuff, another lesson learned!

Re: this topic in particular, Dave highlighted the reasons why I'm pursuing making changes to DISKIO and why the underlining changes to the device geo structure may be relevant to us. While the point he raised about the JFS FS structure is very valid, the fact that most JFS deployments probably utilize a 4K block (due to the partition/volume size) lends itself extremely well to syncing up with how the physical SSD hardware itself is organized.

My interest in making the underlying DISKIO changes is to develop a true capability to assess this, given the departure from the 512 byte sector size.

One step at a time though, let me see if I can get my physical device info first with the 0x80 category call to DosDevIOCtl AND using the 0x0E function call to query the device capabilities.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version