match

Synopsis

match volume header
match alternate volume header
match journal
match journal information block
match catalog file
match attributes file
match startup file
match extents file
match allocation file
match bad block file

match files where <match-expr>

Description

Defines the conditions under which a class will match a file. If more than one match specification is given for a class, a match of any one of the specifications will cause the class to match.

match may be followed either by the name of a volume data structure, or alternatively by the phrase files where, followed by a match expression. We recommend that you avoid the form with the volume data structure names, as it is really intended for use in the built-in class set definitions.

Match expressions are compiled into a form that iDefrag can interpret quickly to keep extent classification fast; most expressions compile and execute quickly, but a few impose a compile time or match-time penalty (there is a table later in this description that lists potentially problematic constructs).

A match-expr or match expression is a Boolean expression consisting of comparisons of properties and values, logical operators and a few other predicates. Currently supported properties are

The operators are for the most part straightforward, with the possible exception of the ~= and ~!= operators (the match operators), which aside from their obvious use matching regular expressions against string properties can be used to match bitmasks against numeric properties. For instance, 0b1010 ~= 0b0010 is true, whilst 0b1010 ~= 0b0001 and 0b1010 ~!= 0b1000 are both false. (Note that having constants on both sides of an expression is not actually supported by iDefrag; the example is for illustrative purposes only.) A summary of the available operators is given below, in order of precedence:

iDefrag also supports four predicate expressions, namely:

Performance Tips

Certain type of match expression have a substantial effect on performance, either during compilation of the match engine, or at match time when iDefrag is attempting to match file extents with classes.

The table below lists the expressions that are potentially expensive.

Match time penalties are generally more problematic than compile-time penalties because matching processes very large numbers of files on a typical disk.

The most serious performance issue is if iDefrag is forced to look up the full paths for large numbers of items at match time. It’s best to avoid full path matching except with the = and != operators if at all possible, and if you must use it in other circumstances then put it on the right hand side of an and or or expression.

Additionally, iDefrag runs matching in class priority order, so it’s better to put expensive match statements in classes that have a lower priority, so that files that match other class sets are not subject to the performance penalty from evaluating an expensive match expression against them.

Example

class "BSD" {
  match files where file is within "/usr" or file is within "/bin"
  match files where file is within "/etc"
  color "#ffe000"
}

class "Big" {
  match files where size > 104857600
  color "#ff00ff"
}

See also

class, display class, priority