Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
vinum(8)                FreeBSD System Manager's Manual               vinum(8)

NAME
     vinum - Logical Volume Manager control program

SYNOPSIS
     vinum [command] [-options]

COMMANDS
     create [-f description-file] Create a volume as described in
     description-file attach plex volume [rename] attach subdisk plex [offset]
     [rename] Attach a plex to a volume, or a subdisk to a plex.  debug Cause
     the volume manager to enter the kernel debugger.  debug flags Set
     debugging flags.  detach [plex | subdisk] Detach a plex or subdisk from
     the volume or plex to which it is attached.  info [-v] List information
     about volume manager state.  init [-v] [-w] plex Initialize a plex by
     writing zeroes to all its subdisks.  label volume Create a volume label
     list [-r] [-s] [-v] [-V] [volume | plex | subdisk] List information about
     specified objects l [-r] [-s] [-v] [-V] [volume | plex | subdisk] List
     information about specified objects (alternative to list command) ld [-r]
     [-s] [-v] [-V] [volume] List information about drives ls [-r] [-s] [-v]
     [-V] [subdisk] List information about subdisks lp [-r] [-s] [-v] [-V]
     [plex] List information about plexes lv [-r] [-s] [-v] [-V] [volume] List
     information about volumes printconfig [file] Write a copy of the current
     configuration to file.  makedev Remake the device nodes in /dev/vinum.
     quit Exit the vinum program when running in interactive mode.  Normally
     this would be done by entering the EOF character.  read disk [disk...]
     Read the vinum configuration from the specified disks.  rename [-r]
     [drive | subdisk | plex | volume] newname Change the name of the
     specified object.  resetconfig Reset the complete vinum configuration.
     resetstats [-r] [volume | plex | subdisk] Reset statistisc counters for
     the specified objects, or for all objects if none are specified.  rm [-f]
     [-r] volume | plex | subdisk Remove an object saveconfig Save vinum
     configuration to disk.  setdaemon [value] Set daemon configuration.
     start Read configuration from all vinum drives.  start [volume | plex |
     subdisk] Allow the system to access the objects stop [-f] [volume | plex
     | subdisk] Terminate access to the objects, or stop vinum if no
     parameters are specified.

DESCRIPTION
     vinum is a utility program to communicate with the Vinum logical volume
     manager.  See vinum(4) for more information about the volume manager.
     vinum(8) is designed either for interactive use, when started without a
     command, or to execute a single command if the command is supplied as
     arguments to vinum.  In interactive mode, vinum maintains a command line
     history.

   OPTIONS
     vinum commands may optionally be followed by an option.  Any of the
     following options may be specified with any command, but in some cases
     they do not make any difference: cases, the options are ignored.  For
     example, the stop command ignores the -v and -V options.

     -f      The -f ("force") option overrides safety checks.  Use with
             extreme care.  This option is for emergency use only.  For
             example, the command

                   rm -f myvolume

             removes myvolume even if it is open.  Any subsequent access to
             the volume will almost certainly cause a panic.

     -r      The -r ("recursive") option is used by the list commands to
             display information not only about the specified objects, but
             also about subordinate objects.  For example, in conjnction with
             the lv command, the -r option will also show information about
             the plexes and subdisks belonging to the volume.

     -s      The -s ("statistics") option is used by the list commands to
             display statistical information.

     -v      The -v ("verbose") option can be used with any command to request
             more detailed information.

     -V      The -V ("Very verbose") option can be used with any command to
             request more detailed information than the -v option provides.

     -w      The -w ("wait") option tells vinum to wait for completion of
             commands which normally run in the background, such as init.

   COMMANDS IN DETAIL
     vinum commands perform the following functions:

     attach plex volume [rename]
     attach subdisk plex [offset] [rename]

             vinum attach inserts the specified plex or subdisk in a volume or
             plex.  In the case of a subdisk, an offset in the plex may be
             specified.  If it is not, the subdisk will be attached at the
             first possible location.  After attaching a plex to a non-empty
             volume, vinum reintegrates the plex.

             If the keyword rename is specified, vinum renames the object (and
             in the case of a plex, any subordinate subdisks) to fit in with
             the default vinum naming convention.

             A number of considerations apply to attaching subdisks:

             +o   Subdisks can normally only be attached to concatenated
                 plexes.

             +o   If a striped or RAID-5 plex is missing a subdisk (for example
                 after drive failure), it may be replaced by a subdisk of the
                 same size only.  No other attachment of subdisks is currently
                 allowed.

             +o   For concatenated plexes, the offset parameter specifies the
                 offset in blocks from the beginning of the plex.  For striped
                 and RAID-5 plexes, it specifies the offset of the first block
                 of the subdisk: in other words, the offset is the numerical
                 position of the subdisk multiplied by the stripe size.  For
                 example, in a plex of block size 256k, the first subdisk will
                 have offset 0, the second offset 256k, the third 512k, etc.
                 This calculation ignores parity blocks in RAID-5 plexes.

     create [-f description-file]

             vinum create is used to create any object.  In view of the
             relatively complicated relationship and the potential dangers
             involved in creating a vinum object, there is no interactive
             interface to this function.  If you do not specify a file name,
             vinum starts an editor on a temporary file.  If the environment
             variable EDITOR is set, vinum starts this editor.  If not, it
             defaults to vi.  See the section CONFIGURATION FILE below for
             more information on the format of this file.

             Note that the vinum create function is additive: if you run it
             multiple times, you will create multiple copies of all unnamed
             objects.

             Normally the create command will not change the names of existing
             vinum drives, in order to avoid accidentally erasing them.  The
             correct way to dispose of no longer wanted vinum drives is to
             reset the configuration with the resetconfig command.  In some
             cases, however, it may be necessary to create new data on vinum
             drives which can no longer be started.  In this case, use the
             create -f command.

     debug

             vinum debug is used to enter the remote kernel debugger.  It is
             only activated if vinum is built with the VINUMDEBUG option.
             This option will stop the execution of the operating system until
             the kernel debugger is exited.  If remote debugging is set and
             there is no remote connection for a kernel debugger, it will be
             necessary to reset the system and reboot in order to leave the
             debugger.

     debug   flags

             Set a bit mask of internal debugging flags.  These will change
             without warning as the product matures; to be certain, read the
             header file sys/dev/vinumvar.h.  The bit mask is composed of the
             following values:

             DEBUG_ADDRESSES (1)
                     Show buffer information during requests

             DEBUG_NUMOUTPUT (2)
                     Show the value of vp->v_numoutput.

             DEBUG_RESID (4)
                     Go into debugger in complete_rqe.

             DEBUG_LASTREQS (8)
                     Keep a circular buffer of last requests.

             DEBUG_REVIVECONFLICT (16)
                     Print info about revive conflicts.

             DEBUG_EOFINFO (32)
                     Print information about internal state when returning an
                     EOF on a striped plex.

             DEBUG_MEMFREE (64)
                     Maintain a circular list of the last memory areas freed
                     by the memory allocator.

             DEBUG_REMOTEGDB (256)
                     Go into remote gdb when the debug command is issued.

             DEBUG_WARNINGS (512)
                     Print some warnings about minor problems in the
                     implementation.

     detach [-f] plex
     detach [-f] subdisk

             vinum detach removes the specified plex or subdisk from the
             volume or plex to which it is attached.  If removing the object
             would impair the data integrity of the volume, the operation will
             fail unless the -f option is specified.  If the object is named
             after the object above it (for example, subdisk vol1.p7.s0
             attached to plex vol1.p7), the name will be changed by prepending
             the text "ex-" (for example, ex-vol1.p7.s0).  If necessary, the
             name will be truncated in the process.

             detach does not reduce the number of subdisks in a striped or
             RAID-5 plex.  Instead, the subdisk is marked absent, and can
             later be replaced with the attach command.

     info
             vinum info displays information about vinum memory usage.  This
             is intended primarily for debugging.  With the -v option, it will
             give detailed information about the memory areas in use.

             With the -V option, info displays information about the last up
             to 64 I/O requests handled by the vinum driver.  This information
             is only collected if debug flag 8 is set.  The format looks like:

             vinum -> info -V
             Flags: 0x200    1 opens
             Total of 38 blocks malloced, total memory: 16460
             Maximum allocs:       56, malloc table at 0xf0f72dbc

             Time             Event       Buf        Dev     Offset          Bytes   SD      SDoff   Doffset Goffset

             14:40:00.637758 1VS Write 0xf2361f40    0x5b03  0x10            16384
             14:40:00.639280 2LR Write 0xf2361f40    0x5b03  0x10            16384
             14:40:00.639294 3RQ Read  0xf2361f40    0x427   0x104109        8192    19      0       0       0
             14:40:00.639455 3RQ Read  0xf2361f40    0x417   0xd2109         8192    17      0       0       0
             14:40:00.639529 3RQ Read  0xf2361f40    0x40f   0x6e109         8192    16      0       0       0
             14:40:00.652978 4DN Read  0xf2361f40    0x427   0x104109        8192    19      0       0       0
             14:40:00.667040 4DN Read  0xf2361f40    0x40f   0x6e109         8192    16      0       0       0
             14:40:00.668556 4DN Read  0xf2361f40    0x417   0xd2109         8192    17      0       0       0
             14:40:00.669777 6RP Write 0xf2361f40    0x427   0x104109        8192    19      0       0       0
             14:40:00.685547 4DN Write 0xf2361f40    0x427   0x104109        8192    19      0       0       0

             The Buf field always contains the address of the user buffer
             header.  This can be used to identify the requests associated
             with a user request, though this is not 100% reliable:
             theoretically two requests in sequence could use the same buffer
             header, though this is not common.  The beginning of a request
             can be identified by the event 1VS.  The example above shows the
             requests involved in a single user request.

             The Event field contains information related to the sequence of
             events in the request chain.  The digit 1 to 6 indicates the
             approximate sequence of events, and the two-letter abbreviation
             is a mnemonic for the location

             1VS     (vinumstrategy) shows information about the user request
                     on entry to vinumstrategy .
                     The device number is the vinum device, and offset and
                     length are the user parameters.  This is always the
                     beginning of a request sequence.

             2LR     (launch_requests) shows the user request just prior to
                     launching the low-level vinum requests in the function
                     launch_requests.
                     The parameters should be the same as in the 1VS
                     information.

                     In the following requests, Dev is the device number of
                     the associated disk partition, Offset is the offset from
                     the beginning of the partition, SD is the subdisk index
                     in vinum_conf, SDoff is the offset from the beginning of
                     the subdisk, Doffset is the offset of the associated data
                     request, and Goffset is the offset of the associated
                     group request, where applicable.

             3RQ     (request) shows one of possibly several low-level vinum
                     requests which are launched to satisfy the high-level
                     request.  This information is also logged in
                     launch_requests.

             4DN     (done) is called from complete_rqe,
                     showing the completion of a request.  This completion
                     should match a request launched either at stage 4DN from
                     launch_requests,
                     or from complete_raid5_write
                     at stage 5RD or 6RP.

             5RD     (RAID-5 data) is called from complete_raid5_write
                     and represents the data written to a RAID-5 data stripe
                     after calculating parity.

             6RP     (RAID-5 parity) is called from complete_raid5_write
                     and represents the data written to a RAID-5 parity stripe
                     after calculating parity.

     init [-w] plex

             vinum init initializes a plex by writing zeroes to all its
             subdisks.  This is the only way to ensure consistent data in a
             plex.  You must perform this initialization before using a RAID-5
             plex.  It is also recommended for other new plexes.  vinum
             initializes all subdisks of a plex in parallel.  Since this
             operation can take a long time, it is normally performed in the
             background.  If you want to wait for completion of the command,
             use the -w (wait) option.  vinum prints a console message when
             the initialization is complete.

     label   volume

             The label command writes a ufs style volume label on a volume.
             It is a simple alternative to an appropriate call to disklabel.
             This is needed because some ufs commands still read the disk to
             find the label instead of using the correct ioctl call to access
             it.  vinum maintains a volume label separately from the volume
             data, so this command is not needed for newfs.  This command is
             deprecated.

     list    [-r] [-V] [volume | plex | subdisk]
     l       [-r] [-V] [volume | plex | subdisk]
     ld      [-r] [-s] [-v] [-V] [volume]
     ls      [-r] [-s] [-v] [-V] [subdisk]
     lp      [-r] [-s] [-v] [-V] [plex]
     lv      [-r] [-s] [-v] [-V] [volume]

             list is used to show information about the specified object.  If
             the argument is omitted, information is shown about all objects
             known to vinum.  The l command is a synonym for list.

             The -r option relates to volumes and plexes: if specified, it
             recursively lists information for the subdisks and (for a volume)
             plexes subordinate to the objects.  The commands lv, lp, ls and
             ld commands list only volumes, plexes, subdisks and drives
             respectively.  This is particularly useful when used without
             parameters.

             The -s option causes vinum to output device statistics, the [-v]
             (verbose) option causes some additional information to be output,
             and the [-V] causes considerable additional information to be
             output.

     makedev
             The makedev command removes the directory /dev/vinum and
             recreates it with device nodes which reflect the current
             configuration.  This command is not intended for general use, and
             is provided for emergency use only.

     quit    Exit the vinum program when running in interactive mode.
             Normally this would be done by entering the EOF character.

     printconfig [file] Write a copy of the current configuration to file in a
             format that can be used to recreate the vinum configuration.
             Unlike the configuration saved on disk, it includes definitions
             of the drives.  If you omit file, vinum writes the list to
             stdout.

     read    disk [disk...]

             The read command scans the specified disks for vinum partitions
             containing previously created configuration information.  It
             reads the configuration in order from the most recently updated
             to least recently updated configuration.  vinum maintains an up-
             to-date copy of all configuration information on each disk
             partition.  You must specify all of the slices in a configuration
             as the parameter to this command.

             The read command is intended to selectively load a vinum
             configuration on a system which has other vinum partitions.  If
             you want to start all partitions on the system, it is easier to
             use the start command.

             If vinum encounters any errors during this command, it will turn
             off automatic configuration update to avoid corrupting the copies
             on disk.  This will also happen if the configuration on disk
             indicates a configuration error (for example, subdisks which do
             not have a valid space specification).  You can turn the updates
             on again with the setdaemon and saveconfig commands.  Reset bit 4
             of the daemon options mask to re-enable configuration saves.

     rename  [-r] [drive | subdisk | plex | volume] newname

             Change the name of the specified object.  If the -r option is
             specified, subordinate objects will be named by the default
             rules: plex names will be formed by appending .pnnuummbbeerr to the
             volume name, and subdisk names will be formed by appending
             .snnuummbbeerr to the plex name.

     replace [subdisk | plex] newobject

             Replace the object with an identical other object.  This command
             has not yet been implemented.

     resetconfig

             The resetconfig command completely obliterates the vinum
             configuration on a system.  Use this command only when you want
             to completely delete the configuration.  vinum will ask for
             confirmation: you must type in the words NO FUTURE exactly as
             shown:

                   # vinum resetconfig

                   WARNING!  This command will completely wipe out your vinum
                   configuration.  All data will be lost.  If you really want
                   to do this, enter the text

                   NO FUTURE
                   Enter text -> NNOO FFUUTTUURREE
                   Vinum configuration obliterated

             As the message suggests, this is a last-ditch command.  Don't use
             it unless you have an existing configuration which you never want
             to see again.

     resetstats [-r] [volume | plex | subdisk]

             vinum maintains a number of statistical counters for each object.
             See the header file for more information.  Use the resetstats
             command to reset these counters.  In conjunction with the -r
             option, vinum also resets the counters of subordinate objects.

     rm      [-f] [-r] volume | plex | subdisk

             rm removes an object from the vinum configuration.  Once an
             object has been removed, there is no way to recover it.  Normally
             vinum performs a large amount of consistency checking before
             removing an object.  The -f option tells vinum to omit this
             checking and remove the object anyway.  Use this option with
             great care: it can result in total loss of data on a volume.

             Normally, vinum refuses to remove a volume or plex if it has
             subordinate plexes or subdisks respectively.  You can tell vinum
             to remove the object anyway by using the -f flag, or you can
             cause vinum to remove the subordinate objects as well by using
             the -r (recursive) flag.  If you remove a volume with the -r
             flag, it will remove both the plexes and the subdisks which
             belong to the plexes.

     saveconfig

             Save the current configuration to disk.  This is primarily a
             maintenance function.  For example, if an error occurs on
             startup, updates will be disabled.  When you reenable them, the
             configuration is not automatically saved to disk.  Use this
             command to save the configuration.

     setdaemon [value]

             setdaemon sets a variable bitmask for the vinum daemon.  This
             command is temporary and will be replaced.  Currently, the bit
             mask may contain the bits 1 (log every action to syslog) and 4
             (don't update configuration).  Option bit 4 can be useful for
             error recovery.

     start   [volume | plex | subdisk]

             start starts (brings into to the up state) one or more vinum
             objects.

             If no object names are specified, vinum scans the disks known to
             the system for vinum drives and then reads in the configuration
             as described under the read commands.  The vinum drive contains a
             header with all information about the data stored on the drive,
             including the names of the other drives which are required in
             order to represent plexes and volumes.

             If vinum encounters any errors during this command, it will turn
             off automatic configuration update to avoid corrupting the copies
             on disk.  This will also happen if the configuration on disk
             indicates a configuration error (for example, subdisks which do
             not have a valid space specification).  You can turn the updates
             on again with the setdaemon and saveconfig command.  Reset bit 4
             of the daemon options mask to re-enable configuration saves.

             If object names are specified, vinum starts them.  Normally this
             operation is only of use with subdisks.  The action depends on
             the current state of the object:

             +o   If the object is already in the up state, vinum does nothing.

             +o   If the object is a subdisk in the down or reborn states,
                 vinum changes it to the up state.

             +o   If the object is a subdisk in the empty state, the change
                 depends on the subdisk.  If it is part of a plex which is
                 part of a volume which contains other plexes, vinum places
                 the subdisk in the reviving state and attempts to copy the
                 data from the volume.  When the operation completes, the
                 subdisk is set into the up state.  If it is part of a plex
                 which is part of a volume which contains no other plexes, or
                 if it is not part of a plex, vinum brings it into the up
                 state immediately.

             +o   If the object is a subdisk in the reviving state, vinum
                 continues the revive operation offline.  When the operation
                 completes, the subdisk is set into the up state.

             When a subdisk comes into the up state, vinum automatically
             checks the state of any plex and volume to which it may belong
             and changes their state where appropriate.

             If the object is a volume or a plex, start currently has no
             effect: it checks the state of the subordinate subdisks (and
             plexes in the case of a volume) and sets the state of the object
             accordingly.  In a later version, this operation will cause the
             subdisks

             To start a plex in a multi-plex volume, the data must be copied
             from another plex in the volume.  Since this frequently takes a
             long time, it is done in the background.

     stop    [-f] [volume | plex | subdisk]

             If no parameters are specified, stop removes the vinum kld and
             stops vinum(8).  This can only be done if no objects are active,
             In particular, the -f flag does not override this requirement.
             This command can only work if vinum has been loaded as a kld,
             since it is not possible to unload a statically configured
             driver.  vinum stop will fail if vinum is statically configured.

             If object names are specified, stop disables access to the
             objects.  If the objects have  subordinate objects, they
             subordinate objects must either already be inactive (stopped or
             in error), or the -r and -f flags must be specified.  This
             command does not remove the objects from the configuration.  They
             can be accessed again after a start command.

             By default, vinum does not stop active objects.  For example, you
             cannot stop a plex which is attached to an active volume, and you
             cannot stop a volume which is open.  The -f option tells vinum to
             omit this checking and remove the object anyway.  Use this option
             with great care and understanding: used incorrectly, it can
             result in serious data corruption.

   CONFIGURATION FILE
     vinum requires that all parameters to the create commands must be in a
     configuration file.  Entries in the configuration file define volumes,
     plexes and subdisks, and may be in free format, except that each entry
     must be on a single line.

     Some configuration file parameters specify a size (lengths, stripe
     sizes).  These lengths can be specified as bytes, as sectors of 512 bytes
     (by appending the letter s), as kilobytes (by appending the letter k), as
     megabytes (by appending the letter m) or as gigabytes (by appending the
     letter g).  These quantities represent the values 2**10, 2**20 and 2**30
     respectively.  For example, the value 16777216 bytes can also be written
     as 16m, 16384k or 32768b.

     For reasons of compatibility, vinum takes the letter b (block) to be
     equivalent to s (sector).  The use of this abbreviation is deprecated,
     since the size of a block is very dependent on the context.

     The configuration file can contain the following entries:

     drive name option

           Define a drive.  The option must be:

           device devicename   Specify the device on which the drive resides.
                               devicename must be the name of a disk
                               compatibility partition, for example /dev/da1e
                               or /dev/wd3h, and it should be of type vinum.
                               Do not use the c partition, which is reserved
                               for the complete disk, and should be of type
                               unused.  It is currently possible to create
                               drives on other disk devices, for example
                               /dev/da0s1 or /dev/da0s1e, but it will not be
                               possible to start these drives after a reboot.

     volume name [options]

           Define a volume with name name.

           Options are:

           plex plexname       Add the specified plex to the volume.  If
                               plexname is specified as *, vinum will look for
                               the definition of the plex as the next possible
                               entry in the configuration file after the
                               definition of the volume.

           readpol policy      Define a read policy for the volume.  policy
                               may be either round or prefer plexname.  vinum
                               satisfies a read request from only one of the
                               plexes.  A round read policy specifies that
                               each read should be performed from a different
                               plex in round-robin fashion.  A prefer read
                               policy reads from the specified plex every
                               time.

           setupstate

                               When creating a multi-plex volume, assume that
                               the contents of all the plexes are consistent.
                               This is normally not the case, and correctly
                               you should use the init command to first bring
                               them to a consistent state.  In the case of
                               striped and concatenated plexes, however, it
                               does not normally cause problems to leave them
                               inconsistent: when using a volume for a file
                               system or a swap partition, the previous
                               contents of the disks are not of interest, so
                               they may be ignored.  If you want to take this
                               risk, use this keyword.  It will only apply to
                               the plexes defined immediately after the volume
                               in the configuration file.  If you add plexes
                               to a volume at a later time, you must integrate
                               them.

                               Note that you must use the init command with
                               RAID-5 plexes: otherwise extreme data
                               corruption will result if one subdisk fails.

     plex [options]

           Define a plex.  Unlike a volume, a plex does not need a name.  The
           options may be:

           name plexname       Specify the name of the plex.  Note that you
                               must use the keyword name when naming a plex or
                               subdisk.

           org organization [stripesize]

                               Specify the organization of the plex.
                               organization can be one of concat, striped or
                               raid5.  For striped and raid5 plexes, the
                               parameter stripesize must be specified, while
                               for concat it must be omitted.  For type
                               striped, it specifies the width of each stripe.
                               For type raid5, it specifies the size of a
                               group.  A group is a portion of a plex which
                               stores the parity bits all in the same subdisk.
                               It must be a factor of the plex size (in other
                               words, the result of dividing the plex size by
                               the stripe size must be an integer), and it
                               must be a multiple of a disk sector (512
                               bytes).

                               For optimum performance, stripes should be at
                               least 128 kB in size: anything smaller will
                               result in a significant increase in I/O
                               activity due to mapping of individual requests
                               over multiple disks.  The performance
                               improvement due to the increased number of
                               concurrent transfers caused by this mapping
                               will not make up for the performance drop due
                               to the increase in latency.  A good guideline
                               for stripe size is between 256 kB and 512 kB.

                               A striped plex must have at least two subdisks
                               (otherwise it is a concatenated plex), and each
                               must be the same size.  A RAID-5 plex must have
                               at least three subdisks, and each must be the
                               same size.  In practice, a RAID-5 plex should
                               have at least 5 subdisks.

           volume volname      Add the plex to the specified volume.  If no
                               volume keyword is specified, the plex will be
                               added to the last volume mentioned in the
                               configuration file.

           sd sdname offset    Add the specified subdisk to the  plex at
                               offset offset.

     subdisk [options]

           Define a subdisk.  Options may be:

           name name           Specify the name of a subdisk.  It is not
                               necessary to specify a name for a subdisk--see
                               OBJECT NAMING above.  Note that you must
                               specify the keyword name if you wish to name a
                               subdisk.

           plexoffset offset   Specify the starting offset of the subdisk in
                               the plex.  If not specified, vinum allocates
                               the space immediately after the previous
                               subdisk, if any, or otherwise at the beginning
                               of the plex.

           driveoffset offset  Specify the starting offset of the subdisk in
                               the drive.  If not specified, vinum allocates
                               the first contiguous length bytes of free space
                               on the drive.

           length length       Specify the length of the subdisk.  This
                               keyword must be specified.  There is no
                               default, but the value 0 may be specified to
                               mean "use the largest available contiguous free
                               area on the drive".  If the drive is empty,
                               this means that the entire drive will be used
                               for the subdisk.  length may be shortened to
                               len.

           plex plex           Specify the plex to which the subdisk belongs.
                               By default, the subdisk belongs to the last
                               plex specified.

           drive drive         Specify the drive on which the subdisk resides.
                               By default, the subdisk resides on the last
                               drive specified.

EXAMPLE CONFIGURATION FILE
     # Sample vinum configuration file
     #
     # Our drives
     drive drive1 device /dev/da1h
     drive drive2 device /dev/da2h
     drive drive3 device /dev/da3h
     drive drive4 device /dev/da4h
     drive drive5 device /dev/da5h
     drive drive6 device /dev/da6h
     # A volume with one striped plex
     volume tinyvol
      plex org striped 512b
       sd length 64m drive drive2
       sd length 64m drive drive4
     volume stripe
      plex org striped 512b
       sd length 512m drive drive2
       sd length 512m drive drive4
     # Two plexes
     volume concat
      plex org concat
       sd length 100m drive drive2
       sd length 50m drive drive4
      plex org concat
       sd length 150m drive drive4
     # A volume with one striped plex and one concatenated plex
     volume strcon
      plex org striped 512b
       sd length 100m drive drive2
       sd length 100m drive drive4
      plex org concat
       sd length 150m drive drive2
       sd length 50m drive drive4
     # a volume with a  RAID-5 and a striped plex
     # note that the RAID-5 volume is longer by
     # the length of one subdisk
     volume vol5
      plex org striped 64k
       sd length 1000m drive drive2
       sd length 1000m drive drive4
      plex org raid5 32k
       sd length 500m drive drive1
       sd length 500m drive drive2
       sd length 500m drive drive3
       sd length 500m drive drive4
       sd length 500m drive drive5

   DRIVE LAYOUT CONSIDERATIONS
     vinum drives are currently BSD disk partitions.  They must be of type
     vinum in order to avoid overwriting file systems.  For compatibility
     reasons, vinum currently accepts partitions of type unused, but the next
     release will not allow this kind of partition.  vinum prints a warning
     message when reading a configuration from a partition of type unused.
     Use disklabel -e to edit a partition type definition.  The following
     display shows a typical partition layout as shown by disklabel:

     8 partitions:
     #        size   offset    fstype   [fsize bsize bps/cpg]
       a:    81920   344064    4.2BSD        0     0     0   # (Cyl.  240*- 297*)
       b:   262144    81920      swap                        # (Cyl.   57*- 240*)
       c:  4226725        0    unused        0     0         # (Cyl.    0 - 2955*)
       e:    81920        0    4.2BSD        0     0     0   # (Cyl.    0 - 57*)
       f:  1900000   425984    4.2BSD        0     0     0   # (Cyl.  297*- 1626*)
       g:  1900741  2325984     vinum        0     0     0   # (Cyl. 1626*- 2955*)

     In this example, partition g may be used as a vinum partition.
     Partitions a, e and f may be used as UFS file systems or ccd partitions.
     Partition b is a swap partition, and partition c represents the whole
     disk and should not be used for any other purpose.

     vinum uses the first 265 sectors on each partition for configuration
     information, so the maximum size of a subdisk is 265 sectors smaller than
     the drive.

LOG FILE
     vinum maintains a log file, by default /var/tmp/vinum.history, in which
     it keeps track of the commands issued to vinum.  You can override the
     name of this file by setting the environment variable VINUM_HISTORY to
     the name of the file.

     Each message in the log file is preceded by a date.  The default format
     is %e %b %Y %H:%M:%S See strftime(3) for further details of the format
     string.  It can be overridden by the environment variable
     VINUM_DATEFORMAT.  The date format in th

HOW TO SET UP VINUM
     This section gives practical advice about how to implement a vinum
     system.

   Where to put the data
     The first choice you need to make is where to put the data.  You need
     dedicated disk partitions for vinum.  They should be compatibility
     partitions, not devices or partition c of a slice.  For example, good
     names are /dev/da0e or /dev/wd3a.  Bad names are /dev/da0 and /dev/da0s1,
     both of which represent a device, not a partition, /dev/wd1c, which
     represents a complete disk and should be of type unused, and /dev/da3s0e,
     which is not a compatibility partition.  vinum currently allows you to
     create drives with these names, but the start command will not find them.
     See the example under DRIVE LAYOUT CONSIDERATIONS above.

   Designing volumes
     The way you set up vinum volumes depends on your intentions.  There are a
     number of possibilities:

     1.   You may want to join up a number of small disks to make a reasonable
          sized file system.  For example, if you had five small drives and
          wanted to use all the space for a single volume, you might write a
          configuration file like:

              drive d1 device /dev/da2e
              drive d2 device /dev/da3e
              drive d3 device /dev/da4e
              drive d4 device /dev/da5e
              drive d5 device /dev/da6e
              volume bigger
               plex org concat
                 sd length 0 drive d1
                 sd length 0 drive d2
                 sd length 0 drive d3
                 sd length 0 drive d4
                 sd length 0 drive d5

          In this case, you specify the length of the subdisks as 0, which
          means "use the largest area of free space that you can find on the
          drive".  If the subdisk is the only subdisk on the drive, it will
          use all available space.

     2.   You want to set up vinum to obtain additional resilience against
          disk failures.  You have the choice of RAID-1, also called
          "mirroring", or RAID-5, also called "parity".

          To set up mirroring, create multiple plexes in a volume.  For
          example, to create a mirrored volume of 2 GB, you might create the
          following configuration file:

              drive d1 device /dev/da2e
              drive d2 device /dev/da3e
              volume mirror
               plex org concat
                 sd length 2g drive d1
               plex org concat
                 sd length 2g drive d2

          When creating mirrored drives, it is important to ensure that the
          data from each plex is on a different physical disk so that vinum
          can access the complete address space of the volume even if a drive
          fails.  Note that each plex requires as much data as the complete
          volume: in this example, the volume has a size of 2 GB, but each
          plex (and each subdisk) requires 2 GB, so the total disk storage
          requirement is 4 GB.

          To set up RAID-5, create a single plex of type raid5.  For example,
          to create an equivalent resilient volume of 2 GB, you might use the
          following configuration file:

              drive d1 device /dev/da2e
              drive d2 device /dev/da3e
              drive d3 device /dev/da4e
              drive d4 device /dev/da5e
              drive d5 device /dev/da6e
              volume raid
               plex org raid5 512k
                 sd length 512m drive d1
                 sd length 512m drive d2
                 sd length 512m drive d3
                 sd length 512m drive d4
                 sd length 512m drive d5

          RAID-5 plexes require at least three subdisks, one of which is used
          for storing parity information and is lost for data storage.  The
          more disks you use, the greater the proportion of the disk storage
          can be used for data storage.  In this example, the total storage
          usage is 2.5 GB, compared to 4 GB for a mirrored configuration.  If
          you were to use the minimum of only three disks, you would require 3
          GB to store the information, for example:

              drive d1 device /dev/da2e
              drive d2 device /dev/da3e
              drive d3 device /dev/da4e
              volume raid
               plex org raid5 512k
                 sd length 1g drive d1
                 sd length 1g drive d2
                 sd length 1g drive d3

          As with creating mirrored drives, it is important to ensure that the
          data from each subdisk is on a different physical disk so that vinum
          can access the complete address space of the volume even if a drive
          fails.

     3.   You want to set up vinum to allow more concurrent access to a file
          system.  In many cases, access to a file system is limited by the
          speed of the disk.  By spreading the volume across multiple disks,
          you can increase the throughput in multi-access environments.  This
          technique shows little or no performance improvement in single-
          access environments.  vinum uses a technique called "striping", or
          sometimes RAID-0, to increase this concurrency of access.  The name
          RAID-0 is misleading: striping does not provide any redundancy or
          additional reliability.  In fact, it decreases the reliability,
          since the failure of a single disk will render the volume useless,
          and the more disks you have, the more likely it is that one of them
          will fail.

          To implement striping, use a striped plex:

              drive d1 device /dev/da2e
              drive d2 device /dev/da3e
              drive d3 device /dev/da4e
              drive d4 device /dev/da5e
              volume raid
               plex org striped 512k
                 sd length 512m drive d1
                 sd length 512m drive d2
                 sd length 512m drive d3
                 sd length 512m drive d4

          A striped plex must have at least two subdisks, but the increase in
          performance is greater if you have a larger number of disks.

     4.   You may want to have the best of both worlds and have both
          resilience and performance.  This is sometimes called RAID-10 (a
          combination of RAID-1 and RAID-0), though again this name is
          misleading.  With vinum you can do this with the following
          configuration file:

              drive d1 device /dev/da2e
              drive d2 device /dev/da3e
              drive d3 device /dev/da4e
              drive d4 device /dev/da5e
              volume raid
               plex org striped 512k
                 sd length 512m drive d1
                 sd length 512m drive d2
                 sd length 512m drive d3
                 sd length 512m drive d4
               plex org striped 512k
                 sd length 512m drive d4
                 sd length 512m drive d3
                 sd length 512m drive d2
                 sd length 512m drive d1

          Here the plexes are striped, increasing performance, and there are
          two of them, increasing reliablity.  Note that this example shows
          the subdisks of the second plex in reverse order from the first
          plex.  This is for performance reasons and will be discussed below.

   Creating the volumes
     Once you have created your configuration files, start vinum and create
     the volumes.  In this example, the configuration is in the file
     configfile:

       # vinum create -v configfile
          1: drive d1 device /dev/da2e
          2: drive d2 device /dev/da3e
          3: volume mirror
          4:  plex org concat
          5:    sd length 2g drive d1
          6:  plex org concat
          7:    sd length 2g drive d2
       Configuration summary

       Drives:         2 (4 configured)
       Volumes:        1 (4 configured)
       Plexes:         2 (8 configured)
       Subdisks:       2 (16 configured)

       Drive d1:       Device /dev/da2e
                       Created on vinum.lemis.com at Tue Mar 23 12:30:31 1999
                       Config last updated Tue Mar 23 14:30:32 1999
                       Size:      60105216000 bytes (57320 MB)
                       Used:       2147619328 bytes (2048 MB)
                       Available: 57957596672 bytes (55272 MB)
                       State: up
                       Last error: none
       Drive d2:       Device /dev/da3e
                       Created on vinum.lemis.com at Tue Mar 23 12:30:32 1999
                       Config last updated Tue Mar 23 14:30:33 1999
                       Size:      60105216000 bytes (57320 MB)
                       Used:       2147619328 bytes (2048 MB)
                       Available: 57957596672 bytes (55272 MB)
                       State: up
                       Last error: none

       Volume mirror:  Size: 2147483648 bytes (2048 MB)
                       State: up
                       Flags:
                       2 plexes
                       Read policy: round robin

       Plex mirror.p0: Size:   2147483648 bytes (2048 MB)
                       Subdisks:        1
                       State: up
                       Organization: concat
                       Part of volume mirror
       Plex mirror.p1: Size:   2147483648 bytes (2048 MB)
                       Subdisks:        1
                       State: up
                       Organization: concat
                       Part of volume mirror

       Subdisk mirror.p0.s0:
                       Size:       2147483648 bytes (2048 MB)
                       State: up
                       Plex mirror.p0 at offset 0

       Subdisk mirror.p1.s0:
                       Size:       2147483648 bytes (2048 MB)
                       State: up
                       Plex mirror.p1 at offset 0

     The -v flag tells vinum to list the file as it configures.  Subsequently
     it lists the current configuration in the same format as the list -v
     command.

   Creating more volumes
     Once you have created the vinum volumes, vinum keeps track of them in its
     internal configuration files.  You do not need to create them again.  In
     particular, if you run the create command again, you will create
     additional objects:

       # vinum create sampleconfig
       Configuration summary

       Drives:         2 (4 configured)
       Volumes:        1 (4 configured)
       Plexes:         4 (8 configured)
       Subdisks:       4 (16 configured)

       D d1                    State: up       Device /dev/da2e        Avail: 53224/57320 MB (92%)
       D d2                    State: up       Device /dev/da3e        Avail: 53224/57320 MB (92%)

       V mirror                State: up       Plexes:       4 Size:       2048 MB

       P mirror.p0           C State: up       Subdisks:     1 Size:       2048 MB
       P mirror.p1           C State: up       Subdisks:     1 Size:       2048 MB
       P mirror.p2           C State: up       Subdisks:     1 Size:       2048 MB
       P mirror.p3           C State: up       Subdisks:     1 Size:       2048 MB

       S mirror.p0.s0          State: up       PO:        0  B Size:       2048 MB
       S mirror.p1.s0          State: up       PO:        0  B Size:       2048 MB
       S mirror.p2.s0          State: up       PO:        0  B Size:       2048 MB
       S mirror.p3.s0          State: up       PO:        0  B Size:       2048 MB

     As this example (this time with the -f flag) shows, re-running the create
     has created four new plexes, each with a new subdisk.  If you want to add
     other volumes, create new configuration files for them.  They do not need
     to reference the drives that vinum already knows about.  For example, to
     create a volume raid on the four drives /dev/da1e, /dev/da2e, /dev/da3e
     and /dev/da4e, you only need to mention the other two:

       drive d3 device /dev/da1e
       drive d4 device /dev/da4e
       volume raid
         plex org raid5 512k
           sd size 2g drive d1
           sd size 2g drive d2
           sd size 2g drive d3
           sd size 2g drive d4

     With this configuration file, we get:

       # vinum create newconfig
       Configuration summary

       Drives:         4 (4 configured)
       Volumes:        2 (4 configured)
       Plexes:         5 (8 configured)
       Subdisks:       8 (16 configured)

       D d1                    State: up       Device /dev/da2e        Avail: 51176/57320 MB (89%)
       D d2                    State: up       Device /dev/da3e        Avail: 53220/57320 MB (89%)
       D d3                    State: up       Device /dev/da1e        Avail: 53224/57320 MB (92%)
       D d4                    State: up       Device /dev/da4e        Avail: 53224/57320 MB (92%)

       V mirror                State: down     Plexes:       4 Size:       2048 MB
       V raid                  State: down     Plexes:       1 Size:       6144 MB

       P mirror.p0           C State: init     Subdisks:     1 Size:       2048 MB
       P mirror.p1           C State: init     Subdisks:     1 Size:       2048 MB
       P mirror.p2           C State: init     Subdisks:     1 Size:       2048 MB
       P mirror.p3           C State: init     Subdisks:     1 Size:       2048 MB
       P raid.p0            R5 State: init     Subdisks:     4 Size:       6144 MB

       S mirror.p0.s0          State: up       PO:        0  B Size:       2048 MB
       S mirror.p1.s0          State: up       PO:        0  B Size:       2048 MB
       S mirror.p2.s0          State: up       PO:        0  B Size:       2048 MB
       S mirror.p3.s0          State: up       PO:        0  B Size:       2048 MB
       S raid.p0.s0            State: empty    PO:        0  B Size:       2048 MB
       S raid.p0.s1            State: empty    PO:      512 kB Size:       2048 MB
       S raid.p0.s2            State: empty    PO:     1024 kB Size:       2048 MB
       S raid.p0.s3            State: empty    PO:     1536 kB Size:       2048 MB

     Note the size of the RAID-5 plex: it is only 6 GB, although together its
     components use 8 GB of disk space.  This is because the equivalent of one
     subdisk is used for storing parity data.

   Restarting Vinum
     On rebooting the system, start vinum with the start command:

       # vinum start

     This will start all the vinum drives in the system.  If for some reason
     you wish to start only some of them, use the read command.

   Performance considerations
     A number of misconceptions exist about how to set up a RAID array for
     best performance.  In particular, most systems use far too small a stripe
     size.  The following discussion applies to all RAID systems, not just to
     vinum.

     The FreeBSD block I/O system issues requests of between .5kB and 60 kB; a
     typical mix is somewhere round 8 kB.  You can't stop any striping system
     from breaking a request into two physical requests, and if you do it
     wrong it can be broken into several.  This will result in a significant
     drop in performance: the decrease in transfer time per disk is offset by
     the order of magnitude greater increase in latency.

     With modern disk sizes and the FreeBSD block I/O system, you can expect
     to have a reasonably small number of fragmented requests with a stripe
     size between 256 kB and 512 kB; with correct RAID implementations there
     is no obvious reason not to increase the size to 2 or 4 MB on a large
     disk.

     The easiest way to consider the impact of any transfer in a multi-access
     system is to look at it from the point of view of the potential
     bottleneck, the disk subsystem: how much total disk time does the
     transfer use?  Since just about everything is cached, the time
     relationship between the request and its completion is not so important:
     the important parameter is the total time that the request keeps the
     disks active, the time when the disks are not available to perform other
     transfers.  As a result, it doesn't really matter if the transfers are
     happening at the same time or different times.  In practical terms, the
     time we're looking at is the sum of the total latency (positioning time
     and rotational latency, or the time it takes for the data to arrive under
     the disk heads) and the total transfer time.  For a given transfer to
     disks of the same speed, the transfer time depends only on the total size
     of the transfer.

     Consider a typical news article or web page of 24 kB, which will probably
     be read in a single I/O.  Take disks with a transfer rate of 6 MB/s and
     an average positioning time of 8 ms, and a file system with 4 kB blocks.
     Since it's 24 kB, we don't have to worry about fragments, so the file
     will start on a 4 kB boundary.  The number of transfers required depends
     on where the block starts: it's (S + F - 1) / S, where S is the stripe
     size in file system blocks, and F is the file size in file system blocks.

     1.   Stripe size of 4 kB.  You'll have 6 transfers.  Total subsystem
          load: 48 ms latency, 2 ms transfer, 50 ms total.

     2.   Stripe size of 8 kB.  On average, you'll have 3.5 transfers.  Total
          subsystem load: 28 ms latency, 2 ms transfer, 30 ms total.

     3.   Stripe size of 16 kB.  On average, you'll have 2.25 transfers.
          Total subsystem load: 18 ms latency, 2 ms transfer, 20 ms total.

     4.   Stripe size of 256 kB.  On average, you'll have 1.08 transfers.
          Total subsystem load: 8.6 ms latency, 2 ms transfer, 10.6 ms total.

     5.   Stripe size of 4 MB.  On average, you'll have 1.0009 transfers.
          Total subsystem load: 8.01 ms latency, 2 ms transfer, 10.01 ms
          total.

     It appears that some hardware RAID systems have problems with large
     stripes: they appear to always transfer a complete stripe to or from
     disk, so that a large stripe size will have an adverse effect on
     performance.  vinum does not suffer from this problem: it optimizes all
     disk transfers and does not transfer unneeded data.

     Note that no well-known benchmark program tests true multi-access
     conditions (more than 100 concurrent users), so it is difficult to
     demonstrate the validity of these statements.

     Given these considerations, the following factors affect the performance
     of a vinum volume:

     +o   Striping improves performance for multiple access only, since it
         increases the chance of individual requests being on different
         drives.

     +o   Concatenating UFS file systems across multiple drives can also
         improve performance for multiple file access, since UFS divides a
         file system into cylinder groups and attempts to keep files in a
         single cylinder group.  In general, it is not as effective as
         striping.

     +o   Mirroring can improve multi-access performance for reads, since by
         default vinum issues consecutive reads to consecutive plexes.

     +o   Mirroring decreases performance for all writes, whether multi-access
         or single access, since the data must be written to both plexes.
         This explains the subdisk layout in the example of a mirroring
         configuration above: if the corresponding subdisk in each plex is on
         a different physical disk, the write commands can be issued in
         parallel, whereas if they are on the same physical disk, they will be
         performed sequentially.

     +o   RAID-5 reads have essentially the same considerations as striped
         reads, unless the striped plex is part of a mirrored volume, in which
         case the performance of the mirrored volume will be better.

     +o   RAID-5 writes are approximately 25% of the speed of striped writes:
         to perform the write, vinum must first read the data block and the
         corresponding parity block, perform some calculations and write back
         the parity block and the data block, four times as many transfers as
         for writing a striped plex.  On the other hand, this is offset by the
         cost of mirroring, so writes to a volume with a single RAID-5 plex
         are approximately half the speed of writes to a correctly configured
         volume with two striped plexes.

     +o   When the vinum configuration changes (for example, adding or removing
         objects, or the change of state of one of the objects), vinum writes
         up to 128 kB of updated configuration to each drive.  The larger the
         number of drives, the longer this takes.

   Creating file systems on Vinum volumes
     You do not need to run disklabel before creating a file system on a vinum
     volume.  Just run newfs against the raw device.  Use the -v option to
     state that the device is not divided into partitions.  For example, to
     create a file system on volume mirror, enter the following command:

         # newfs -v /dev/vinum/rmirror

     Note the name rmirror, indicating the raw device.

Other considerations
     A number of other considerations apply to vinum configuration:

     +o   There is no advantage in creating multiple drives on a single disk.
         Each drive uses 131.5 kB of data for label and configuration
         information, and performance will suffer when the configuration
         changes.  Use appropriately sized subdisks instead.

     +o   It is possible to increase the size of a concatenated vinum plex, but
         currently the size of striped and RAID-5 plexes cannot be increased.
         Currently the size of an existing UFS file system also cannot be
         increased, but it is planned to make both plexes and file systems
         extensible.

GOTCHAS
     The following points are not bugs, and they have good reasons for
     existing, but they have shown to cause confusion.  Each is discussed in
     the appropriate section above.

     1.   vinum will not create a device on UFS partitions.  Instead, it will
          return an error message "wrong partition type".  The partition type
          should be vinum, though currently partitions of type unused are also
          accepted.

     2.   When you create a volume with multiple plexes, vinum does not
          automatically initialize the plexes.  This means that the contents
          are not known, but they are certainly not consistent.  As a result,
          by default vinum sets the state of all newly-created plexes except
          the first to stale.  In order to synchronize them with the first
          plex, you must start their subdisks, which causes vinum to copy the
          data from a plex which is in the up state.  Depending on the size of
          the subdisks involved, this can take a long time.

          In practice, people aren't too interested in what was in the plex
          when it was created, and other volume managers cheat by setting them
          up anyway.  vinum provides two ways to ensure that newly created
          plexes are up:

          +o   Create the plexes and then synchronize them with vinum start.

          +o   Create the volume (not the plex) with the keyword setupstate,
              which tells vinum to ignore any possible inconsistency and set
              the plexes to be up.

     3.   Some of the commands currently supported by vinum are not really
          needed.  For reasons which I don't understand, however, I find that
          users frequently try the label and resetconfig commands, though
          especially resetconfig outputs all sort of dire warnings.  Don't use
          these commands unless you have a good reason to do so.

     4.   Some state transitions are not very intuitive.  In fact, it's not
          clear whether this is a bug or a feature.  If you find that you
          can't start an object in some strange state, such as a reborn
          subdisk, try first to get it into stopped state, with the stop or
          stop -f commands.  If that works, you should then be able to start
          it.  If you find that this is the only way to get out of a position
          where easier methods fail, please report the situation.

     5.   If you build the kernel module with the -DVINUMDEBUG option, you
          must also build vinum(8) with the -DVINUMDEBUG option, since the
          size of some data objects used by both components depends on this
          option.  If you don't do so, commands will fail with the message
          Invalid argument, and a console message will be logged such as

          vinumioctl: invalid ioctl from process 247 (vinum): c0e44642

          This error may also occur if you use old versions of kld or userland
          program.

     6.   vinum drives are UNIX disk partitions and should have the partition
          type vinum.  This is different from ccd, which expects partitions of
          type 4.2BSD.  This behaviour of ccd is an invitation to shoot
          yourself in the foot: with ccd you can easily overwrite a file
          system.  vinum will not permit this.

          For similar reasons, the vinum start command will not accept a drive
          on partition c.  Partition c is used by the system to represent the
          whole disk, and must be of type unused.  Clearly there is a conflict
          here, which vinum resolves by not using the c partition.

     7.   The vinum read command has a particularly emetic syntax.  Once it
          was the only way to start vinum, but now the preferred method is
          with vinum start.  vinum read should be used for maintenance
          purposes only.  Note that its syntax has changed, and the arguments
          must be disk slices, such as /dev/da0, not partitions such as
          /dev/da0e.

FILES
     /dev/vinum - directory with device nodes for vinum objects.
     /dev/vinum/control - control device for vinum
     /dev/vinum/plex - directory containing device nodes for vinum plexes.
     /dev/vinum/sd - directory containing device nodes for vinum subdisks.

ENVIRONMENT VARIABLES
     VINUM_HISTORY The name of the log file, by default
             /var/log/vinum_history.

     VINUM_DATEFORMAT The format of dates in the log file, by default %e %b %Y
             %H:%M:%S.

     EDITOR  The name of the editor to use for editing configuration files, by
             default vi.

SEE ALSO
     vinum(4), disklabel(8), newfs(8), strftime(3),
     http://www.lemis.com/vinum.html,
     http://www.lemis.com/vinum-debugging.html.

AUTHOR
     Greg Lehey _grog@lemis.com_.

HISTORY
     The vinum command first appeared in FreeBSD 3.0.

                                 28 March 1999

NAME | SYNOPSIS | COMMANDS | DESCRIPTION | EXAMPLE CONFIGURATION FILE | LOG FILE | HOW TO SET UP VINUM | Other considerations | GOTCHAS | FILES | ENVIRONMENT VARIABLES | SEE ALSO | AUTHOR | HISTORY

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=vinum&sektion=8&manpath=FreeBSD+3.2-RELEASE>

home | help