Contents:
The VERITAS File System
Disk Space Allocation
Extent Based Allocation
Typed Extents
Extent Attributes
Disk Layout Options
Version 1
Version 2
Version 4
Inode Limitation On Filesystems Without Large File Support
Upgrading The VxFS Disk Layout
How To Look For The Number Of Inodes Allocated on A VxFS Filesystem
=-=-=-=-=-=-=-=-=-=-=-=
The VERITAS File System
=-=-=-=-=-=-=-=-=-=-=-=
The VERITAS File System (referred to as VxFS or vxfs) is an
extent based, intent logging file system intended for use with
the Solaris operating system.
VxFS provides enhancements that increase Solaris usability and
makes the UNIX system more viable for use in the commercial
marketplace. VxFS is particularly useful in environments that
require high performance and availability and deal with large
volumes of data.
To provide a conceptual understanding of how the
VxFS allocation scheme differs from block based
allocation, an overview of this architecture is
covered in the section entitled "Extent based Allocation."
=-=-=-=-=-=-=-=-=-=-=
Disk Space Allocation
=-=-=-=-=-=-=-=-=-=-=
Disk space is allocated by the system in 512 byte sectors. An
integral number of sectors are grouped together to form a logical
block. VxFS supports logical block sizes of 1024, 2048, 4096, and
8192 bytes. The default block size is 1024 bytes. The block size
may be specified as an argument to the mkfs utility and may vary
between VxFS file systems mounted on the same system. VxFS
allocates disk space to files in extents. An extent is a set of
contiguous blocks.
=-=-=-=-=-=-=-=-=-=-=-=
Extent Based Allocation
=-=-=-=-=-=-=-=-=-=-=-=
Disk space is allocated by the system in 512 byte sectors,
which are grouped to form a logical block. VXFS supports
logical block sizes of 1024, 2048, 4096, and 8192 bytes.
The default block size is 1K for file systems up to 8GB,
2K for file systems up to 16 GB, 4K for ifie systems up to 3
2 GB, and 8K for larger filesystems.
An extent is defined as one or more adjacent blocks of data
within the filesystem. An extent is presented as an address-length
pair, which identifies the starting block address and the length
of the extent (in filesystem or logical blocks). When storage is
added to a file on a VxFS ifie system, it is grouped in extents,
as opposed to being allocated a block at a time (as is done with
the ufs filesystem).
By allocating disk space to files in extents, disk I/O to and
from a file can be done in units of multiple blocks. This type of
I/O can occur if storage is allocated in units of consecutive blocks.
For sequential I/O, multiple block operations are considerably faster
than block-at-a-time operations. Almost all disk drives accept I/O
operations of multiple blocks.
Extent allocation makes the interpretation of addressed blocks
from the inode structure only slightly different from that of block
based modes. The ufs filesystem inode structure contains the addresses
of 12 direct blocks, one indirect block, and one double indirect block.
An indirect block contains the addresses of other blocks. The ufs
indirect block size is 8K and each address is 4 bytes long. A ufs mode
therefore can address 12 blocks directly and up to 2048 more blocks
through one indirect address.
A VxFS mode is similar to the ufs inode. It references 10 direct extents,
each of which are pairs of starting block addresses and lengths in blocks.
The VxFS mode also points to two indirect address extents, which contain
the addresses of other extents:
- The first indirect address extent is used for single
indirection, where each entry in the extent indicates the starting block
number of an indirect data extent.
- The second indirect address extent is used for double
indirection, where each entry in the extent indicates the starting block
number of a single indirect address extent.
Each indirect address extent is 8K long and contains 2048 entries. All
indirect data extents for a file must be the same size: this value is set
when the first indirect data extent is allocated and it is stored in the
mode. Directory modes always use an 8K indirect data extent size. By default,
regular file modes also use an 8K indirect data extent size (this can be
changed with vxtunefs), but they allocate and use the indirect data extents
in clusters to simulate larger extents.
=-=-=-=-=-=-=
Typed Extents
=-=-=-=-=-=-=
In Version 4, VXFS introduced a new type of mode block map organization
for indirect extents known as the typed extents. Each entry in the block
map consists of a typed descriptor record containing a type, offset,
starting block, and number of blocks. Indirect as well as data extents
use this format to identify logical file offsets and physical disk
locations of any given extent. The extent descriptor fields are
defined as follows:
* type - Uniquely identifies and defines an extent descriptor
record, and defines the record's length and format.
* offset - Represents the logical file offset in blocks for a
given descriptor. Used to optimize lookups and to eliminate
hole descriptor entries.
* starting block - The starting file system block of the extent.
* number of blocks - The number of contiguous blocks in the extent.
Some notes about typed extents:
* Indirect address blocks are fully typed and may have variable
lengths up to a maximum of 8K (this is the optimum size). On a
fragmented filesystem, indirect extents may be smaller than 8K d
epending on space availability. VxFS always tries to obtain 8K
indirect extents, but will use smaller indirects if needed.
* Indirect Data extents are variable in size. This allows files
which must go to indirects to continue to allocate large, contiguous
extents and take full advantage of VxFS's optimized I/O.
* Holes in sparse ifies require no storage. Since a typed record
contains the offset and length of a descriptor, holes are eliminated
entirely. A hole is determined by adding the offset and length of a
descriptor and comparing the result with the offset of the next record.
* There are no limits on the levels of indirection. It is expected
however, that fewer levels will be seen with this format given that
data extents are of variable lengths.
* New types can be added in the future. Since this format uses a type
indicator to determine it's record format and content, new types can
be added to accommodate future requirements and new functionality.
Currently, the typed format is used on regular files only when
indirection is needed. Typed records are longer than the previous
format and therefore less direct entries can be used in the mode.
Newly created files start out using the old format which allows for
10 direct extents in the inode. The inode's block map is converted
to the typed format when indirection is needed. This allows
us to take full advantage of both formats.
=-=-=-=-=-=-=-=-=
Extent Attributes
=-=-=-=-=-=-=-=-=
The VxFS file system allocates disk space to files in groups of one
or more extents. VxFS also allows applications to control some aspects
of the extent allocation for a given file. Extent attributes are the
extent allocation policies associated with a file.
The setext and getext commands allow the administrator to set or view
extent attributes associated with a file, as well as to preallocate
space for a file. See the setext(1) and getext(l) man(ual) pages for
discussions on how to use extent attributes.
The vxtunefs command allows the administrator to set or view the
default indirect data extent size. See the vxtunefs(1M) man(ual) page
for discussions on how to use the indirect data extent size feature.
=-=-=-=-=-=-=-=-=-=
Disk Layout Options
=-=-=-=-=-=-=-=-=-=
Three disk layout formats are available with VxFS:
Version 1
---------
The Version 1 disk layout is the original layout used with
earlier releases (pre-2.0) of VxFS. This version is not y2k
compliant, thus a recommendation of an upgrade is the
best recommendation for this version of VxFS disk layout.
Version 2
---------
The Version 2 disk layout supports features such as:
- filesets
- dynamic inode allocation
- enhanced security
In addition, the Version 2 layout is available with and
without support for quotas.
Many aspects of the Version 1 disk layout are preserved in the
Version 2 disk layout. However, the Version 2 layout differs
from the Version 1 layout in that it includes support for the
following features:
- filesets (sets of files within a file system)
- dynamic inode allocation (allocation of modes on an
as-neededbasis)
- enhanced security
The addition of filesets and dynamic allocation of inodes has
affected the disk layout in various ways. In particular, many
of the file system structures are now located in files (referred
to as structural files) rather than in fixed disk areas. This
provides a simple mechanism for dynamic growth of structures. For
example, modes are now stored in structural files and allocated
as needed. In general, file system structures that deal with
space allocation are still in fixed disk locations, while most
other structures are dynamically allocated and have become clients
of the file system's disk space allocation scheme.
The Version 2 disk layout for VxFS 2.3 differs from previous VxFS
releases because of the addition of BSD style quota support. The
differences include the fileset header structure modification to
store a quota inode and preallocation of an internal quotas file.
Basic Layout
The VxFS Version 2 disk layout is composed of:
- The super-block
- The object location table
- The intent log
- A replica of the object location table
- One or more allocation units
Inodes
An inode is a data structure that contains information about a
file. The VxFS default inode size is currently 256 bytes.
Each inode stores information such as the following about a
particular file:
- file length
- link count
- owner and group IDs
- access privileges
- time of last access
- time of last modification
- pointers to the extents that contain the file's data
Refer to the inode_vxfs(4) manual page for details on the
contents of a VxFS inode.
There are up to ten direct extent address size pairs per inode.
Each direct extent address indicates the starting block number
of a direct extent; direct extent sizes can vary. If all of
the direct extents are used, two indirect address extents are
available for use in each inode. The first indirect address extent
is used for single indirection, where each entry in the extent
indicates the starting block number of an indirect data extent.
The second indirect address extent is used for double indirection,
where each entry in the extent indicates the starting block
number of a single indirect address extent. Each indirect address
extent is 8K long and contains 2048 entries. All indirect data
extents for a given file have the same size, which is determined
when the file's first indirect data extent is allocated.
Version 2 inodes differ from Version 1 inodes in that they are
located in structural files to facilitate dynamic mode allocation,
which is the allocation of modes on an as-needed basis. Instead of
allocating a fixed number of inodes into the file system, mkfs
allocates a minimum number of modes. Additional inodes are later
allocated as the file system needs them.
The inode list is a series of inodes located in the mode list file.
There is one inode in the list for every file in a given fileset.
For recovery purposes, the inode list file is referenced by two
inodes that point to the same set of data blocks. Although the inode
addresses are replicated for recovery purposes, the inodes themselves
are not.
An inode extent is an extent that contains modes and is 8K long,
by default. Inode extents are dynamically allocated to store inodes
as they are needed.
Initial Inode List Extents
The initial inode list extents contain the modes first allocated
by mkfs for each fileset in a file system. During file system use,
inodes are allocated as needed and are added into the inode list
files for the filesets.
The construction of the primary fileset's inode list resembles
that of the VxFS Version 1 file system layout, with the first two
inodes reserved and inodes 2 and 3 pre-assigued to the root and
lost+found directories. The structural fileset's inode list is
similarly constructed, with certain inodes allocated for specific
files and other inodes reserved or unallocated.
There are two initial inode list extents for the structural fileset.
These contain the inodes for all structural files needed to find and
set up the file system.
Some of the entries in the structural fileset's inode list are
replicas of one another. For example, inodes 4 and 36 both reference
copies of the fileset header file. The replicated inodes are used by
fsck to reconstruct the file system in the event of damage to either
one of the replicas. Although the two initial inode list extents
belonging to the structural fileset are logically contiguous, they
are physically separated. This helps to ensure the integrity of the
replicated information and reduces the chance that localized disk
damage might result in complete loss of the file system.
Note that inodes 6 and 38 in the structural ifieset reference the
inode list file for the structural fileset. In a newly created file
system, this file contains the two inode extents pictured for the
structural ifieset. Likewise, the structural fileset inodes 7 and 39
reference the inode list file for the primary fileset. In a newly
created file system, this file contains the single extent pictured
for the primary fileset. All of the unused inodes in the initial
extents of the structural inode list are reserved for future use.
NOTE: The Version 3 disk layout is not supported on Solaris.
---------
Version 4
---------
Version 4 is the new and default VxFS disk layout.
This disk layout encompasses all file system structural
information in files, rather than at fixed locations on
disk, allowing for greater scalability.
It adds support for:
- files up to 2 terabytes
- file systems up to 1 terabyte
- Access Control Lists
The Version 4 disk layout was designed to allow 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 (Allocation unit) 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 4 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(1M)).
The Version 4 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 4 structural files reside in the structural fileset,
which is similar to the Version 2 attribute fileset. The structural
files in the Version 4 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, which defines the file system
structure, and the primary fileset, which contains user data.
NOTE: Most Solaris and VxFS documentations state that inodes are
unlimited and dynamically allocated while some Release Notes
specify that there is a limitation under 5.5.1 of 8.4 millions
inodes. The only way to check these limtations is to check the
current VxFS disk layout you have and the Solaris Operating
System version you are currently using.
There is no way to increase the number of inodes once the file
system is created - the creation process (mkfs) is what creates
those inodes.
Inode Limitation On Filesystems Without Large File Support
----------------------------------------------------------
To be able to create more than 8 million inodes, the
file system must be created using the largefiles option of
mkfs (the fsadm utility can also be used to set the
largefiles flag on the filesystem) see the mkfs_vxfs and
fsadm_vxfs man pages for details.
Upgrading The VxFS Disk Layout
------------------------------
VxFS currently supports three file system disk layouts
listed above.
o disk layout 1
o disk layout 2 (with quotas or without quotas)
o disk layout 4
Once VxFS Release 3.X (example, 3.2.1 or higher) is installed
on system, new filesystems are created using disk layout 4 by
default, but you can specify other disk layouts using mkfs
# mkfs -o version=2
# mkfs -o version=4
# mkfs -o noquota, version=2
Using disk layout 4 for NEW filesystems is recommended.
Use the vxupgrade command to upgrade an existing VxFS disk
layout to disk layout 4 while the file systems remains on
line (see the vxupgrade(1M) manual page for details on
upgrading VxFS filesystems).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
How To Look For The Number Of Inodes Allocated on A VxFS Filesystem
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There are different ways of determining inode/info/characteristics/type
on a VxFS filesystem.
[A.] Check mounted filesystems to see if you are using strictly
Solaris hard partitions or Veritas Volume Manager volume
partitions and their respective usage, capacity and mount
points via "df -k":
# /usr/bin/df -k
Sample Output:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t0d0s0 246167 116222 105335 53% /
/dev/dsk/c2t0d0s6 433639 259588 130691 67% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
/dev/dsk/c2t0d0s3 492351 54671 388450 13% /var
/dev/dsk/c2t0d0s5 433639 52765 337514 14% /opt
swap 489056 75636 413420 16% /tmp
/dev/dsk/c3t2d2s0 489702 52477 388255 12% /mnt
softdist-190:/export/dist
26081504 16973264 8586616 67% /usr/dist
/dev/vx/dsk/rootdg/vol01
10240 1109 8568 12% /vxfs_test1
/dev/vx/dsk/rootdg/vol02
10240 1109 8568 12% /vxfs_test2
Note: There may be instances that the VxFS volumes are used as
raw partitions. If this is the case. You will NOT see these
volumes as being mounted. You can however, still reference
the whole raw device name for that volume in the "fstyp" or
"mkfs" commands given below in [D.].
[B.] Check the mounted filesystems (mount points) whether they
are "UFS" or "VxFS" file systems via "df -n":
# /usr/bin/df -n
Sample Output:
/ : ufs
/usr : ufs
/proc : proc
/dev/fd : fd
/var : ufs
/opt : ufs
/tmp : tmpfs
/mnt : ufs
/usr/dist : nfs
/vxfs_test1 : vxfs
/vxfs_test2 : vxfs
This output clearly shows "/vxfs_test1", and "/vxfs_test2"
as having "VxFS" file systems.
[C.] Determine the disk layout version you are currently
running on these "VxFS" file systems via "vxupgrade":
# /usr/lib/fs/vxfs/vxupgrade /vxfs_test1
Sample Output:
/vxfs: vxfs file system version 4 layout
# /usr/lib/fs/vxfs/vxupgrade /vxfs_test1
Sample Output:
/vxfs: vxfs file system version 4 layout
[D.] Next determine the properties of this VxFS file system
including the inode information via "mkfs -o N" or "fstyp"
or "mkfs -F vxfs -m":
# /usr/lib/fs/vxfs/mkfs -o N /dev/vx/rdsk/rootdg/vol01
Sample Output:
version 4 layout
20480 sectors, 10240 blocks of size 1024, log size 1024 blocks
unlimited inodes, largefiles not supported
10240 data blocks, 9144 free data blocks
1 allocation units of 32768 blocks, 32768 data blocks
last allocation unit has 10240 data blocks
# /usr/lib/fs/vxfs/mkfs -o N /dev/vx/rdsk/rootdg/vol02
Sample Output:
version 4 layout
20480 sectors, 10240 blocks of size 1024, log size 1024 blocks
unlimited inodes, largefiles not supported
10240 data blocks, 9144 free data blocks
1 allocation units of 32768 blocks, 32768 data blocks
last allocation unit has 10240 data blocks
OR
# /usr/lib/fs/vxfs/fstyp -v /dev/vx/rdsk/rootdg/vol01
Sample Output:
vxfs
magic a501fcf5 version 4 ctime Sat Jul 17 19:50:05 1999
logstart 0 logend 0
bsize 1024 size 10240 dsize 10240 ninode 0 nau 0
defiextsize 0 ilbsize 0 immedlen 96 ndaddr 10
aufirst 0 emap 0 imap 0 iextop 0 istart 0
bstart 0 femap 0 fimap 0 fiextop 0 fistart 0 fbstart 0
nindir 2048 aulen 32768 auimlen 0 auemlen 8
auilen 0 aupad 0 aublocks 32768 maxtier 15
inopb 4 inopau 0 ndiripau 0 iaddrlen 8 bshift 10
inoshift 2 bmask fffffc00 boffmask 3ff checksum dc9f2f5d
oltext1 33 oltext2 1282 oltsize 1 checksum2 62b
free 9131 ifree 0
efree 1 1 0 1 0 1 2 2 0 1 0 2 1 0 0 0
# /usr/lib/fs/vxfs/fstyp -v /dev/vx/rdsk/rootdg/vol01
Sample Output:
vxfs
magic a501fcf5 version 4 ctime Sat Jul 17 19:50:05 1999
logstart 0 logend 0
bsize 1024 size 10240 dsize 10240 ninode 0 nau 0
defiextsize 0 ilbsize 0 immedlen 96 ndaddr 10
aufirst 0 emap 0 imap 0 iextop 0 istart 0
bstart 0 femap 0 fimap 0 fiextop 0 fistart 0 fbstart 0
nindir 2048 aulen 32768 auimlen 0 auemlen 8
auilen 0 aupad 0 aublocks 32768 maxtier 15
inopb 4 inopau 0 ndiripau 0 iaddrlen 8 bshift 10
inoshift 2 bmask fffffc00 boffmask 3ff checksum dc9f2f5d
oltext1 33 oltext2 1282 oltsize 1 checksum2 62b
free 9131 ifree 0
efree 1 1 0 1 0 1 2 2 0 1 0 2 1 0 0 0
OR
# /usr/lib/fs/vxfs/mkfs -F vxfs -m /dev/vx/rdsk/rootdg/vol01
Sample Output:
mkfs -F vxfs -o
ninode=unlimited,bsize=1024,version=4,inosize=256,logsize=1024,
nolargefiles /dev/vx/rdsk/rootdg/vol01 20480
# /usr/lib/fs/vxfs/mkfs -F vxfs -m /dev/vx/rdsk/rootdg/vol02
Sample Output:
mkfs -F vxfs -o
ninode=unlimited,bsize=1024,version=4,inosize=256,logsize=1024,
nolargefiles /dev/vx/rdsk/rootdg/vol01 20480
NOTES:
------
o Be sure that you are consistent with the binaries/commands
being invoked. There are 2 separate binaries for "mkfs" and
"fstyp".
/usr/lib/fs/vxfs
and
/usr/sbin
You may encounter problems reading "correct" information or
may even get errors when invoking incorrect binaries among
the two. To further explain this, please reference
SRDB ID: 19520
SYNOPSIS: The 'mkfs -m' command erroneously reports a UFS
filesystem.
Rule-of-thumb is, if dealing with VxFS, use strictly
/usr/lib/fs/vxfs binaries including the initial creation
of the filesystem via "mkfs".
o You may use raw or block partitions for the device names,
however in most cases it is best recommended to use the'
raw device names of the storage device involved.
As in our example, /dev/vx/rdsk/rootdg/vol01 and
/dev/vx/rdsk/rootdg/vol02
o From the "/usr/lib/fs/vxfs/fstyp -v", "vxupgrade"
/usr/lib/fs/vxfs/mkfs -o N" and/or
"/usr/lib/fs/vxfs/mkfs -F vxfs -m" outputs, the
"ninode 0", "version 4 layout" or "unlimited inodes"
clearly indicates UNLIMITED inodes.
ninode=n
n is the maximum number of inodes in the file
system. The digit 0 and the string unlimited
both mean the number of inodes is unlimited.
For disk layout Version 1, n is rounded down and
the default is the total number of blocks in
allocation units divided by 4.For disk layout
Versions 2 and 4, the default is unlimited.
See manual pages for mkfs_vxfs below.
From man(ual) page of mkfs_vxfs
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The number of inodes allocated to a file system
depends on the disk layout version. For Version 1 file
systems, the default number of inodes is calculated as a
function of the file system size, with 1/4 of the available
blocks used for inodes. This default can be overridden
with the ninode=num option. For Version 2 or 4 disk layouts,
inode allocation is done dynamically. There is a minimum
number of inodes allocated to the file system by mkfs, and
any other inode allocations are done on an as-needed basis
during file system use.
inosize=inosize
inosize is the on-disk inode structure size for
files on the file system. For disk layout Ver-
sions 1 and 2, the only valid value is 256. For
disk layout Version 4, the valid values are 256
and 512. The default is 256. There is usually
no reason to increase the inode size, and not
using the default value may even adversely
affect file system performance.
ninode=n
n is the maximum number of inodes in the file
system. The digit 0 and the string unlimited
both mean the number of inodes is unlimited.
For disk layout Version 1, n is rounded down and
the default is the total number of blocks in
allocation units divided by 4.For disk layout
Versions 2 and 4, the default is unlimited.
From man(ual) page of fstyp_vxfs
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-v
Specifies verbose mode. Displays the super-block
fields, the number of free blocks and inodes, and
the number of free extents by size. The output for
-v differs slightly depending on the disk layout.
For a Version 2 file system, the number of free
inodes is always zero. For a Version 4 file sys-
tem, fields such as logstart, logend, and nau are
also zero. The number of allocation units can be
determined from the file system size field and the
aulen field. In Version 4 file systems, all allo-
cation units are the same size (as shown by aulen)
except for the last au, which can be smaller.
The VxFS SysAdmin Guide says that since VxFS Version
2 filesystems (default is Version 4 on VxFS 3.2.X) additional
inodes are created on demand.
The initial pool setup at mkfs is what determines the number of
inodes that will be allocated to your VxFS filesystem. Again it is
BEST RECOMMENDED to add the "-o largefiles" option in the "mkfs"
command to add support to files > 2GB. Be sure however, that
your Solaris Operating System version is "large file" aware
or SUPPORTS the "largefiles" option.
As an ILLUSTRATION:
-------------------
# /usr/lib/fs/vxfs/mkfs -F vxfs -o largefiles /dev/vx/rdsk/simpledg/v0
Sample Output:
version 4 layout
403456 sectors, 201728 blocks of size 1024, log size 1024 blocks
unlimited inodes, largefiles supported
^^^^^^^^^^^^^^^^
201728 data blocks, 200584 free data blocks
7 allocation units of 32768 blocks, 32768 data blocks
last allocation unit has 5120 data blocks
#
# /usr/bin/df -g .
/mnt (/dev/vx/dsk/simpledg/v0): 8192 block size 1024
frag size
403456 total blocks 401142 free blocks 376086 available
50144 total files
^^^^^^^^^^^^^^^^^
50140 free files 20779376 filesys id
^^^^^^^^^^^^^^^^
vxfs fstype 0x00000004 flag 255 filename length
#
A bit later after creating a few files ;-), ~ 28,000, the output shows ...
/mnt (/dev/vx/dsk/simpledg/v0): 8192 block size 1024
frag size
403456 total blocks 333866 free blocks 313058 available
68240 total files
^^^^^^^^^^^^^^^^^
41731 free files 20779376 filesys id
^^^^^^^^^^^^^^^^^
vxfs fstype 0x00000004 flag 255 filename length
Note the free files have dropped but the total files have increased somewhat.
No intervention (other than the file creation) was taken. So you should be
OK, meaning you will not run out of files before you run out of inodes.
What you are seeing here is the initial pool setup at mkfs.
VxFS tries to match up its current pools with what the utilities use
for the fixed pools in other file systems.
The best way to remedy a situation where you run out of inodes is
to recreate the VxFS filesystem with the "-o largefiles" as well as
using the latest revision of VxFS (VRTSvxfs version 3.X) to ensure
that disk layout version 4 is used for dynamic unlimited inode
allocation.
