Thin provisioning of a file system and an iSCSI LUN through a common mechanism

• US 7,631,155 B1
• Filed: 06/30/2007
• Issued: 12/08/2009
• Est. Priority Date: 06/30/2007
• Status: Active Grant

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: EMC Corporation (Dell Technologies Inc.)
• Inventors: Godbole, Saurabh, Mullick, Sachin, Bono, Jean-Pierre, Veeraswamy, Sairam, Vahalia, Uresh K., Hayden, John M., Clark, Morgan A.
• Primary Examiner(s): Elmore; Stephen C
• Application Number:
  US11/772,129
• Time in Patent Office: 892 Days
• Field of Search: 711/156, 711/112, 711/114, 711/170, 711/202, 707/205
• US Class Current: 711/156
• CPC Class Codes: G06F 11/1004 to protect a block of data words, e.g. CRC or checksum G06F11/1076 takes precedence; security arrangements for protecting computers or computer systems against unauthorized activity G06F21/00
• CPC Class Codes: G06F 11/1435 using file system or storage system metadata
• CPC Class Codes: G06F 11/1456 Hardware arrangements for backup
• CPC Class Codes: G06F 16/1727 Details of free space management performed by the file system saving storage space on storage systems G06F3/0608; management of blocks in storage devices G06F3/064
• CPC Class Codes: G06F 2201/84 Using snapshots, i.e. a logical point-in-time copy of the data
• CPC Class Codes: G06F 2211/1088 Scrubbing in RAID systems with parity
• CPC Class Codes: G06F 3/0608 Saving storage space on storage systems
• CPC Class Codes: G06F 3/0665 at area level, e.g. provisioning of virtual or logical volumes
• CPC Class Codes: G06F 3/067 Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
• CPC Class Codes: Y10S 707/99953 Recoverability
• CPC Class Codes: Y10S 707/99956 File allocation

Abstract

A container file system is built on a sparse metavolume for enhanced decoupling of logical storage from physical storage and for providing common supplementary storage services for iSCSI block access and for NFS or CIFS file system access. The container file system contains a production file system or iSCSI LUN and may also contain snapshot copies of the production file system or iSCSI LUN. The container file system manages storage space among the production file system or iSCSI LUN and its snapshot copies, and also improves fault containment. The sparse metavolume provides thin provisioning of the container file system. A slice map indicates whether or not each slice of logical storage in the sparse metavolume is provisioned with an associated configured slice of data storage.

Claims

1. A file server comprising:

data storage containing data of a production file system or a logical unit number (LUN) of storage; and

at least one data processor coupled to the data storage for accessing the data storage;

wherein the production file system or LUN is contained in a file of a container file system in the data storage, the container file system having a logical extent of storage provided by a logical extent of a sparse metavolume of the data storage, the logical extent of the sparse metavolume including slices of logical storage, at least one of the slices of logical storage being provisioned with a configured slice of the data storage containing data of the production file system or LUN;

wherein said at least one data processor is programmed for maintaining a slice map, the slice map indicating whether or not each slice of logical storage in the sparse metavolume is provisioned with an associated configured slice of the data storage; and

said at least one data processor is programmed for responding to requests from at least one client for writing data to and reading data from the production file system or LUN by accessing the slice map for determining a configured slice of the data storage to be written to and read from, and by writing to and reading from the configured slice of the data storage to be written to and read from.

2. The file server as claimed in claim 1, wherein a plurality of logical slices of the sparse metavolume are provisioned with configured slices of the data storage, and each of the configured slices of the data storage includes a respective slice mark, and the respective slice mark includes an identification of the sparse metavolume, an offset of said each of the configured slices of the data storage on the logical extent of the sparse metavolume, and a slice state.

3. The file server as claimed in claim 1, wherein a plurality of slices of the data storage have been configured, and each of the configured slices of the data storage includes a slice state indicating whether or not the slice is free, is being added to a sparse metavolume, has been added to a sparse metavolume, is being released from the sparse metavolume, or is being replaced in the sparse metavolume.

4. The file server as claimed in claim 1, wherein said at least one data processor is further programmed for maintaining a pool of free slices configured from the data storage, and for provisioning a selected logical slice of the sparse metavolume with a configured slice of the data storage removed from the pool of free slices, and for releasing a selected configured slice from the sparse metavolume and returning the released slice to the pool of free slices.

5. The file server as claimed in claim 1, wherein the container file system has a logical extent including a plurality of self-contained cylinder groups, each of the cylinder groups is of a constant cylinder group size, each of the logical slices of the metavolume is of a constant logical slice size, and each logical slice of the sparse metavolume contains a fixed number of the cylinder groups of the container file system.

6. The file server as claimed in claim 1, wherein said at least one data processor is further programmed for maintaining a bitmap indicating configured slices that are provisioned to the sparse metavolume and have free file system blocks, and for accessing the bitmap for selecting a configured slice for allocation of free file system blocks.

7. The file server as claimed in claim 1, wherein said at least one data processor is further programmed for performing a reorganization of the container file system for releasing a selected configured slice provisioned to the sparse metavolume by migrating data of allocated blocks of the container file system from the selected configured slice to another configured slice provisioned to the sparse metavolume, and releasing the selected configured slice from the sparse metavolume once the selected configured slice has been vacated of data of allocated blocks of the container file system.

8. The file server as claimed in claim 7, wherein the container file system has a logical extent including a multiplicity of self-contained cylinder groups, and each slice of logical storage of the sparse metavolume includes a respective plurality of the cylinder groups, and the data processor is further programmed for performing the reorganization of the container file system by stopping new allocations to the cylinder groups in the selected configured slice, moving file system blocks out of the cylinder groups in the selected configured slice, updating files containing the moved file system blocks with new block numbers, and removing cylinder groups from the container file system as the cylinder groups are vacated of file system blocks.

9. The file server as claimed in claim 7, wherein said at least one data processor is further programmed for performing the reorganization of the container file system by maintaining at least one shrink policy, at least one list of slices to be released, at least one list of file system blocks belonging to a slice being vacated, at least one list of inodes having allocated file system blocks from the slice being vacated, and at least one destination list of blocks.

10. The file server as claimed in claim 7, wherein the container file system includes per-block metadata for each allocated block of the container file system, the per-block metadata identifying a file to which said each allocated block of the container file system is allocated, and wherein said at least one data processor is programmed for accessing the per-block metadata when performing the reorganization of the container file system for identifying files of the container file system needing to be updated for new linkages to allocated blocks having data that has been migrated.

11. The file server as claimed in claim 1, wherein said at least one data processor is further programmed for performing a reorganization of the container file system including a change of inode numbers from old inode numbers to respective new inode numbers and for storing records of old inode numbers that have been changed to respective new inode numbers, and for accessing the records when performing an inode lookup for a specified inode number in order to change the specified inode number to a respective one of the new inode numbers when a record is found having an old inode number equal to the specified inode number.

12. A method of operating a file server, said method comprising the steps of:

configuring data storage into slices of the data storage; and

building a container file system upon a sparse metavolume of the data storage, the sparse metavolume including slices of logical storage, at least one of the slices of logical storage being provisioned with one of the configured slices of the data storage, and creating a production file system or a logical unit number (LUN) of the data storage in a file of the container file system; and

maintaining a slice map, the slice map indicating whether or not each slice of logical storage in the sparse metavolume is provisioned with an associated one of the configured slices of the data storage; and

responding to requests from said at least one client for writing data to and reading data from the production file system or LUN by accessing the slice map for determining a configured slice of the data storage to be written to and read from, and by writing to and reading from the configured slice of data storage to be written to and read from.

13. The method as claimed in claim 12, which further includes provisioning a plurality of logical slices of the sparse metavolume with configured slices of the data storage, and including a respective slice mark in each of the configured slices provisioned to the sparse metavolume, wherein the respective slice mark includes an identification of the sparse metavolume, an offset of said each of the configured slices of the data storage on the logical extent of the sparse metavolume, and a slice state.

14. The method as claimed in claim 12, which further includes maintaining a slice state for each of the configured slices of the data storage, wherein the slice state indicates whether or not the slice is free, is being added to a sparse metavolume, has been added to a sparse metavolume, is being released from the sparse metavolume, or is being replaced in the sparse metavolume.

15. The method as claimed in claim 12, which further includes placing the configured slices in a pool of free slices configured from the data storage, provisioning a selected logical slice of the sparse metavolume with a configured slice of the data storage removed from the pool of free slices, and releasing a selected configured slice from the sparse metavolume and returning the released slice to the pool of free slices.

16. The method as claimed in claim 12, which further includes maintaining a bitmap indicating configured slices that are provisioned to the sparse metavolume and have free file system blocks, and accessing the bitmap for selecting a configured slice for allocation of free file system blocks.

17. A method of operating a file server, the file server having data storage containing data of a production file system or a logical unit number (LUN) of storage, wherein the production file system or LUN is contained in a file of a container file system in the data storage, the container file system having a logical extent of storage provided by a logical extent of a sparse metavolume of the data storage, the logical extent of the sparse metavolume including slices of logical storage, at least one of the slices of logical storage being provisioned with at least one configured slice of the data storage containing data of the production file system or LUN, said method comprising the steps of:

maintaining a slice map, the slice map indicating whether or not each slice of logical storage in the sparse metavolume is provisioned with an associated configured slice of the data storage; and

responding to requests from at least one client for writing data to and reading data from the production file system or LUN by accessing the slice map for determining a configured slice of the data storage to be written to and read from, and by writing to and reading from the configured slice of the data storage to be written to and read from.

18. The method as claimed in claim 17 which further includes performing a reorganization of the container file system for releasing a selected configured slice provisioned to the sparse metavolume by migrating data of allocated blocks of the container file system from the selected configured slice to another configured slice provisioned to the sparse metavolume, and releasing the selected configured slice from the sparse metavolume once the selected configured slice has been vacated of data of allocated blocks of the container file system.

19. The method as claimed in claim 18, wherein the container file system includes per-block metadata for each allocated block of the container file system, the per-block metadata identifying a file to which said each allocated block of the container file system is allocated, and wherein the method further includes accessing the per-block metadata when performing the reorganization of the container file system for identifying files of the container file system that are updated for new linkages to allocated blocks having data that has been migrated.

20. The method as claimed in claim 17, which further includes performing a reorganization of the container file system including a change of inode numbers from old inode numbers to respective new inode numbers and for storing records of old inode numbers that have been changed to respective new inode numbers, and for accessing at least one of the records when performing an inode lookup for a specified inode number in order to change the specified inode number to a respective one of the new inode numbers when a record is found having an old inode number equal to the specified inode number.