VMS dürfte wohl mit so großen Filesystemen keine Probleme haben, wenn überhaupt dann die Kombination aus VMS, Controller und Platte.
Bei PC gab es doch eine Limitierung, glaub auf 512MB und 1024 Spuren. Eventuell tritt hier so ein Effekt ein daß VMS die Plattengröße erkennt aber ein paar höherwertige Bits der Blocknummer beim Lesen/Schreiben unter den Tisch fallen.
Ich würde es ausprobieren. Durchnummerierte Dateien anlegen, jeweils x MB gross, und in z.B. 512 Byte blocken jeweils Datei- und Blocknummer schreiben. Ist die Platte vollgeschrieben, die Dateien durchlesen und Prüfen ob gelesene Datei- und Blocknummer der erwarteten entsprechen.
Ich würde es ausprobieren. Durchnummerierte Dateien anlegen, jeweils x MB gross, und in z.B. 512 Byte blocken jeweils Datei- und Blocknummer schreiben. Ist die Platte vollgeschrieben, die Dateien durchlesen und Prüfen ob gelesene Datei- und Blocknummer der erwarteten entsprechen.
Das habe ich nicht ganz verstanden.
also mit SYSGEN>CREATE files beliebiger Blockgröße schreiben kann ich.
Was meinst Du mit Datei und Blocknummer genau?
Zum Ausprobieren hat Bernhard für die 4000/60 auch was geschrieben RE: Vaxstation 4000/60 Inbetriebnahme
Datei mit fortlaufender Nummerierung, je 512Byte groß und mit der Blocknummer (= Nummer der Datei) in der Datei, so würde ich das verstehen... 
PS: wenn man zu lang vor so einem Maschinchen sitzt, wird man betriebsblind... 
Die 4000-er sollten das Problem nicht mehr haben, und bei den 3100 serie gab es das nur zur Boot-Zeit.
Die Boot-EPROMs der alten 3100 nutzen nur kurze SCSI commandos, deshalb muss alles was das system zum Booten braucht im ersten 1GB liegen. Sobald VMS gebooted ist, nutzt es andere Treiber für SCSI, und es sollte nichts mehr schief gehen ...
Datei mit fortlaufender Nummerierung, je 512Byte groß und mit der Blocknummer (= Nummer der Datei) in der Datei, so würde ich das verstehen...
Fast, die Nummer des 512 Byte Blocks muss auch in die Datei
So etwa:
Datei.1
Erste 512 Bytes enthalten Dateinummer (1) und die Blocknummer (1)
Zweite 512 Bytes enthalten Dateinummer (1) und die Blocknummer (2)
Dritte 512 Bytes enthalten Dateinummer (1) und die Blocknummer (3)
Datei.2
Erste 512 Bytes enthalten Dateinummer (2) und die Blocknummer (1)
Zweite 512 Bytes enthalten Dateinummer (2) und die Blocknummer (2)
Dritte 512 Bytes enthalten Dateinummer (2) und die Blocknummer (3)
Dadurch hat jeder 512 Byte Block einen Hinweis zu welcher Datei gehört und der wievielte Block es ist
Nach dem Schreiben werden die Dateien sequenziell durchgelesen und für jede Datei verglichen ob die in den
Datenblöcken stehende Datei und Blocknummer dem entsprechen was geschrieben wurde.
Tut es das nicht, also zb. ein Block in Datei x enthält eine andere Datei/Blocknummer als erwartet ist das Filesystem korrupt
denn es tauchen in der Datei Daten auf die da nicht hingehören.
Vor ein paar Jahren tauchten massenhaft gefälschte USB Sticks bzw. SSD auf welche Daten einfach wegwarfen.
Im ct Magazin wurde daraufhin das Windowsprogramm h2testw vorgestellt . .
Ich verwende das gerne um neue Speichermedien zu testen. Bei einer 18 TB Platte dauert es aber etwas länger....
Das habe ich im Internet gefunden (HPE forum):
"OpenVMS 5.5-2 has a 24 bit VBN pointer, so the maximum size disk it can address is 8.5 gb. That means NO support for 9GB disk!!
VMS Forever"
Ist also auch noch OS-Version abhängig.
Du solltest aber auf eine 4000-er und VMS7.2 OK sein
Das habe ich im Internet gefunden (HPE forum):
"OpenVMS 5.5-2 has a 24 bit VBN pointer, so the maximum size disk it can address is 8.5 gb. That means NO support for 9GB disk!!
VMS Forever"
Interessant, guter Grund VMS7 zu nehmen wenn man keine kleinen Platten hat.
Sagt aber noch nichts über den Emulex…
Habe mit der VS4000/60 , VMS 7.3 und WASD folgende Anzeige bezüglich der Festplatte (SCA 72GB).
Da könnte eine magische Grenze sein:
