The Version 3 disk layout allows the file system to scale
easily to accommodate large files and large file systems.
The Version 1 and 2 disk layouts divided up the file system
space into allocation units. The first AU started part way into
the file system which caused potential alignment problems depending
on where the first AU started. Each allocation unit also had its
own summary, bitmaps, and data blocks. Because this AU structural
information was stored at the start of each AU, this also limited
the maximum size of an extent that could be allocated. By replacing
the allocation unit model of previous versions, the need for alignment
of allocation units and the restriction on extent sizes was removed.
The VxFS Version 3 disk layout divides the entire file system
space into fixed size allocation units. The first allocation unit
starts at block zero and all allocation units are a fixed length
of 32K blocks. (An exception may be the last AU, which occupies
whatever space remains at the end of the file system). Because the
first AU starts at block zero instead of part way through the file
system as in previous versions, there is no longer a need for explicit
AU alignment or padding to be added when creating a file system
(see mkfs_vxfs(1M)).
The Version 3 file system also moves away from the model of
storing AU structural data at the start of an AU and puts all structural
information in files. So expanding the file system structures simply
requires extending the appropriate structural files. This removes
the extent size restriction imposed by the Version 1 and Version
2 layouts.
All Version 3 structural files reside in the structural fileset, which is similar to the Version 2 attribute fileset.
The structural files in the Version 3 disk layout are:
- object location
table file
Contains the object location table (OLT). As with
the Version 2 disk layout, the OLT, which is referenced from the
super-block, is used to locate the other structural files.
- label file
Encapsulates the super-block and super-block replicas.
Although the location of the primary super-block is known, the label
file can be used to locate super-block copies if there is structural
damage to the file system.
- device file
Records device information such as volume length
and volume label, and contains pointers to other structural files.
- fileset header file
Holds information on a per-fileset basis. This may
include the inode of the fileset's inode list file, the maximum
number of inodes allowed, an indication of whether the file system
supports large files, and the inode number of the quotas file if
the fileset supports quotas. When a file system is created, there
are two filesets—the structural fileset defines the file system structure, the primary fileset contains user data.
- inode list file
Both the primary fileset and the structural fileset
have their own set of inodes stored in an inode list file. Only
the inodes in the primary fileset are visible to users. When the number
of inodes is increased, the kernel increases the size of the inode list
file.
- inode allocation unit file
Holds the free inode map, extended operations map,
and a summary of inode resources.
- log file
Maps the block used by the file system intent log.
- extent allocation unit state file
Indicates the allocation state of each AU by defining
whether each AU is free, allocated as a whole (no bitmaps allocated),
or expanded, in which case the bitmaps associated with each AU determine
which extents are allocated.
- extent allocation unit summary file
Contains the AU summary for each allocation unit,
which contains the number of free extents of each size. The summary
for an extent is created only when an allocation unit is expanded
for use.
- free extent map file
Contains the free extent maps for each of the allocation
units.
- quotas file
If the file system supports quotas, there is a quotas
file which is used to track the resources allocated to each user.
Figure 2-10 “VxFS Version 3 Disk Layout” shows how the kernel and utilities
build information about the structure of the file system. The super-block
location is in a known location from which the OLT can be located.
From the OLT, the initial extents of the structural inode list can be
located along with the inode number of the fileset header file.
The initial inode list extents contain the inode for the fileset
header file from which the extents associated with the fileset header
file are obtained.
As an example, when mounting the file system, the kernel needs
to access the primary fileset in order to access its inode list,
inode allocation unit, quotas file and so on. The required information
is obtained by accessing the fileset header file from which the
kernel can locate the appropriate entry in the file and access the
required information.
Printable version
