WO2016014035A1

WO2016014035A1 - Files tiering in multi-volume file systems

Info

Publication number: WO2016014035A1
Application number: PCT/US2014/047641
Authority: WO
Inventors: Anand GANJIHAL
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2014-07-22
Filing date: 2014-07-22
Publication date: 2016-01-28

Abstract

In some examples, a tier bit map is loaded into memory, where the tier bit map shows that each of a number of file system objects is stored in one of a number of tiers of a multi-volume file system. A tier request to move a file system object stored on a first tier to a second tier of the plurality of tiers is obtained. The file system object is moved from the first tier to the second tier. In response to receiving confirmation that the file system object is moved, the tier bit map is updated to indicate that the file system object is stored in the second tier.

Description

FILES TIERING IN MULTI-VOLUME FILE SYSTEMS BACKGROUND

[0001 ] Tiered file systems allow storage devices with varying properties to be optimally utilized in a single file system. For example, frequently accessed data can be stored in a first tier with faster storage devices while rarely accessed data can be stored in a second tier with slower storage devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1 is a block diagram of an example computing device for providing file tiering in multi-volume file systems;

[0004] FIG. 2 is a block diagram of an example computing device that includes a tier application for providing file tiering in multi-volume file systems;

[0005] FIG. 3 is a flowchart of an example method for execution by a computing device for providing file tiering in multi-volume file systems; and

[0006] FIGS. 4 and 5 are workflow diagrams showing example multi-volume file system deployments that are configured to provide file tiering. DETAILED DESCRIPTION

[0007] In order to ensure the objects/files in a given file system are in the correct tier group, tiering applications read all the directory entries and for each entry reads the inode/extent maps to examine the existing tier identifiers, which involves reading of multiple on-disk metadata pages. Some implementations try to avoid multiple metadata reads by adding tier identifies to directory entries. In this case, tiering applications can obtain the tier identifiers from directory entries instead of reading inode contents, hence solving the performance problem of reading multiple metadata pages; however, the tier identifiers in the directory entries have to be updated each time an object/file is moved to a different tier. Further, each object/file can be associated with multiple directory entries via hard links that each have to be updated when the object/file is moved, which involves additional metadata reads and directory entry updating.

[0008] As discussed above, tiered applications manage and monitor the tier assignments of files/objects in tiered file systems (e.g., tiered adaptive storage (TAS) system). With the growth of big data, file systems that act as containers of data have also grow in sizes in the petabytes and added support for billions of objects. However, increase in file system sizes and the number of file system objects also places a burden on file system tiering applications to verify each of the many objects and to ensure that files are placed in the correct tier group according user requirements. As the number of objects continue to grow, the performance of tiering applications continues to be impacted.

[0009] In examples described herein, a per file system tier bit map holds the files’ tier identifiers and acts as common place to retrieve/update a tier identifier for a particular file. The tier bit map may be provided and managed by a bitfile access subsystem (BAS) of the tiered file system. The tier bit map abstracts the tier identifiers from directory entries such that tier identifiers can be modified in a single location when a file is moved to a different tier. Typically, directory entries describe the organization structure of the tiered file system by being associated with files contained in a directory and identifying a tier identifier for each file in the directory. In the examples of this disclosure, the directory entries refer to the BAS for tier identifiers so that updates can be performed in a single location. In some examples, a per file system tier bit map includes file system objects metadata such as last modified time and date, user identifier for the actor, file system object size, and/or other relevant file system object metadata that assists in effectively providing file system object tiering.

[0010] In some examples, a tier bit map is loaded into memory, where the tier bit map shows that each of a number of file system objects is stored in one of a number of tiers of a multi-volume file system. At this stage, a tier request to move a file system object stored on a first tier to a second tier of the plurality of tiers is obtained. The file system object is moved from the first tier to the second tier. In response to receiving confirmation that the file system object is moved, the tier bit map is updated to indicate that the file system object is stored in the second tier.

[0011 ] Referring now to the drawings, FIG. 1 is a block diagram of an example computing device 100 for providing file tiering in multi-volume file systems. Computing device 100 may be any computing device such as a server, a desktop computer, a notebook computer, a tablet, etc. In the example of FIG. 1, computing device 100 includes a processor 110, an interface 115, and a machine- readable storage medium 120.

[0012] Processor 110 may be any number of central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 120. Processor 110 may fetch, decode, and execute instructions 122, 124, 126, 128 to provide file tiering in multi-volume file systems, as described below. As an alternative or in addition to retrieving and executing instructions, processor 110 may include any number of electronic circuits comprising a number of electronic components for performing the functionality of instructions 122, 124, 126, and/or 128.

[0013] Interface 115 may include a number of electronic components for communicating with other computing devices. For example, interface 115 may be an Ethernet interface, a Universal Serial Bus (USB) interface, an IEEE 1394 (Firewire) interface, an external Serial Advanced Technology Attachment (eSATA) interface, or any other physical connection interface suitable for communication with storage devices. Alternatively, interface 115 may be a wireless interface, such as a wireless local area network (WLAN) interface or a near-field communication (NFC) interface. In operation, as detailed below, interface 115 may be used to send and receive data to and from a corresponding interface of storage devices.

[0014] Machine-readable storage medium 120 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 120 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. As described in detail below, machine-readable storage medium 120 may be encoded with executable instructions for providing file tiering in multi- volume file systems.

[0015] Tier bit map loading instructions 122 may load a tier bit map into memory of computing device 100. The tier bit map includes a mapping to a tier for each file/object (i.e., file system object) in the tiered file system. The tier bit map is loaded into memory to improve access times to the tier bit map. The directory entries of the tiered file system refers to the tier bit map such that the directory entries indirectly reference files/objects in the tiered file system. The tier bit map can also include metadata describing the files/objects such as last modified date, last modified user, file object size, etc.

[0016] Tier request obtaining instructions 124 may request a tier request to move a file/object from an initial tier to a destination tier. The tier request may be in response to a reallocation resources to the file/object. The tier request can be processed and the transfer can be initiated according to the parameters in the tier request.

[0017] File system object moving instructions 126 may instruct the tiered file system to move the file/object as specified in the tier request. In response, the tiered file system can move the file/object to the destination tier. After the file/object is moved, the tiered file system provides confirmation that the movement is completed. Typically, moving the file/object to a different tier involves moving the file/object to a different storage device with different performance properties.

[0018] Tier bit map updating instructions 128 may update the tier bit map to reflect the file/object’s movement to the destination tier. Specifically, an entry in the tier bit map that is associated with the file/object is updated to reference the file/object’s new position in the destination tier.

[0019] FIG. 2 is a block diagram of an example computing device 200 in communication via a network 245 with a multi-volume file system 270. As illustrated in FIG. 2 and described below, computing device 200 may communicate with multi-volume file system 270 to provide file tiering in multi- volume file systems. As illustrated, computing device 200 may include a number of modules 210-226. Each of the modules may include a series of instructions encoded on a machine-readable storage medium and executable by a processor of the computing device 200. In addition or as an alternative, each module may include any number of hardware devices including electronic circuitry for implementing the functionality described below.

[0020] As with computing device 100 of FIG. 1, computing device 200 may be a server, a desktop computer, a notebook computer, a tablet, or any other device suitable for executing the functionality described below. As detailed below, computing device 200 may include a series of modules 210-226 for enabling dataset file tiering in multi-volume file systems.

[0021 ] Interface module 210 may manage communications with multi-volume file system 270. Specifically, the interface module 210 may initiate connections with multi-volume file system 270 and then send or receive file system date to/from multi-volume file system 270. In some cases, all or a portion of multi- volume file system 270 may be stored locally on computing device 200 so that the functionality described below can be performed without the use of network 245.

[0022] Tier Application 220 may manage objects/files stored in multi-volume file system 270. Although the components of tier application 220 are described in detail below, additional details regarding an example implementation of module 210 are provided above in connection with instructions 122, 124, and 128 of FIG. 1.

[0023] Memory map manager 222 provides tier application 220 with access to tier bit map 272. Specifically, memory map manager 222 is configured to load tier bit map 272 into local memory (not shown) of computing device 200 and then queries tier bit map for tier identifiers of objects/files. Further, memory map manager 222 is configured to update tier bit map 272 according to the movement and/or creation of objects/files. For example, when tier application 220 initially accesses multi-volume file system 270, memory map manager 222 can load tier bit map 272 into local memory. In this example, as files/objects are moved to different tiers of multi-volume file system 270, tier bit map 272 is updated accordingly to reflect the updated tiers of the files/objects.

[0024] File system module 224 performs tier operations of objects/files in multi- volume file system 270. For example, file system module 224 can move an object/file from an initial tier (e.g., tier A 274A) to a destination tier (e.g., tier N 274N). In another example, file system module 224 may obtain metadata for an object/file. In yet another example, file system module 224 retrieves files/objects from multi-volume file system 270. File system module 224 may handle requests from other applications to perform tier operations. File system module 224 may also perform tier operations according to tier configurations as specified by tier configuration module 226.

[0025] Tier configuration module 226 may configure tiers (e.g., tier A 274A, tier N 274N) of multi-volume file system 270. Specifically, tier configuration module 226 may specify the operating parameters of the tiers (e.g., tier A 274A, tier N 274N). For example, tier A 274A may include high performance storage devices (e.g., storage device A 276A) with limited capacity, where tier configuration module 226 specifies that older objects/files stored on the high performance storage devices should be moved to tier N 274N, which may include high capacity storage devices (e.g., storage device N 276N) with low performance, when a threshold capacity is achieved. In this example, tier configuration module 226 may generate a tier query that specifies an object/file should be moved from tier N 274N to tier A 274A when the object/file is accessed at a preconfigured frequency by users. Tier queries to perform tier actions may be generated in response to various triggers created by tier configuration module 226. Examples of tier queries can include“For each file with name *.jpeg then move the file to Tier‘x’” or“For each file with name *.doc then move the file to Tier‘y’”.

[0026] Multi-volume file system 270 is a tiered file system that include multiple tiers (e.g., tier A 274A, tier N 274N) each with multiple storage devices (e.g., storage device A 276A, storage device N 276N). Examples of storage devices (e.g., storage device A 276A, storage device N 276N) include magnetic hard drives, solid state drives, high capacity random access memory, etc. Each tier (e.g., tier A 274A, tier N 274N) may be associated with storage devices (e.g., storage device A 276A, storage device N 276N) with particular properties such as performance, capacity, etc. Tier bit map 272 of multi-volume file system 270 identifies the tier (e.g., tier A 274A, tier N 274N) of each file/object stored in multi- volume file system 270. In other words, tier bit map 272 provides a layer of abstraction with respect to tiers for references to file/objects in multi-volume file system 270.

[0027] FIG. 3 is a flowchart of an example method 300 for execution by a computing device 100 for providing file tiering in multi-volume file systems. Although execution of method 300 is described below with reference to computing device 100 of FIG. 1, other suitable devices for execution of method 300 may be used, such as computing device 200 of FIG. 2. Method 300 may be implemented in the form of executable instructions stored on a machine-readable storage medium and/or in the form of electronic circuitry.

[0028] Method 300 may start in block 305 and continue to block 310, where computing device 100 loads a tier bit map into memory. The tier bit map includes a mapping to a tier for each file/object in the tiered file system. In block 315, computing device 100 requests a tier request to move a file/object from an initial tier to a destination tier.

[0029] In block 320, computing device 100 instructs the tiered file system to move the file/object as specified in the tier request. After the file/object is moved, the tiered file system provides confirmation that the movement is completed. In block 325, the tier bit map is updated to reflect the file/object’s movement to the destination tier. Specifically, an entry in the tier bit map that is associated with the file/object is updated to reference the file/object’s new position in the destination tier. Method 300 may then proceed to block 330, where method 300 ends.

[0030] FIG. 4 is a workflow diagram showing an example multi-volume file system deployment that is configured to provide file tiering. The workflow diagram shows storage device A 402A, storage device N 402N, file system 404, and tier application 406, which may each be similar to their corresponding components described above with respect to FIGS. 1 and 2. [0031 ] In block 420, tier application 406 sends a memory map request to file system 404. The memory map request directs file system 404 to load a tier bit map into memory (not shown) accessible to tier application 406. In block 422, file system 404 loads the tier bit map into the memory. Because the tier bit map is in the memory, access times of tier application 406 when accessing the tier bit map are reduced.

[0032] In block 424, file system 404 sends a map confirmation to tier application 406. The map confirmation notifies tier application 406 that the tier bit map has been loaded into memory. In some cases, the map confirmation can include the location of the tier bit map in memory. In block 426, tier application 406 sends a read directory request to file system 404, which forwards the read directory request to storage device N 402N. The read directory request may specify the target storage device of tier application 406 so that file system 404 can correctly forward the request.

[0033] In block 428, storage device N 402N provides the requested directory page to file system 404. The directory page describes the files included in a directory of file system 404. In block 430, file system 404 sends a directory confirmation to tier application 406. The directory confirmation notifies tier application 406 that the directory page has been loaded by file system 404. Each directory page of storage device N 402N can be iteratively processed as described with respect to FIG. 4 to handle tier configurations for all the file system objects stored in storage device N 402N. In other words, each directory page is processed so that each of the file system objects associated with a directory page can be processed as described below.

[0034] In block 432, tier application 406 sends a tier identifier request for a file in the directory to file system 404. The tier identifier request directs file system 404 to consult metadata in the tier bit map to determine the tier identifier of the file, where the tier identifier denotes the tier of the storage location of the file. In block 434, file system 404 sends the tier identifier of the file to tier application 406. In block 436, tier application 406 uses tier identifier to check a tier configuration to determine if any changes should be requested for the file. For example, a tier query of the tier configuration may specify that the file should be located on a different tier of file system 404. In this example, the tier query matches file metadata associated with the file that can also be stored in the tier bit map.

[0035] In block 438, tier application 406 sends a move file request to file system 404. The move file request directs file system 404 to move the file from a current tier to a target tier of file system 404. In block 440, file system 404 forwards the move file request to storage device N 402N. In response, storage device N 402N can process the move file request and move the file to storage device A 402N in block 442.

[0036] After the move is complete, storage device N 402N sends a confirmation of the movement of the file to file system 404 in block 444. In block 446, file system 404 updates the tier bit map to reflect the movement of the file to the target tier. In block 448, file system 404 sends a confirmation that the move file request has been processed to tier application 406. Each file of the current directory page of storage device N 402N can be iteratively processed as described above to handle tier configurations for all the file system objects stored in the directory page.

[0037] FIG. 5 is a workflow diagram showing an example multi-volume file system deployment that is configured to provide file tiering. The workflow diagram shows storage device A 502A, storage device N 502N, file system 504, and tier application 506, which may each be similar to their corresponding components described above with respect to FIGS. 1 and 2.

[0038] In block 520, tier application 506 sends a tier map request to file system 504. The tier map requests a tier bit map from file system 504. In block 522, file system 504 provides the tier bit map to tier application 506. In block 524, tier application 506 loads the tier bit map into memory that is directly accessible to tier application 506.

[0039] In block 526, tier application 506 sends a read directory request to file system 504, which forwards the read directory request to storage device N 502N. In block 528, storage device N 502N provides the requested directory page to file system 504. In block 530, file system 504 sends a directory confirmation to tier application 506. Each directory page of storage device N 502N can be iteratively processed as described with respect to FIG. 5 to handle tier configurations for all the file system objects stored in storage device N 502N.

[0040] In block 532, tier application 506 checks a tier configuration to determine if any changes should be requested for a file in the directory page. Because tier application 506 can access the tier bit map directly, tier application 506 initially determines the tier identifier of the file by consulting the tier bit map. In this example, tier application 506 can then use the tier identifier to query the tier configuration and determine if any changes should be requested for the file.

[0041 ] In block 534, tier application 506 sends a move file request to file system 504. In block 536, file system 504 forwards the move file request to storage device N 502N. In response, storage device N 502N can process the move file request and move the file to storage device A 502N in block 538.

[0042] After the move is complete, storage device N 502N sends a confirmation of the movement of the file to file system 504 in block 540. In block 542, file system 504 updates the tier bit map to reflect the movement of the file to the target tier. In block 544, file system 504 sends a confirmation that the move file request has been processed to tier application 506. Each file of the current directory page of storage device N 502N can be iteratively processed as described above to handle tier configurations for all the file system objects stored in the directory page.

[0043] The foregoing disclosure describes a number of examples for file tiering in multi-volume file systems. In this manner, the examples disclosed herein facilitate file tiering in multi-volume file systems by using a tier bit map to abstract references to files in the files systems.

Claims

CLAIMS We claim:

1. A system for files tiering in multi-volume file systems, comprising:

a plurality of storage devices that are each assigned to one of a plurality of tiers of a multi-volume file system;

a processor to execute instructions stored on a memory; and

a file system to:

load a tier bit map into the memory, wherein the tier bit map shows that each of a plurality of file system objects is stored in one of the plurality of tiers;

obtain a tier request to move a file system object stored on a first tier to a second tier of the plurality of tiers;

move the file system object from a first storage device assigned to the first tier to a second storage device assigned to the second tier; and in response to receiving confirmation that the file system object is moved, update the tier bit map to indicate that the file system object is stored in the second tier.

2. The system of claim 1 , further comprising a tier application to:

access the tier bit map to obtain a tier identifier for the first tier and file system object metadata associated with the file system object; and

generate the tier request based on the tier identifier and a tier query of a plurality of tier queries in a tier configuration.

3. The system of claim 2, wherein the tier request is generated by:

comparing the file system object metadata of each of the plurality of file system objects to each of the plurality of tier queries;

matching a tier query of the plurality of tier queries matching the file system metadata; and

generating the tier request in response to determining that the tier query specifies the second tier for the file system object.

4. The system of claim 1 , wherein the tier bit map comprises attributes describing the plurality of file system objects, wherein the attributes comprises at least one of a group selected from last modified date, last modified user, and file object size.

5. The system of claim 1, wherein the tier bit map is used by a plurality of directory pages to indirectly reference the plurality of file system objects, wherein each of the plurality of directory pages is associated with a subset of the plurality of file system objects.

6. The system of claim 5, wherein the processor is further to:

request a directory page of the plurality of directory pages from the first storage device;

iteratively compare each of the plurality of file system objects to a plurality of tier queries in a tier configuration; and

generate the tier request based on the file matching one of the plurality of tier queries.

7. A method for files tiering in multi-volume file systems, comprising:

requesting that a tier bit map be loaded into memory, wherein the tier bit map shows that each of a plurality of file system objects is stored in one of a plurality of tiers of a multi-volume file system;

accessing the tier bit map to obtain a tier identifier for a first tier and file system object metadata associated with the file system object;

generating a tier request based on the tier identifier and a tier query of a plurality of tier queries in a tier configuration; and

sending the tier request to move a file system object stored on a first tier to a second tier of the plurality of tiers, wherein the tier bit map is updated to indicate that the file system object has been moved to the second tier by the multi-volume file system.

8. The method of claim 7, wherein generating the tier request further comprises:

matching a tier query of the plurality of tier queries to the file system metadata; and

9. The method of claim 7, wherein the tier bit map comprises attributes describing the plurality of file system objects, wherein the attributes comprises at least one of a group selected from last modified date, last modified user, and file object size.

10. The method of claim 7, wherein the tier bit map is used by a plurality of directory pages to indirectly reference the plurality of file system objects, wherein each of the plurality of directory pages is associated with a subset of the plurality of file system objects.

11. The method of claim 10, further comprising:

requesting a directory page of the plurality of directory pages from the first storage device;

iteratively comparing each of the plurality of file system objects to a plurality of tier queries in a tier configuration; and

generating the tier request based on the file matching one of the plurality of tier queries.

12. A non-transitory machine-readable storage medium encoded with instructions executable by a processor for files tiering in multi-volume file systems, the machine-readable storage medium comprising instructions to: request that a tier bit map be loaded into memory, wherein the tier bit map shows that each of a plurality of file system objects is stored in one of a plurality of tiers of a multi-volume file system;

access the tier bit map to obtain a tier identifier for a first tier and file system object metadata associated with the file system object;

compare the file system object metadata to a tier query of a plurality of tier queries of a tier configuration;

generate a tier request in response to determining that the tier query specifies a second tier for the file system object; and

send the tier request to move a file system object stored on a first tier to a second tier of the plurality of tiers, wherein the tier bit map is updated to indicate that the file system object has been moved to the second tier by the multi-volume file system.

13. The non-transitory machine-readable storage medium of claim 12, wherein the tier bit map comprises attributes describing the plurality of file system objects, wherein the attributes comprises at least one of a group selected from last modified date, last modified user, and file object size.

14. The non-transitory machine-readable storage medium of claim 12, wherein the tier bit map is used by a plurality of directory pages to indirectly reference the plurality of file system objects, wherein each of the plurality of directory pages is associated with a subset of the plurality of file system objects.

15. The non-transitory machine-readable storage medium of claim 14, wherein the machine-readable storage medium further comprises instructions to:

iteratively compare each of the plurality of file system objects to a plurality of tier queries in a tier configuration; and generate the tier request based on the file matching one of the plurality of tier queries.