You can use the SmartTier graphical user interface (GUI) to create any of four types of file placement policy documents. Alternatively, you can use a text editor or XML editor to create XML policy documents directly. The GUI places policy rule statements in the correct order to achieve the desired behavior. If you use a text editor, it is your responsibility to order policy rules and the statements in them so that the desired behavior results.
The rules that comprise a placement policy may occur in any order, but during both file allocation and fsppadm enforce relocation scans, the first rule in which a file is designated by a SELECT statement is the only rule against which that file is evaluated. Thus, rules whose purpose is to supersede a generally applicable behavior for a special class of files should precede the general rules in a file placement policy document.
The following XML snippet illustrates faulty rule placement with potentially unintended consequences:
<?xml version="1.0"?> <!DOCTYPE FILE_PLACEMENT_POLICY SYSTEM "placement.dtd"> <FILE_PLACEMENT_POLICY Version="5.0"> <RULE Name="GeneralRule"> <SELECT> <PATTERN>*</PATTERN> </SELECT> <CREATE> <ON> <DESTINATION> <CLASS>tier2</CLASS> </DESTINATION> </ON> </CREATE> other_statements </RULE> <RULE Name="DatabaseRule"> <SELECT> <PATTERN>*.db</PATTERN> </SELECT> <CREATE> <ON> <DESTINATION> <CLASS>tier1</CLASS> </DESTINATION> </ON> </CREATE> other_statements </RULE> </FILE_PLACEMENT_POLICY>
The GeneralRule rule specifies that all files created in the file system, designated by <PATTERN>*</PATTERN>, should be created on
tier2 volumes. The
DatabaseRule rule specifies that files whose names include an extension of
.db should be created on
tier1 volumes. The
GeneralRule rule applies to any file created in the file system, including those with a naming pattern of
*.db, so the
DatabaseRule rule will never apply to any file. This fault can be remedied by exchanging the order of the two rules. If the
DatabaseRule rule occurs first in the policy document, VxFS encounters it first when determining where to new place files whose names follow the pattern
*.db, and correctly allocates space for them on
tier1 volumes. For files to which the
DatabaseRule rule does not apply, VxFS continues scanning the policy and allocates space according to the specification in the CREATE statement of the
A similar consideration applies to statements within a placement policy rule. VxFS processes these statements in order, and stops processing on behalf of a file when it encounters a statement that pertains to the file. This can result in unintended behavior.
The following XML snippet illustrates a RELOCATE statement and a DELETE statement in a rule that is intended to relocate if the files have not been accessed in 30 days, and delete the files if they have not been accessed in 90 days:
<RELOCATE> <TO> <DESTINATION> <CLASS>tier2</CLASS> </DESTINATION> </TO> <WHEN> <ACCAGE Units="days"> <MIN Flags="gt">30</MIN> </ACCAGE> </WHEN> </RELOCATE> <DELETE> <WHEN> <ACCAGE Units="days"> <MIN Flags="gt">90</MIN> </ACCAGE> </WHEN> </DELETE>
As written with the RELOCATE statement preceding the DELETE statement, files will never be deleted, because the <WHEN> clause in the RELOCATE statement applies to all selected files that have not been accessed for at least 30 days. This includes those that have not been accessed for 90 days. VxFS ceases to process a file against a placement policy when it identifies a statement that applies to that file, so the DELETE statement would never occur. This example illustrates the general point that RELOCATE and DELETE statements that specify less inclusive criteria should precede statements that specify more inclusive criteria in a file placement policy document. The GUI automatically produce the correct statement order for the policies it creates.