Well ArcaOS 5.0 is probably the last version for me.

[Greg Pringle]

So, for you "OS/2" is dead.

That reminds me of OS/2 1.0 which I used a few times. My roomate ran a BBS using it. Then 2.0 came out and I bought it. Soon I programmed for it and installed many applications at work that cound not be done with windows 3.1 As time went on I used virtually every varient of OS/2. All along it was being called "Dead". I even knew the people at IBM that were responsible for trying to kill OS/2. They all failed, most lost their jobs. Yet, OS/2 continued.

I use both an OS/2 machine and a virtual OS/2 machine. The normal machine is faster and has a better interface. I don't have to bother with multiple logins and odd screen views.

I develop for every operating system. OS/2 is still the best.

(by the way, the Colonial Pipeline hack would not have happened with OS/2)

[Fahrvenugen]

So, for you "OS/2" is dead.

I can't remember who it was, but someone once said that if we had 1 additional OS/2 user for every time it was declared "dead" we'd have more users then Windows users.  Some days I think there might be some truth to this LOL!

[David McKenna]

 Hey Guys,

  According to Wikipedia (  https://en.wikipedia.org/wiki/JFS_%28file_system%29  ) the JFS file system has a maximum file size of 4PB, and maximum volume size of 32PB. Since JFS allows 'spanning' of partitions to create large volumes, wouldn't it be possible to have 3 2TB partitions (to use Neil's example) 'spanned' as a 6TB 'drive' (that is: a non-bootable Volume)? Or do I misunderstand and Wikipedia is wrong (at least for OS/2)? I've never actually spanned partitions, so not sure how that works...

Regards,

[Doug Bissett]

You can span ADVANCED volumes (even on different physical disks), but I don't know about >2 TB volumes. Advanced volumes are not bootable.

I did it, years ago (much smaller disk, of course), with mixed results. It did work okay, but introduced some very messy maintenance challenges. Eventually, I just consolidated it all, when I got a new disk that was big enough to hold all of it.

It would be educational to know if it works with large disks, but I don't have one to play with.

[Dave Yeo]

IIRC, the JFS file and volume size limits are lower on OS/2 then on Linux.

[Lars]

The storage driver provides 48 bit LBA addressing. And the GPT filter driver uses this interface. That way you can access a +2TB disc with ArcaOS.

As I understand it, the GPT filter driver will split a 6 TB drive into 3 units of 2 TB each, allowing you to access a 6 TB drive as, for example, E:, F: and G:. This is different from a single drive letter with 6 TB, which is currently only possible on a network drive.

Ok, that pretty much explains it. The drive letter "logically" extends the 32 bit LBA address, providing additional upper bits for the 48 or 64 bits sent to the device to address a sector. At least, that is a good trick but it uses up valuable drive letters.

[Lars]

Thinking out loud: a transfer IORB for the ADD contains a 16-bit field "Blocksize". For once, that field is pretty useless as up to present day, OS/2 always expects a value of 512. But even if not, the upper say four bits could be used to extend the LBA address. But that would require to update OS2DASD.DMD accordingly. And of course, the ADD to take advantage of those 4 additional bits.

[Rich Walsh]

As I understand it, the GPT filter driver will split a 6 TB drive into 3 units of 2 TB each, allowing you to access a 6 TB drive as, for example, E:, F: and G:. This is different from a single drive letter with 6 TB, which is currently only possible on a network drive.

Ok, that pretty much explains it. The drive letter "logically" extends the 32 bit LBA address, providing additional upper bits for the 48 or 64 bits sent to the device to address a sector. At least, that is a good trick but it uses up valuable drive letters.

Sorry but none of this is correct.

GPT.FLT (which isn't really a filter, per se) creates a set of emulated MBR disks, one for each partition you want to mount. It then makes each GPT partition look like it is the only primary on that MBR disk. Because access to the underlying disk (which OS/2 knows nothing about) is through this MBR emulation, MBR limits of 2TB apply.

Also, because this is an emulation, LVM disk spanning (which requires additional on-disk LVM data) is impossible.

[Lars]

So that also means none of the real GPT partitions can be bigger than 2TB, correct?
If yes, then the sole intention of that filter is to make accessible GPT partitions and not to provide access to larger partitions, correct?

[Roderick Klein]

Is it a perfect solution ? Hmmm perhaps not. But at least people will no longer have to wipe Windows 10 if they want to maintain the Windows installation.
Also ALL associated possible headaches with MBR disk layout are a thing of the past.
For the coming years for me this would be an acceptable solution. I do not see in the next 2 to 3 years hard discs ending up in consumer PC's of 20 TB?
But I might be wrong...

Check www.warpstock.eu for a presentation from Alex Taylor demonstrating UEFI.

Roderick

[Lars]

I guess there cannot be a perfect solution as there will likely be multiple places where that 2TB limit will come into play, also thinking about the disk tools.
But it seems that with the help of GPT.FLT (that can modify the IORBs passed between OS2DASD.DMD and the ADD drivers), you can also address sectors beyond the ABSOLUTE 2TB limit and that OS2AHCI.ADD has some sort of extension to use 48 bits of LBA address. Potentially what I proposed earlier on.
What is the reason why OS2DASD.DMD cannot be modified?
License issues?

[Rich Walsh]

it seems that with the help of GPT.FLT (that can modify the IORBs passed between OS2DASD.DMD and the ADD drivers), you can also address sectors beyond the ABSOLUTE 2TB limit and that OS2AHCI.ADD has some sort of extension to use 48 bits of LBA address. Potentially what I proposed earlier on.

I didn't see your proposal so I wrote my own 

There are two new CommandCodes: IOCC_GEOMETRY64 (0x13) and IOCC_EXECUTE_IO64 (0x14). They signal the use of new extended IORBs, GEOMETRY64 and IORB_EXECUTEIO64. The only difference from the 32-bit IORBs is that a 64-bit field has been added at the end of the structures to hold ullTotalSectors and ullRBA, respectively. The .ADD code is unchanged except that it now looks at the CmdCode to decide whether to take the LBA from the 32-bit or 64-bit field.

Current versions of AN's 'os2ahci.add' and 'nvme.add' support this interface. It's use comes at a small cost: for requests above 2TB, GPT.FLT has to create a 64-bit version of each request before it sends it to the .ADD. Each request is less than 100 bytes, so the overhead is minimal.

BTW... IOCC_GEOMETRY64 returns the actual number of sectors on a disk - it isn't rounded down to a cylinder boundary. The call can also be used as a safe way to determine if 48/64-bit support is available.

What is the reason why OS2DASD.DMD cannot be modified? License issues?

Virtually everything above the .ADD/.FLT level is tied to 32-bit LBAs. There's just too much to change.

[drjohnnyfever]

On the thought of "64-bit OS/2", mostly what we really want is utilize all of our physical RAM in a system to be able to run more applications. We don't particularly care about the virtual address space limit per process as much, although that could be a bit of a pain point for web browsers in the future.

The "easy way" of doing this (if there is such a thing) to me seems like if you could wedge a hypervisor under OS/2 (or inside of it as the case my be) so you could run multiple instances of it, as if it were on KVM of ESXi but have it be totally transparent (or mostly transparently) to the user so it is all managed by native ArcaOS / OS/2 tooling in the UI and it appears like you are running one OS (think of the way virtual DOS machines currently work in OS/2). And have some sort of driver infrastructure added in to the kernel such that IPC mechanisms from the different running instances could be bridged together so from an application perspective it seems like applications are running on the same instance, and inter process communication works as normal. Granted this may well be a difficult project. I can see proof of concepting it as running multiple instances of ArcaOS in VirtualBox on a Windows system with drivers added so IPC works between applications in the different instances.

I'm only vaguely aware of how process address space works in OS/2, most of my OS internals knowledge is from FreeBSD so I might be way off base in how practical this would be to do, but it does seem doable. The main goal here would be to do the minimum possible change required to the system itself and push all the complexity down to some lower layer. Xen or Bhyve or L4 could perhaps be repurposed to minimize the effort.

I know I'm far from the first person to come up with this idea, but I'm wondering if anyone has tried pursuing it.

[Lars]

it seems that with the help of GPT.FLT (that can modify the IORBs passed between OS2DASD.DMD and the ADD drivers), you can also address sectors beyond the ABSOLUTE 2TB limit and that OS2AHCI.ADD has some sort of extension to use 48 bits of LBA address. Potentially what I proposed earlier on.

I didn't see your proposal so I wrote my own 

There are two new CommandCodes: IOCC_GEOMETRY64 (0x13) and IOCC_EXECUTE_IO64 (0x14). They signal the use of new extended IORBs, GEOMETRY64 and IORB_EXECUTEIO64. The only difference from the 32-bit IORBs is that a 64-bit field has been added at the end of the structures to hold ullTotalSectors and ullRBA, respectively. The .ADD code is unchanged except that it now looks at the CmdCode to decide whether to take the LBA from the 32-bit or 64-bit field.

Current versions of AN's 'os2ahci.add' and 'nvme.add' support this interface. It's use comes at a small cost: for requests above 2TB, GPT.FLT has to create a 64-bit version of each request before it sends it to the .ADD. Each request is less than 100 bytes, so the overhead is minimal.

BTW... IOCC_GEOMETRY64 returns the actual number of sectors on a disk - it isn't rounded down to a cylinder boundary. The call can also be used as a safe way to determine if 48/64-bit support is available.

What is the reason why OS2DASD.DMD cannot be modified? License issues?

Virtually everything above the .ADD/.FLT level is tied to 32-bit LBAs. There's just too much to change.

Hi Rich,

I am always glad to help. Let me know if you need any :-)

Thanks for letting me know the new command codes. For reasons of large floppy support, I also had to add a new (internal) command code to USBMSD.ADD. Now I can check if that conflicts with the new command codes you mentioned.

[Fahrvenugen]

I suspect I already know the answer to this, but I seem to recall reading years ago (probably 15 to 20 years ago - back when IBM still had a few people working on OS/2's kernel) that someone at IBM was looking into updates / modifications to OS/2's kernel to allow it to enable and use PAE mode - at least from the standpoint of allowing memory above the 4GB barrier to be fully used by the system.  Does anyone have any idea what might have become of this?

I'm guessing the current ramdisk option we have is using PAE to some extent to allow that memory to be accessed.  I'm just wondering if my memory of the supposed IBM work on PAE in the kernel is correct/incorrect, or if it was tried and just didn't work reliably which is why we now have the ramdisk option (as it does work well).