Symantec logo

Calculating I/O temperature

An important application of the VxFS Dynamic Storage Tiering Facility is automating the relocation of inactive files to lower-cost storage. If a file has not been accessed for the period of time specified in the <ACCAGE> element, a scan of the file system should schedule the file for relocation to a lower tier of storage. But, time since last access is inadequate as the only criterion for activity-based relocation for the following reasons:

The VxFS Dynamic Storage Tiering Facility implements the concept of I/O temperature to overcome these deficiencies. A file's I/O temperature is equal to the number of bytes transferred to or from it over a specified period of time divided by the size of the file. For example, if a file occupies one megabyte of storage at the time of an fsppadm enforce scan and the data in the file has been completely read or written ten times within the last three days, the file's I/O temperature is said to be 10 over 3 days.

If a file system's active placement policy includes any <IOTEMP> clauses in RELOCATE or DELETE statements, VxFS begins execution of the fsppadm enforce command by calculating file I/O activity using information in its File Change Log (FCL) file. It uses these estimates to make relocation and deletion decisions.

See About the File Change Log file

As its name implies, the File Change Log records information about changes made to files in a VxFS file system. In addition to recording creations, deletions, extensions, the FCL periodically captures the cumulative amount of I/O activity (number of bytes read and written) on a file-by-file basis. File I/O activity is recorded in the FCL each time a file is opened or closed, as well as at timed intervals to capture information about files that remain open for long periods.

If a file system's active file placement policy contains <IOTEMP> clauses, execution of the fsppadm enforce command begins with a scan of the FCL to extract I/O activity infor-mation over the period of interest for the policy. The period of interest is the interval between the time at which the fsppadm enforce command was issued and that time minus the largest interval value specified in any <PERIOD> element in the active policy.

For files with I/O activity during the largest interval, VxFS computes an approximation of the amount of read, write, and total data transfer (the sum of the two) activity by subtracting the I/O levels in the oldest FCL record that pertains to the file from those in the newest (Vnewest - Voldest in Figure 2). It then computes each file's I/O temperature by dividing its I/O activity by its size at Tscan. Dividing by file size is an implicit acknowledgement that relocating larger files consumes more I/O resources than relocating smaller ones. Using this algorithm requires that larger files must have more activity against them in order to reach a given I/O temperature, and thereby justify the resource cost of relocation.

While this computation is an approximation in several ways, it represents an easy to compute, and more importantly, unbiased, estimate of relative recent I/O activity upon which reasonable relocation decisions can be based.

File relocation and deletion decisions can be based on read, write, or total I/O activity.

The following XML snippet illustrates the use of IOTEMP in a policy rule to specify relocation of low-activity files from tier1 volumes to tier2 volumes:

<RELOCATE>

<FROM>

<SOURCE>

<CLASS>tier1</CLASS>

</SOURCE>

</FROM>

<TO>

<DESTINATION>

<CLASS>tier2</CLASS>

</DESTINATION>

</TO>

<WHEN>

<IOTEMP Type="nwrbytes">

<MAX Flags="lt">3</MAX>

<PERIOD Units="days">4</PERIOD>

</IOTEMP>

</WHEN>

</RELOCATE>

This snippet specifies that files to which the rule applies should be relocated from tier1 volumes to tier2 volumes if their I/O temperatures fall below 3 over a period of 4 days. The Type="nwrbytes" XML attribute specifies that total data transfer activity, which is the the sum of bytes read and bytes written, should be used in the computation. For example, a 50 megabyte file that experienced less than 150 megabytes of data transfer over the 4-day period immediately preceding the fsppadm enforce scan would be a candidate for relocation. VxFS considers files that experience no activity over the period of interest to have an I/O temperature of zero. VxFS relocates qualifying files in the order in which it encounters the files in its scan of the file system directory tree.

Using I/O temperature rather than a binary indication of activity, such as the POSIX atime, minimizes the chance of not relocating files that were only accessed occasionally during the period of interest. A large file that has had only a few bytes transferred to or from it would have a low I/O temperature, and would therefore be a candidate for relocation to tier2 volumes, even if the activity was very recent.

But, the greater value of I/O temperature as a file relocation criterion lies in upward re-location: detecting increasing levels of I/O activity against files that had previously been relocated to lower tiers in a storage hierarchy due to inactivity or low temperatures, and relocating them to higher tiers in the storage hierarchy.

The following XML snippet illustrates relocating files from tier2 volumes to tier1 when the activity level against them increases.

<RELOCATE>

<FROM>

<SOURCE>

<CLASS>tier2</CLASS>

</SOURCE>

</FROM>

<TO>

<DESTINATION>

<CLASS>tier1</CLASS>

</DESTINATION>

</TO>

<WHEN>

<IOTEMP Type="nrbytes">

<MAX Flags="gt">5</MAX>

<PERIOD Units="days">2</PERIOD>

</IOTEMP>

</WHEN>

</RELOCATE>

The <RELOCATE> statement specifies that files on tier2 volumes whose I/O temperature as calculated using the number of bytes read is above 5 over a 2-day period are to be relocated to tier1 volumes. Bytes written to the file during the period of interest are not part of this calculation.

Using I/O temperature rather than a binary indicator of activity as a criterion for file relocation gives administrators a granular level of control over automated file relocation that can be used to attune policies to application requirements. For example, specifying a large value in the <PERIOD> element of an upward relocation statement prevents files from being relocated unless I/O activity against them is sustained. Alternatively, specifying a high temperature and a short period tends to relocate files based on short-term intensity of I/O activity against them.