VOS_RELEASE(1)

📦
version 1.8.16.1 · 10 versions
, in ubuntu stonking

💖 VOS_RELEASE(1) 💖

okay bestie, welcome to the AFS Command Reference — this is the vos release page and it's literally the glow-up command for your read-only volumes 💅✨

✨ NAME ✨

vos_release — updates read-only volumes to match the read/write source volume 🦋

🎀 SYNOPSIS 🎀

vos release -id <volume name or ID>
    [-force] [-force-reclone]
    [-cell <cell name>]
    [-noauth] [-localauth]
    [-verbose] [-encrypt] [-noresolve]
    [-config <config directory>]
    [-help]

vos rel -i <volume name or ID>
    [-force] [-force-r]
    [-c <cell name>]
    [-noa] [-l] [-v] [-e] [-nor]
    [-co <config directory>]
    [-h]

🌸 DESCRIPTION 🌸

so vos release copies the contents of the read/write source volume you point at into every single read-only site that's defined in that source volume's Volume Location Database (VLDB) entry. no cap. (def use vos addsite to define sites first if you haven't, bestie — the command is not gonna invent them for you). every read-only copy gets the exact same name as the read/write source, just with a ".readonly" extension tacked on the end. periodt.

for users to have a consistent view of the file system, the release of the new volume version has to be atomic: either all read-only sites get the new version, or all sites keep the version they currently have. it's giving all-or-nothing, and honestly iconic of it. vos release is built to make sure every copy of the volume's read-only version matches both the read/write source and each other. but when stuff goes sideways — machine outages, server process outages, the usual chaos 😭 — and the release can't finish, AFS uses two mechanisms to flag it for the administrator.

  1. The command interpreter spits an error message out on the standard error stream, naming each read-only site that didn't receive the new volume version.
  2. During the release operation, the Volume Location (VL) Server marks site definitions in the VLDB entry with flags ("New release" and "Old release") that say whether or not the site has the new volume version.

if any flags are still hanging around after the operation completes, it did not succeed, sorry bestie. and here's the spicy bit: the Cache Manager refuses to access a read-only site marked with the "Old release" flag, which can dump a whole lot more load onto the sites marked "New release". so yeah — investigate and eliminate the cause of the failure, then run vos release as many times as it takes to complete the release with zero errors. slay.

the pattern of site flags left behind in the volume's VLDB entry after a failed release can actually help you figure out where the operation died. use vos examine or vos listvldb to display the VLDB entry. the VL Server sets the flags in concert with the Volume Server's operations, like this:

  • Before the operation begins, the VL Server sets the "New release" flag on the read/write site definition in the VLDB entry and the "Old release" flag on read-only site definitions (unless the read-only site has been defined since the last release operation and has no actual volume, in which case its site flag stays "Not released").
  • If necessary, the Volume Server creates a temporary copy (a clone) of the read/write source called the ReleaseClone (there's more on when it does or doesn't make a new one below 👇). It assigns the ReleaseClone its own volume ID number, which the VL Server records in the "RClone" field of the source volume's VLDB entry.
  • The Volume Server distributes a copy of the ReleaseClone to each read-only site defined in the VLDB entry. As each site successfully receives the new clone, the VL Server sets that site's flag in the VLDB entry to "New release".
  • When all the read-only copies are successfully released, the VL Server clears all the "New release" site flags. The ReleaseClone isn't needed anymore, so the Volume Server deletes it and the VL Server erases its ID from the VLDB entry. bye queen 💅

by default, the Volume Server figures out on its own whether or not it needs to create a new ReleaseClone:

  • If there are no flags ("New release", "Old release", or "Not released") on any site definition in the VLDB entry, that means the previous vos release completed successfully and all read-only sites currently have the same volume. The Volume Server infers the current vos release was issued because the read/write volume changed. So it creates a new ReleaseClone volume and distributes a copy of the clone volume to all the read-only sites. To keep the amount of data transferred down during a release, the Volume Server sends incremental changes to remote sites during the release — it only sends files and directories that have been changed in the read/write volume since the previous release. efficient queen ✨
  • If any site definition in the VLDB entry is marked with a flag, then either the previous release didn't complete successfully or a new read-only site was defined since the last release. The Volume Server does not create a new ReleaseClone — instead it distributes the entire existing ReleaseClone to sites marked with the "Old release" or "Not released" flag. And as noted up top, the VL Server marks each VLDB site definition with the "New release" flag as that site receives the ReleaseClone, then clears all flags once every site has successfully received it.

want to override the default behavior and force the Volume Server to create and release a fresh ReleaseClone to the read-only sites? add the -force flag, bestie. that's the move when, say, the data at the read/write site has changed since the existing ReleaseClone was created during the previous release operation.

and -force-reclone will force the creation of a new release clone volume, but it will not force a full volume dump to be sent out to the remote sites. instead, incremental changes will be distributed when possible. so it's the gentle version of forcing 🫶

💅 OPTIONS 💅

  • -id <volume name or id> — specifies either the complete name or the volume ID number of a read/write volume. this one's not optional, it's the whole point 😌
  • -force — creates a new ReleaseClone and distributes the entire clone volume to all read-only sites, regardless of the "New release", "Old release", or "Not released" site flags. full send 🔥
  • -force-reclone — creates a new ReleaseClone and incrementally distributes the clone volume to all read-only sites, regardless of the "New release", "Old release", or "Not released" site flags. new clone, but no mandatory full dump 💖
  • -cell <cell name> — names the cell in which to run the command. do NOT combine this argument with the -localauth flag. for more details, see vos(1).
  • -noauth — assigns the unprivileged identity "anonymous" to the issuer. do NOT combine this flag with the -localauth flag. for more details, see vos(1).
  • -localauth — constructs a server ticket using a key from the local /etc/openafs/server/KeyFile file. the vos command interpreter presents it to the Volume Server and Volume Location Server during mutual authentication. do NOT combine this flag with the -cell argument or the -noauth flag. for more details, see vos(1).
  • -verbose — produces a detailed trace of the command's execution on the standard output stream. if this argument is omitted, only warnings and error messages show up. so if you're nosy (same), this is your flag 👀
  • -encrypt — encrypts the command so the operation's results are not transmitted across the network in clear text. this option is available in OpenAFS versions 1.4.11 or later and 1.5.60 or later.
  • -noresolve — shows all servers as IP addresses instead of the DNS name. super useful when the server address is registered as 127.0.0.1, or when you're dealing with multi-homed servers. this option is available in OpenAFS versions 1.4.8 or later and 1.5.35 or later.
  • -config <configuration directory> — sets the location of the configuration directory to be used. this defaults to /etc/openafs, except if -localauth is specified, in which case the default is /etc/openafs/server. this option allows the use of alternative configuration locations for testing purposes 🧪
  • -help — prints the online help for this command. all other valid options are ignored. it said what it said 🙈

⭐ EXAMPLES ⭐

this command clones the read/write volume usr and releases it to the read-only sites defined in its VLDB entry:

% vos release usr

look at her go 🎀

👑 PRIVILEGE REQUIRED 👑

the issuer must be listed in the /etc/openafs/server/UserList file on the machine specified with the -server argument and on each database server machine. if the -localauth flag is included, the issuer must instead be logged on to a server machine as the local superuser "root". no shortcuts, bestie 💜

🌈 SEE ALSO 🌈

vos(1), vos_addsite(1), vos_examine(1), vos_listvldb(1)

IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.

This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.

okay that's the whole page, bestie, you ate it 💖 this was OpenAFS, dated 2026-07-27 — go forth and release those volumes, mwah 🫶✨

📦 where this page comes from