Discussion:
RMS and SSIO (again)
Add Reply
Vitaly Pustovetov
2022-01-07 17:38:40 UTC
Reply
Permalink
Lets assume the SSIO interface will be $QIO possibly using something like IO$M_RBYTE/IO$M_WBYTE. This would in effect be readp/writep (linux IO routines) on VMS. So lets externalize them as SYS$READP/SYS$WRITEP.
Why do we need to assume? =)

int sys$ssio_readw(
unsigned short chan,
VOID_PQ buffer,
unsigned __int64 bufsiz,
IOSA_PL iosa,
RESTARTROUTINE64 ast,
VOID_PQ astprm);

int sys$ssio_writew(
unsigned short chan,
VOID_PQ buffer,
unsigned __int64 bufsiz,
IOSA_PL iosa,
RESTARTROUTINE64 ast,
VOID_PQ astprm);
Greg Tinkler
2022-01-08 01:31:24 UTC
Reply
Permalink
Post by Vitaly Pustovetov
Why do we need to assume? =)
I/we assume because that is the architecture of VMS, if you want to do an IO you use $QIO. What the internals do is up to the EXEC/KRNL code... From user mode I 'assume' $QIO. I also assume given it accesses XFC that is it cluster safe.

NB I missed typed, pread/pwrite are the 2 routines I am thinking about. (https://man7.org/linux/man-pages/man2/pread.2.html)

Even with the 'different' interface the still concept stands, we can use pread/pwrite (type calls) on top of XFC to replace all the RMS buffering, and yes we still need RMS record locking...

gt
Vitaly Pustovetov
2022-01-08 17:12:41 UTC
Reply
Permalink
I/we assume because that is the architecture of VMS, if you want to do an IO you use $QIO. What the internals do is up to the EXEC/KRNL code... From user mode I 'assume' $QIO. I also assume given it accesses XFC that is it cluster safe.
We don't have to assume anything about the current interface of SSIO. Because it is already define.
p.s. About cluster support - "SSIO V1 has minimum cluster support".
Greg Tinkler
2022-01-09 00:07:56 UTC
Reply
Permalink
On Sunday, 9 January 2022 at 4:12:43 am UTC+11, Vitaly Pustovetov wrote:
Hi Vitaly
Post by Vitaly Pustovetov
We don't have to assume anything about the current interface of SSIO. Because it is already define.
It is not in any 'released' documentation, possibly part of FT and therefore subject to change...

If you look at the parameters they are almost $QIO so why not change it so they are.

One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue. NB in this case the correct solution was FIX CRTL to use RMS correctly.

My point is lets use this change to benefit lots of requirements for VMS, not just Postgresql. Part of that would be to code pread/pwrite in CRTL to use this interface, and have the byte update XFC/SSIO API visible to all code that uses ACP/XPQ.
Post by Vitaly Pustovetov
p.s. About cluster support - "SSIO V1 has minimum cluster support".
Yup, it does not define what 'minimum cluster support' is. For more minimum cluster support means it supports cluster, end of, i.e. it either supports cluster, which if it uses XFC it must, or it is some other interface maybe hacking XFC which we don't want.

XFC by it's very nature coordinates the updating of 'buffers' (MBC's) for all files in the cluster across all systems in that cluster. If it does not work that way then a lot of things will break. If it does work that way, and we have a reasonable expectation that it does, then implicitly SSIO will work across a cluster subject to the application code coordinating the access to the data to avoid those issues that are outside XFC's control, aka serializing data access probably using LCK$...

Back to my main point, RMS buffer can go. We can now use XFC to do the local/global buffering, NB XFC may need some tweaking so it will use bucket size, and number of buffers as set by $ SET RMS/BUFF... which it sort of does now anyway.

gt
Arne Vajhøj
2022-01-09 00:28:20 UTC
Reply
Permalink
Post by Greg Tinkler
On Sunday, 9 January 2022 at 4:12:43 am UTC+11, Vitaly Pustovetov
wrote: Hi Vitaly
Post by Vitaly Pustovetov
We don't have to assume anything about the current interface of
SSIO. Because it is already define.
It is not in any 'released' documentation, possibly part of FT and
therefore subject to change...
If you look at the parameters they are almost $QIO so why not change it so they are.
One if the things that a lot of users of VMS have liked years is the
focus on quality engineering looking at the whole OpenVMS
environment, and not a knee jerk response to some particular issue.
NB in this case the correct solution was FIX CRTL to use RMS
correctly.
Somehow I doubt that.

Arne
Greg Tinkler
2022-01-09 00:35:16 UTC
Reply
Permalink
On Sunday, 9 January 2022 at 11:28:32 am UTC+11, Arne Vajhøj wrote:
Hi Arne
Post by Arne Vajhøj
Somehow I doubt that.
What do you doubt?
I wrote some test code that 'fixed' the issue and emulated what CRTL should do. Only took a few days, and it worked as expected.

Or is there something else you doubt? Maybe you doubt VMS engineering group tried hard to make a quality product, I doubt that as I also found them to be very professional and focused on quality. But that was back in the day, 30 years ago.

So doubts? Would you like to expand that.

gt
Arne Vajhøj
2022-01-09 01:09:24 UTC
Reply
Permalink
Post by Greg Tinkler
Post by Arne Vajhøj
Somehow I doubt that.
What do you doubt?
That it can be done as a CRTL fix.
Post by Greg Tinkler
I wrote some test code that 'fixed' the issue and emulated what CRTL should do. Only took a few days, and it worked as expected.
In that case I suggest you wrap up all the code with the
read/write/whatever prefixed with GT$ or whatever and release
it, then everybody should be able to build and run PostgreSQL
safely on VMS just by doing a few defines - on all VMS
including HP VMS and VMS VAX etc..

Arne
Greg Tinkler
2022-01-09 01:38:31 UTC
Reply
Permalink
On Sunday, 9 January 2022 at 12:09:36 pm UTC+11, Arne Vajhøj wrote:
yes not maybe, in case you have not noticed OpenVMS is a commercial operation. It would be great if VSI published what they did to make clang/llvm work on Linux to build bits for VMS...

What I will show is to key bit to solving the problem.
fdptr->fab->fab$b_rfm = FAB$C_UDF;
fdptr->fab->fab$v_esc = 1;
fdptr->fab->fab$l_ctx = RME$C_SETRFM;
sts = sys$modify (fdptr->fab);

And no I don't feel like having to explain it, you ether understand or don't.

gt
John Reagan
2022-01-09 03:29:37 UTC
Reply
Permalink
Post by Greg Tinkler
It would be great if VSI published what they did to make clang/llvm work on Linux to build bits for VMS...
I've discussed this before but we'll provide the code. I still want to push the LLVM code back to the LLVM git repo.

Essentially, the LLVM changes are
- add an argcount
- add some extra ELF .note sections for module name, etc. but the linker will be ok without it
- add some extra code to make sure we always go through the GOT for static data (like the medium model but not quite) since code will be in 64-bit space but static data is always 32-bit. If you like with /SEGMENT=CODE=P0, you don't need it
- add code to specify .personality routines as specified by the frontend. LLVM is still biased to thinking that .personality routines are all about C++ try/catch.
- add code to deal with more complex LTCEs for "symbol - symbol" relocations

You can go watch my LLVM 5-minute lightning talk from a few years back. Head over to the LLVM channel on YouTube and search for my name. You'll find both talks I've presented.

For clang, that's still a work-in-progress, but RTL prefixing, dual-size pointers (leveraging the existing support in clang), pragma nomember_alignment (almost like pack), headers from TLB files, etc.
Greg Tinkler
2022-01-09 04:57:22 UTC
Reply
Permalink
On Sunday, 9 January 2022 at 2:29:39 pm UTC+11, ***@gmail.com wrote:
thanks John, it is one hell of a task you have to get all those compilers to work...
Arne Vajhøj
2022-01-09 23:39:08 UTC
Reply
Permalink
Post by Greg Tinkler
yes not maybe, in case you have not noticed OpenVMS is a commercial operation.
That does not prevent you from publishing C code that
solve the problem on all VMS versions.
Post by Greg Tinkler
What I will show is to key bit to solving the problem.
fdptr->fab->fab$b_rfm = FAB$C_UDF;
fdptr->fab->fab$v_esc = 1;
fdptr->fab->fab$l_ctx = RME$C_SETRFM;
sts = sys$modify (fdptr->fab);
And no I don't feel like having to explain it, you ether understand or don't.
That is the C equivalent of:

$ SET FILE/ATTR=RFM:UDF

And if you think that is the solution to the SSIO problem, then
I am changing my opinion from "Somehow I doubt that" to
"I totally do not believe that".

Arne
Hein RMS van den Heuvel
2022-01-09 03:56:53 UTC
Reply
Permalink
Post by Greg Tinkler
If you look at the parameters they are almost $QIO so why not change it so they are.
QIO is a generic interface, this a specific one.
It's called progress without being disruptive, still giving a familiar touch and feel.
Switch to all 64 bit, ditch the crud.
IO$_READVBLK orred with modifier bits? Yuck!
Almost too bad they kept the 'channel' instead of a generic (more) opaque 'handle'.
Almost because but I do love my SDA> SHOW PROC/CHAN and such.
Post by Greg Tinkler
One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue.
Steam IO a knee-jerk reaction? Ha! It's been looked at, worked on for 20+ years.
Post by Greg Tinkler
NB in this case the correct solution was FIX CRTL to use RMS correctly.
Nonsense. The C-RTL folks didn't live/work in a vacuum. They know/knew how to use RMS, they know about the FAB$C_UDF hackery.
They know (and implemented) how NOT to use (buffered) RMS and switch to SYS$READ/SYS$WRITE to avoid excessive going in an out of EXEC mode with all the probing for simple actions.
Post by Greg Tinkler
Post by Vitaly Pustovetov
p.s. About cluster support - "SSIO V1 has minimum cluster support".
Yup, it does not define what 'minimum cluster support' is. For more minimum cluster support means it supports cluster, end of, i.e. it either supports cluster,
which if it uses XFC it must, or it is some other interface maybe hacking XFC which we don't want.
You mistakenly believe that XFC usefully supports clusters. It doesn't. It merely coexists peacefully.
All the XFC caches for a file on one node are invalidated when a change, any change, anywhere is made for that file on an other node.
Post by Greg Tinkler
XFC by it's very nature coordinates the updating of 'buffers' (MBC's) for all files in the cluster across all systems in that cluster.
Noop.
Post by Greg Tinkler
If it does not work that way then a lot of things will break.
Correct. The XFC knows just enough to walk away before it breaks.
Post by Greg Tinkler
If it does work that way, and we have a reasonable expectation that it does,
Noop.
Post by Greg Tinkler
Back to my main point, RMS buffer can go.
Now there you are correct.

The whole goal of stream IO should be to get rid of protected process buffers and use shared system buffers like Linux does.
Post by Greg Tinkler
We can now use XFC to do the local/global buffering, NB XFC may need some tweaking so it will use bucket size, and number of buffers as set by $ SET RMS/BUFF... which it sort of does now anyway.
I disagree. Let RMS keep doing the global buffers, relative files, indexed files, bucket size
Just solve the shared sequential file problems.

fwiw, I don't see how the XFC 'sort of does' take MBC, MBF, BKS into consideration. It doesn't. It just divides a file up in 8KB (or was it 16) cache lines with zero consideration for actual usage. In fact the default for indexed and relative file causes maximum overhead due to the prologue block(s) in those files as well as the typically 'odd' cluster sizes.
Even if you make the bucket size a nice multipel of fraction of a cache line, you'll start off with the odd bucket and there will need an extra cache line all the time.
I did extensive experiments with this back in the day (Mark Hopkins!) .
If you tweak an Indexed file just so - over and beyond normal tweaking - you can get a few percent improvement - reducing CPU and IO.
(make cluster size a multiple of 16, make bucket size a multiple or divisible fraction of 16, make the data NOT be in AREA 0 which has the prologue)

Cheers,
Hein
Greg Tinkler
2022-01-09 05:28:13 UTC
Reply
Permalink
Hi Hein

yup maybe are correct about XFC, I though I had read some thing somewhere (by Keith Parris, talking about using hash lookups on the buffers and some tweaks for the locks, must have been dreaming) ... Sad, I had hoped after all the learnings from VCC and earlier XFC things may have improved.

So given the state of play with XFC, and it does not work as expected
- fix XFC so it works, until it does use RMS buffering
- fix CRTL so it works correctly, it is always to have the correct data than slow data
- longer term, once XFC is working well, move RMS to use it for buffering
- don't use SSIO until XFC is fixed

Yes $QIO is a generic interface, that is exactly why I think it should be used. If this is a 'special' case for Postgresql, then maybe call it PQL$special_io(), and only have it documented for that particular use. Otherwise it will become general usage, and therefore should be a generic API.
Vitaly Pustovetov
2022-01-09 18:27:41 UTC
Reply
Permalink
Post by Greg Tinkler
If you look at the parameters they are almost $QIO so why not change it so they are.
For what? We have a new 64-bit system for working with "regular" files. Why access it through $QIO and not through convenient functions?
Post by Greg Tinkler
NB in this case the correct solution was FIX CRTL to use RMS correctly.
The authors of RMS have invented and made SSIO. Do you think they were wrong and we need to correct the CRTL? I'm not sure if your solution will work and it will probably be slower than SSIO.
Post by Greg Tinkler
My point is lets use this change to benefit lots of requirements for VMS, not just Postgresql. Part of that would be to code pread/pwrite in CRTL to use this >interface, and have the byte update XFC/SSIO API visible to all code that uses ACP/XPQ.
read/write/pread/pwrite/readv/writev are SSIO ready since 2005. ;)
Arne Vajhøj
2022-01-10 02:12:37 UTC
Reply
Permalink
Arne Yup it 'pretends' that the file is UDF, but does not change the
file itself. This allow the access to change on the fly to UDF and
back, which then allows all the other RMS functions to work as
expected.
Does it work, yes it does, been there, got the tee-shirt. Re the
code, since I am talking about replacing CRTL components it should be
done within the auspices of CRTL, so FD/FCB etc all correctly
managed. If VSI want to send me all the CRTL relating the files then
maybe... But I don't think that is practical, do you?
There is no need for all of that. It can be done other ways.
Most simple would be an acc callback in open to change it
and a revert routine using saved info.

But I am amazed that someone believe that such 20 lines would
solve a problem VMS engineering has spent a decade or more
on.

Arne
Greg Tinkler
2022-01-10 02:57:28 UTC
Reply
Permalink
Arne

frankly I am not surprised that the offshore VMS group could fix it, I am surprised the the back in the 80/90's the CRTL folk did not talk with the RMS group and have a good solution in place to start with. But then C IO was a very low priority, you either did RMS or your own $QIO. Now with open source it is a very different ball game.

SSIO is not and was never a well designed solution. It looks more like a *nix persons view of how VMS should work.

Once XFC can be properly used for buffer sharing across the cluster, and RMS can use it, then maybe, but why not then just use RMS. The main question re XFC is the focus disk io buffering or file caching. If it is disk IO then it should probably use the device's 'cluster size' as the buffer size, if it is file buffering then it should be MBC/Bucket size. Using some 'fixed' value that does not match either of these will/does cause issues...

The SYS$MODIFY's function is what you just described, after an open, get RMS to pretend that the file is of a different format. And no it is not just 20 lines, that was the few line to help those that don't understand VMS/RMS what is possible. Careful code design would allow the initial open to use UDF so you don't need to do it each IO.

"There is no need for all of that. It can be done other ways."
Well if that is the case then please put your code up... and clearly you don't think SSIO is a good solution either. 8-))

gt
Greg Tinkler
2022-01-10 04:21:08 UTC
Reply
Permalink
And sorry if have been a bit blunt, a couple of COVID19 scares...

gt

Loading...