Any known problems with SYMLINKS ?

[P Muralidhar Kini]

Hoff,
>> An update to BACKUP /INTERCHANGE might be a reasonable way to cause
>> BACKUP to flag or to strip off all off-disk or out-of-purview of the
>> BACKUP symlinks. It already does something sort-of similar, stripping
>> ACLs.
Your suggestion seems to be like,
If SYMLINK and target come under the purview of the BACKUP then include
the SYMLINK in the backup & display a message indicating the same.
If not then exclude the SYMLINK from the backup & display a message
indicating the same.

Sounds reasonsble as backing up the SYMLINK without the target would not
be of much use as the SYMLINK wont be functional once it gets restored in
the future.

How about a scenario where, SYMLINK is on Disk1 and its target is on Disk2.
If BACKUP's were per disk, SAVESET1 for disk1 and SAVESET2 for disk2.
At a future date, both SAVESET1 and SAVESET2 are restored.
SYMLINKS restored in this manner would work.
So i guess the option to include/exclude a symlink which does not come under
the purview of the BACKUP can be made controllable.

Robert,
>> - a command procedure to be run before (emphasis: BEFORE) upgrading to
>> ensure readiness for upgrade.
>> - the command procedure should have two modes: identify and update.
>> Identify merely lists the items that would need to be changed.
VERIFY on V84 does this job. But for a customer who is yet to upgrade from
pre V84 to V84, he would not have the VERIFY for V84. He would have to do the
upgrade first and then probably run the VERIFY to get the pre v84 SYMLINKS
repaired.

you are suggesting that, customers would benefit more if there is a means by
which the compatibility stuff can be sorted out before the upgrade (both identify
and update).

How about making the V84 VERIFY available to customers prior to upgrading.
If they could install this on the pre v84 system, then they could do both the
identify and update of the pre v84 SYMLINKS to V84 format. Once this is done
they could then proceed with the upgrade.

Regards,
Murali

[Robert Gezelter]

Murali,

Certifying that it is safe to run the 8.4 VERIFY to run on earlier systems is a start in the IMHO the correct direction. Packaging it as a "patch", possibly together with the changes to also "create" symlinks, would be even better.

The principle is straightforward. Running a ANALYZE/DISK_STRUCTURE on a significant sized storage farm is a significant project. Likely, it would be optimal to run this over time BEFORE the actual upgrade. It has already been noted that the 8.4 symlinks are fine with an 8.3 system, not vice versa.

Therefore, from the user perspective, the best order is:
- change the creation of symlinks to the 8.4 behavior (likely one or two images affected)
- run ANALYZE/DISK_STRUCTURE on all affected volumes to correct previously extant symlinks
- upgrade to 8.4.

Note that the preceding works as desired, whether or not the system is part of an OpenVMS cluster.

- Bob Gezelter, http://www.rlgsc.com

[Shriniketan Bhagwat]

Hi,

Extension to Muraliâ s explanation on BACKUP with SYMLINK.

There could be a scenario, where the SYMLINK is created with a specific disk name or logical. Example:

$
$ dir/link *.link

Directory SYS$SYSDEVICE:[000000]

A.LINK;1 -> /V84_DISK/000000/a.txt 1 B.LINK;1 -> /$5$DKA0/000000/a.txt 1

Total of 2 files.
$

After the image restore on the new disk, if the source disk is not mounted or the logical is not defined, then these SYSMLINKs will not work. We may have to consider all possible scenarios with BACKUP.

Regards,
Ketan

[Robert Gezelter]

Murali,

Re-reading my posting from last night (NYC time), I realize that I was not explicit about my thoughts on this question.

The summary on my previous posting should be:

There should be a patch kit generated for 8.3 (and perhaps earlier releases) that "corrects" the behavior of symlinks to the 8.4 behavior. Following the installation of the previously described patch to the old system, it is possible to do the (potentially) laborious process of upgrading the symlinks BEFORE the upgrade to 8.4, avoiding the potential for downtime while the symlinks are upgraded.

Thus, the sequence for upgrade is:
- install patch (which will correct all future symlinks)
- perform an ANALYZE/DISK_STRUCTURE with appropriate qualifiers on each disk that has ANY symlinks
- Upgrade to 8.4

With a large, active system, there could be an extended period of time between the second and the third steps.

- Bob Gezelter, http://www.rlgsc.com

[Craig A Berry]

Bob's proposed sequence to get 8.3 systems up to 8.4-compatible symlinks:

> - install patch (which will correct all future symlinks)
> - perform an ANALYZE/DISK_STRUCTURE with appropriate qualifiers on each disk that has ANY symlinks
> - Upgrade to 8.4

If that first step ("install patch...") means what I think it means, I'm not sure it's such a good idea. You'd basically just be moving the problem backward so you'd have v8.3 systems with the patch and v8.3 systems without the patch with two different types of symlink being produced. And depending on what the patch includes (a full backport of the v8.4 symlink implementation?) you'd have a relatively high risk patch touching delicate areas of the file system, the CRTL, perhaps various utilities, etc. And if it all works perfectly you end up with three versions of symlinks to support: v8.3, v8.3+, and v8.4. Such things have been done before, such as with XQP+ in the 5.x era (or was it 6.x?), but I'm not sure it's worth the risk.

That said, I fully agree that a better pre-upgrade option and some sort of strong encouragement in the upgrade procedure itself would be in order.

[Robert Gezelter]

Craig,

My comment about the patch was meant to be very limited, and tied to the previous comment that the VERIFY could be run on 8.3 to set the bits and nothing else.

Admittedly using the comments made in the thread as a basis, it would seem that the bit setting is highly localized. Thus, I am not suggesting "the whole 8.4 symlink" implementation. I am only suggesting two images: the routine used to create a symlink with both bits and the VERIFY.EXE image from 8.4.

Rest assured. If there was a large modification to 8.3, I would not even raise the possibility.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Craig,

A small further clarification on my last clarification.

The "patch" kit that I am proposing is not a mandatory patch, it is an elective patch kit for those who need to maintain 7x24x366 availability.

The problem with upgrading to 8.4 and running the ANALYZE/DISK_STRUCTURE is that any applications using symlinks may be challenged until the ANALYZE completes. With the hypothetical patch kit, the ANALYZE could be run on a background basis (according to Murali, there is no qualification issue with using an upgraded volume with an 8.3 system; the problem is the reverse).

- Bob Gezelter, http://www.rlgsc.com

[P Muralidhar Kini]

Craig,
>> Hmm. What about on v8.3? I don't have v8.4 handy at the moment.
>> It's possible it's been fixed, though it's also possible you have
>> to unmount and remount the volume after setting /NOWRITETHROUGH.
Even on V83 system, i was not able to reproduce the problem.
The attached file has test results.

Robert,
>> The problem with upgrading to 8.4 and running the ANALYZE/DISK_STRUCTURE
>> is that any applications using symlinks may be challenged until the
>> ANALYZE completes
Yes, thats a good point.
With larger disk sizes, the time taken by the ANAL/DISK to complete its work
would be longer. Hence customers don't tend to run this during production
hours but instead would wait till any maintainence window becomes available
to perform such tasks.

>> (according to Murali, there is no qualification issue with using
>> an upgraded volume with an 8.3 system; the problem is the reverse).
Yes, thats correct.

I have also made a note about the problem mentioned in
http://h30499.www3.hp.com/t5/Languages-and-Scripting/Unexpected-ODS5-wildcard-file-spec-result/m-p/4531916#M6938

Regards,
Murali

[Craig A Berry]

Murali wrote:
>>>
Craig,
>> Hmm. What about on v8.3? I don't have v8.4 handy at the moment.
>> It's possible it's been fixed, though it's also possible you have
>> to unmount and remount the volume after setting /NOWRITETHROUGH.
Even on V83 system, i was not able to reproduce the problem.
The attached file has test results.
>>>

Murali, thanks for trying. I see you are testing on a SCSI disk. I can reproduce it 100% of the time on a SAN volume, but not on an LDDriver volume. Makes me wonder if it's a timing problem encountered only on faster storage and the volume characteristics were a red herring.