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:
┌───────────┤ 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├───────┘
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
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
2) 4K byte
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
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.
EDIT
====
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...