title: Used Space and Inodes in Filesystems
agents: linux, windows, aix, solaris, openvms, hpux, freebsd, netbsd, openbsd, macosx
catalog: os/storage
license: GPLv2
distribution: check_mk
description:
 This check measures the usage of filesystems. The usage
 is checked against a warning and a critical level, which
 can be specified in numerous ways.

 Beware: on Linux and UNIX systems the filesystem might reserve a certain
 amount for root (typical is 5%). This checks considers that reserved space
 as used. This is consistent with the percentage-column in the output of {df}
 on most distributions.  So your filesystem might be at 100% in a situation
 where root still has 5% free space available. On some distributions, {df}
 seems to use the user allocatable space instead of the total filesystem size
 as base for the percentage calculation, this might result in differences
 between the percentage values shown by that {df} version and the value
 shown in Checkmk. From our point of view, the calculation of Checkmk is
 more accurate.

 {Inodes:} if the agent provides a {df} subsection for {inodes}, this check
 measures the inodes usage. Thresholds default to (10%, 5%) remaining inodes and
 can be set/changed in ruleset {filesystems}.

 {Trends:} This checks supports filesystem {trends}. This means that the {df} check
 is able to compute the {change} of the used space over the time and can
 make a forecast into the future. It can estimate the time when
 the filesystem will be full.

 In the default configuration the check will compute the trend based on the
 data of the last 24 hours using an exponential moving average that gives more recent
 data a higher weight. Also data beyond the 24 hours will to some small degree be
 reflected in the computation. The advantage of this algorithm is
 an implementation, which does not need any
 access to any RRDs or similar storage.

 Please note that when a filesystem is started to be monitored,
 the trend of the past is unknown.
 It will take at least one trend range of time until the trend
 stabilises and approximately reflects the reality.

 {Grouping:} In some situations you do not want to monitor a single
 filesystem but a group of filesystems forming a pool.
 Only the total usage of the pool is of interest. The {df} check supports pools
 by defining groups. For each group you specify a name and a list
 of globbing patterns (path patterns containing {*}, {?} and {[...]}). The name
 is being used as the check item. All filesystems that match one of
 the patterns are part of the pool. You can specify both patterns for including
 and excluding filesystems from a group.

 When using auto discovery you specify the groups with the ruleset
 "Filesystem Discovery". When configuring manual checks, you specify
 the list of patterns in the check parameters {"patterns_include"} (for including
 filesystems in the group) and {"patterns_exclude"} (for excluding filesystems
 from the group).

item:
 The mount point of the filesystem (UNIX) or the drive
 letter in upper case followed by a colon (Windows). For groups
 the item is the name of the group.

discovery:
 One service is created for each filesystem the agent reports except filesystem types listed in {inventory_df_exclude_fs}.
 The Windows agent only reports fixed disks.
 The Linux agent reports filesystems that have a size and are not of type smbfs, tmpfs, cifs or nfs.

 If filesystem groups are configured in the ruleset "Filesystem Discovery" and a found filesystem
 is matching one of the patterns of a group, then instead of a
 service of the single filesystem one service  for the group is
 created. The service is the name of that group in that case.
