JOHNC%CAD2.DECnet@GE-CRD.ARPA.UUCP (04/14/87)
More on Volume Sets: Several writers have discussed the pros of volume sets: larger files, more spindles, fewer device names to remember, less confusion about "where" another user's directory is. Several have also mentioned some cons: longer backups, more data (the whole volume set) unavailable when a disk fails, difficult to break up into separate volumes w/out "n" free volumes, where "n" is the size of the volume set. I haven't read anything about what I believe is the worst problem with volume sets: When a disk fails not only is all data on the volume set unavailable, but the entire volume set has to be restored from backup when the failed disk is repaired or replaced. Other vendors (like IBM or Honeywell) don't make you do this: when a disk in a pool fails then any file which is on that disk (all or part of the file) is unavailable, but the rest of the pool functions normally. When the disk is replaced or repaired it is restored from tape; but only the files which were actually on that volume have to be reloaded. If volume sets worked better I would certainly use them - but the failure rate of RA81's being what it is I don't want to put more than the disk's 456 meg of data at risk of a single device failure. > ...the solution to the "problem" is to define a logical name which is a > search list of all the mounted disk volumes in the public file structures: > > $define usr$disks usr$disk1:,usr$disk2:,usr$disk3:,usr$disk4: > > Thus anyone can locate anyone elses file by using the usr$disks logical > name as the "device" specification. This assumes that a person only has > a single top-level directory on the set of disks listed in usr$disks; > this does not seem to be much of a restriction. Nope. This _doesn't_ work correctly either. Search lists do their thing fine for read access; but if you want to write to, for example, usr$disks:[sample]xxx.dat it will fail unless the [sample] directory is in the first volume of the volume set. I'd use this, too, if it worked better. Does anyone from DEC know whether this unfortunate behavior is going to be altered in a future release? Virtual Memory = not memory John Child Virtually Empty = not empty General Electric Virtually Foolproof = not foolproof Aircraft Engines Virtual Machine = software Lynn MA