WO2010033961A1 - Storage system for data virtualization and deduplication - Google Patents

Storage system for data virtualization and deduplication Download PDF

Info

Publication number
WO2010033961A1
WO2010033961A1 PCT/US2009/057772 US2009057772W WO2010033961A1 WO 2010033961 A1 WO2010033961 A1 WO 2010033961A1 US 2009057772 W US2009057772 W US 2009057772W WO 2010033961 A1 WO2010033961 A1 WO 2010033961A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
file
storage
metadata
file system
Prior art date
Application number
PCT/US2009/057772
Other languages
French (fr)
Inventor
Nitin Parab
Original Assignee
Riverbed Technology, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Riverbed Technology, Inc. filed Critical Riverbed Technology, Inc.
Publication of WO2010033961A1 publication Critical patent/WO2010033961A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/174Redundancy elimination performed by the file system
    • G06F16/1748De-duplication implemented within the file system, e.g. based on file segments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638Organizing or formatting or addressing of data
    • G06F3/064Management of blocks
    • G06F3/0641De-duplication techniques

Definitions

  • the present invention relates generally to data storage systems, and systems and methods to improve storage efficiency, compactness, performance, reliability, and compatibility.
  • a file system specifies an arrangement for storing, retrieving, and organizing data files or other types of data on data storage devices, such as hard disk devices.
  • a file system may include functionality for maintaining the physical location or address of data on a data storage device and for providing access to data files from local or remote users or applications.
  • a file system may include functionality for organizing data files, such as directories, folders, or other container structures for files.
  • a file system may maintain file metadata describing attributes of data files, such as the length of the data contained in a file; the time that the file was created, last modified, and/or last accessed; and security features, such as group or owner identification and access permission settings (e.g., whether the file is read-only, executable, etc.).
  • file systems are tasked with handling enormous amounts of data. Additionally, file systems often provide data access to large numbers of simultaneous users and software applications. Users and software applications may access the file system via local communications connections, such as a high-speed data bus within a single computer; local area network connections, such as an Ethernet networking or storage area network (SAN) connection; and wide area network connections, such as the Internet, cellular data networks, and other low-bandwidth, high-latency data communications networks.
  • Storage appliances allow clients access to store and retrieve data on a file system using network storage protocols, such as NFS, and CIFS. Storage appliances often build their file systems using raw disk interfaces to access disk storage systems.
  • a file system may support multiple data streams or file forks for each file.
  • a data stream is an additional data set associated with a file system object.
  • Many file systems allow for multiple independent data streams. Unlike typical file metadata, data streams typically may have any arbitrary size, such as the same size or even larger than the file's primary data. Each data stream is logically separate from other data streams, regardless of how it is physically stored. For files with multiple data streams, file data is typically stored in a primary or default data stream, so that applications that are not aware of streams will be able to access file data.
  • File systems such as NTFS refer to logical data streams as alternate data streams.
  • File systems such as XFS use the term extended attributes to describe additional data streams.
  • Network File Protocols such as CIF and NFSv4 support naming, reading, writing, creating and deleting of additional data streams.
  • Storage virtualization appliances are storage front-ends that export virtual file systems that are built using storage appliances and accessed through file storage protocols.
  • the storage virtualization may present the data and metadata of the file system to clients as a virtual file system, such that the underlying structure and arrangement of data and metadata is hidden from users and applications.
  • the storage virtualization appliance intercepts and processes all client commands to the virtual file system, accesses and optionally updates the data and metadata in the underlying file data and metadata storage in the native file system, and optionally provides a result back to the users or applications.
  • Many storage virtualization appliances do metadata virtualization wherein a virtual directory and files hierarchy is exported from one or more directory/file hierarchies. Such storage virtualization appliances my be referred as metadata virtualization appliance.
  • a data virtualization storage appliance is an storage virtualization system that uses the file/directory hierarchy of exiting storage appliance but for clients' data write operations applies transformations to the data and stores the data in a format different than the format in which client sent the data and on read operations by the client sends the data to the client in client's original format applying transformation on the fly.
  • An embodiment of the invention includes a data virtualization storage appliance that performs data deduplication transformations on the data.
  • the original or non-deduplicated file system is used as shell to hold the directory/file hierarchy and file metadata.
  • the data of the file system is stored by a separate data storage in a transformed and deduplicated form.
  • the deduplicated data store can be implemented as one or more hidden files.
  • the shell file system preserves the hierarchy structure and potentially the file metadata of the original, non-deduplicated file system in its original format, allowing clients to access file metadata and hierarchy information easily.
  • the data of a file is removed from the shell file system and replaced with a data layout that specifies the arrangement of deduplicated data segments needed to reconstruct the file data.
  • the data layout associated with a file may be stored in a separate data stream in the shell file system. In another embodiment, the data layout may be stored in the main data stream of the associated file in the original file system.
  • Figure 1 illustrates an example file system suitable for implementation with embodiments of the invention
  • Figure 2 illustrates an example arrangement of data and metadata of a file system according to an embodiment of the invention
  • Figure 3 illustrates updating data and metadata of a file system according to an embodiment of the invention
  • FIGS 4A-4C illustrate examples of deduplicating data storage according to an embodiment of the invention
  • Figure 5 illustrates a virtual file system stack suitable for implementing file systems according to embodiments of the invention
  • Figures 6A-6C illustrate storing virtual file system layer data in additional file streams according to embodiments of the invention
  • Figure 7 illustrates an example hybrid WAN acceleration and deduplicating data storage system suitable for use with embodiments of the invention.
  • Figure 1 illustrates an example file system 100 suitable for implementation with embodiments of the invention.
  • File system 100 organizes files within a hierarchy of directories.
  • root directory 105 includes directories A 110 and B 115 as well as file A 120.
  • Directory B 115 includes file B 130.
  • Directory A 110 includes directory C 125.
  • Directory C 125 includes file C 135.
  • Each file may include file data and file metadata.
  • File metadata is information maintained by the file system to describe the location and attributes of a file.
  • file C 135 includes file C data 140 and file C metadata 145.
  • the file C metadata 145 includes data defining the file type, the file size, the file's most recent modification date, and access control parameters, such as granting or denying users or applications read and/or write access to the file.
  • Figure 2 illustrates an example arrangement of data and metadata of a file system 200 according to an embodiment of the invention.
  • file system 200 the file data and file metadata are stored in separate logical, and potentially physical, locations. This allows the file system 200 to scale more efficiently over large numbers of storage devices.
  • File system 200 includes metadata storage 205.
  • Metadata storage 205 includes metadata 207 for all of the files and other objects, such as directories, aliases, and symbolic links, stored by the file system.
  • metadata storage 205 may store metadata 207a, 207b, and 207c associated with files A 120, B 130, and C 135 of file system 100 in figure 1, in addition to metadata 207d for any additional files or objects in the file system.
  • File system 200 also includes file data storage 210.
  • File data storage 210 includes data 212 for all of the files and other objects, such as directories, aliases, and symbolic links, stored by the file system.
  • data storage 210 may store data 212a, 212b, and 212c associated with files A 120, B 130, and C 135 of file system 100 in figure 1, in addition to data 212d for any additional files or objects in the file system.
  • the data 212 may be stored in its native format, as specified by applications or users, or, as described in detail below, the data 212 may be transformed, compressed, or otherwise modified to improve storage efficiency, file system speed or performance, or any other aspect of the file system 200.
  • Embodiments of metadata storage 205 and data storage 210 may each be implemented using one or more physical data storage devices 225, such as hard disks or hard disk arrays, tape libraries, optical drives or optical disk libraries, or volatile or non-volatile solid state data storage devices. Metadata storage 205 and data storage 210 may be implemented entirely or partially on the same physical storage devices 225 or may be implemented on separate data storage devices.
  • the physical data storage devices 225 used to implement metadata storage 205 and data storage 210 may each comprise a logical storage device, which in turn is comprised of a number of physical storage devices, such as RAID devices.
  • the metadata storage 205 and data storage 210 are connected with storage front-end 220.
  • storage front-end 220 is connected with the physical storage devices 225 storing metadata storage 205 and data storage 210 via storage network 215.
  • Storage network 215 may include Fibre Channel, InfiniBand, Ethernet, and/or any other type of physical data communication connection between physical storage devices 225 and the storage front-end 220.
  • Storage network 215 may use any data communications or data storage protocol to communicate data between physical storage devices 225 and the front-end 220, including Fibre Channel Protocol, iFCP, and other variations thereof; SCSI, iSCSI, HyperSCSI, and other variations thereof; and ATA over Ethernet and other storage device interfaces.
  • the storage front-end 220 provides file system and data virtualization and is adapted to interface one or more client systems 230 with the data and metadata stored by the file system 200.
  • client means any computer or device accessing the file system 200, including server computers hosting applications and individual user computers.
  • a client 230 may connect with storage front-end via network connection 227, which may include wired or wireless physical data communications connections, for example Fibre Channel, Ethernet and/or 802. Hx wireless networking connection, and may use networking protocols such TCP/IP or Fibre Channel Protocol to communicate with storage front-end 220.
  • the storage front-end 220 may present the data and metadata of the file system 200 to clients as a virtual file system, such that the underlying structure and arrangement of data and metadata within the metadata storage 205 and data storage 210 is hidden from clients
  • the virtual file system provided by storage front-end 220 presents clients 230 with a view of the file system data and metadata as a local or networked file system, such as an XFS, CIFS, or NFS file system. Because the storage front-end 220 presents a virtual file system to one or more clients 230, depending upon the file system protocol, a client may believe that it is managing files and data on a raw volume directly.
  • the storage front-end 220 intercepts and processes all client commands to the virtual file system, accesses and optionally updates the data and metadata in the data storage 210 and metadata storage 205, and optionally provides a result back to the clients 230.
  • the storage front-end may perform data processing, caching, data transformation, data compression, and numerous other operations to translate between the virtual file system and the underlying format of data in the data storage 210 and metadata storage 205.
  • Data virtualization refers to any process or technique for converting data from its original format into a different format for more efficient storage, communication, or processing. Data virtualization also refers to any process or technique for converting virtualized data back to original format for users and applications.
  • Data deduplication is one type of data virtualization that eliminates redundant data for the purposes of storage or communication. To reduce the storage capacity requirements and improve file system performance, embodiments of the invention may be used with a dedup Heating file system that reduces redundant data stored within a single file or over many files.
  • Figures 4A-4C illustrate examples of deduplicating data storage according to an embodiment of the invention.
  • FIG. 4 A illustrates an example 400 of a deduplicating file storage suitable for use with an embodiment of the invention.
  • a file Fl 405 includes file data 406 and file metadata 407.
  • the file data 406 is partitioned or segmented into one or more segments based on factors including the contents of the file data 406, the potential size of a segment, and the type of file data.
  • segmenting data for the purposes of deduplication, some of which make use of hashes or other types of data characterizations.
  • One such approach, which may make use of hashes in some embodiments, is the hierarchical segmentation scheme described in U.S.
  • Hierarchical schemes which make use of hashes may take on a number of variations according to various embodiments, including making use of hashes of hashes.
  • many other segmentation schemes and variations are known in the art and may be used with embodiments of the invention.
  • segment file 408 having its file data represented as segments 409, such as segments 409a, 409b, 409c, and 409d in example 400.
  • segment 409a includes data Dl
  • segment 409c includes data D3.
  • segments 409b and 409d include identical copies of data D2.
  • Segmented file 408 also includes the same file metadata 407 as file 405. In embodiments of the invention, file data segmentation occurs in memory and segmented file 408 is not written back to data storage in this form.
  • each segment is associated with a unique label.
  • segment 409a representing data Dl is associated with label Ll
  • segments 409b and 409d representing data D2 are associated with label L2
  • segment 409c representing data D3 is associated with label L3.
  • the file Fl 405 is replaced with deduplicated file Fl 410.
  • Deduplicated file Fl 410 includes data layout Fl 412 specifying a sequence of labels 413 corresponding with the data segments identified in the file data 406.
  • the data layout Fl 412 includes a sequence of labels Ll 413a, L2 413b, L3 413c, L2 413d, corresponding with the sequence of data segments Dl 409a, D2 409b, D3 409c, and a second instance of segment D2 409d.
  • Deduplicated file 410 also includes a copy of the file metadata 407
  • a data segment storage 415 includes copies of the segment labels and corresponding segment data.
  • data segment storage 415 includes segment data Dl, D2, and D3, and corresponding labels Ll, L2, and L3.
  • a storage system can reconstruct the original file data by matching in sequence each label in a file's data layout with its corresponding segment data from the data segment storage 415.
  • data deduplication reduces the storage required for file Fl 405, assuming that the storage overhead for storing labels 417 in the data layout 415 and data segment storage 415 is negligible. Furthermore, data deduplication can be applied over multiple files to further increase storage efficiency and increase performance.
  • Figure 4B illustrates an example 440 of data deduplication applied over several files.
  • Example 440 continues the example 400 and begins with deduplicated file Fl 410 and data segment storage 415 as described above.
  • Example 440 also includes a second file, file F2 444 including file metadata 448 and file data segmented into data segments Dl 446a, D2 446b, D3 446c, and D4 446d.
  • Data segments 446a, 446b, and 446c are identical in content to the data segments 409a, 409b, and 409c, respectively, discussed in figure 4A.
  • the file F2 444 is replaced with deduplicated file F2 450.
  • Deduplicated file F2 450 includes data layout F2 452 specifying a sequence of labels 454 corresponding with the data segments identified in the file data 446.
  • the data layout F2 452 includes a sequence of labels L5 454c and L4 454d.
  • example 440 replaces deduplicated file Fl 410 with a more efficient deduplicated file Fl 410'.
  • the deduplicated file Fl 410' includes data layout 412' including labels L5 454a and L2 454b.
  • An updated data segment storage 415' includes copies of the segment labels and corresponding segment data.
  • data segment storage 415' includes segment data Dl and labels Ll 417b, segment data D2 and label L2 417c, segment data D3 and label L3 417d, and segment data D4 and label L4 417e.
  • labels may be hierarchical.
  • a hierarchical label is associated with a sequence of one or more additional labels.
  • Each of these additional labels may be associated with data segments or with further labels.
  • data segment storage 415' includes label L5 417a.
  • Label L5 417a is associated with a sequence of labels Ll, L2, and L3, which in turn are associated with data segments Dl, D2, and D3, respectively.
  • labels or label-equivalents may be non-hierarchical.
  • a storage system can reconstruct the original file data of a file by recursively matching in sequence each label in a file's data layout with its corresponding segment data from the data segment storage 415'. For example, an storage system may reconstruct the data of file F2 444 by matching label L5 454c in data layout F2 452 with the sequence of labels "Ll, L2, and L3" using label 417a in data segment storage 415'. The storage system then uses labels Ll 417b, L2 417c, and L3 417d to reconstruct data segments Dl 446a, D2 446b, and D3 446c in file F2. Similarly, label 454d in data layout F2 452 is matched to label 417e in data segment storage 415', which reconstructs data segment D4 446d.
  • Figure 4C illustrates one example of a deduplicating file system 460 according to an embodiment of the invention.
  • File system 460 organizes files within a hierarchy of directories.
  • root directory 465 includes directories A 470 and B 475 as well as file A 480.
  • Directory B 475 includes file B 490.
  • Directory A 470 includes directory C 485.
  • Directory C 485 includes file C 495.
  • each file may include a file data layout and file metadata.
  • file data layout specifies a sequence of labels representing data segments needed to reconstruct the original data of the file.
  • file A 480 includes file A data layout 484 and file C metadata 482
  • file B 490 includes file B data layout 494 and file B metadata 492
  • file C 495 includes file C data layout 499 and file C metadata 497.
  • the data segment storage 462 exists as one or more separate files.
  • the data segment storage 462 is implemented as visible or hidden files on a separate logical storage partition or storage device.
  • the data segment storage 462 is implemented in a manner similar to file data storage 210 discussed above.
  • the deduplicated file system 460 may be implemented, at least in part, using the metadata storage 205 discussed above.
  • file data layout may be stored as the contents of the file.
  • a file system may support multiple data streams or file forks for each file.
  • a data stream is an additional data set associated with a file system object.
  • Many file systems allow for multiple independent data streams. Unlike typical file metadata, data streams typically may have any arbitrary size, such as the same size or even larger than the file's primary data.
  • Each data stream is logically separate from other data streams, regardless of how it is physically stored. For files with multiple data streams, file data is typically stored in a primary or default data stream, so that applications that are not aware of streams will be able to access file data.
  • File systems such as NTFS refer to logical data streams as alternate data streams.
  • File systems such as XFS use the term extended attributes to describe additional data streams.
  • Network file protocols such as CIFS and some versions of NFS also support additional data streams.
  • the data layout of a deduplicated file may be stored in a separate data stream.
  • the primary or default data stream of a file may be empty or contain other data associated with a file object.
  • the deduplicated file system is a "shell" of the original file system.
  • the deduplicated file system preserves the hierarchy structure and potentially the file metadata of the original, non-deduplicated file system in its original format. However, the file data itself is removed from file objects and replaced with data layouts in a different data stream.
  • an embodiment of a storage front-end intercepts the read request. This embodiment then accesses the data layout of the file from the appropriate data stream. Using the data layout, an embodiment of the storage front-end retrieves one or more data segments specified by the data layout to reconstructs all or a portion of the file data. This embodiment of the storage front-end then returns the reconstructed data satisfying the read request to the application or client.
  • an embodiment of the storage front-end intercepts the write request and the data to be stored.
  • the storage front-end transforms the data to be stored into one or more data segments.
  • the storage front-end may perform the data segmentation itself, or, as discussed in detail below, a WAN accelerator may optionally be leveraged to perform data segmentation.
  • Unique labels for each data segment are generated.
  • the label is based on the contents of the data segment, for example using a hash function, so that data segments with identical data will have the same label.
  • An embodiment of the storage front-end then stores the data layout for the write data in the file system, for example in a separate data stream, and stores the associated data segments and labels in the data segment storage.
  • the storage front-end first queries the data segment storage to determines if any of the data segments representing the write data have been previously stored, for example as the result of previous data write operations including the one or more of the same data segments.
  • the storage front-end stores any data segments that have not been previously stored along with their associated labels in the data segment storage.
  • an embodiment of the storage front-end updates label metadata in the data segment storage to indicate that an additional data layout is referencing these previously stored data segments.
  • file system 200 separates the storage of file metadata from the storage of file data for improved efficiency, performance, and scalability.
  • this may create problems when updating both the file data and file metadata.
  • some file data operations for example changing the data in a file, may also cause changes in the file's associated metadata, for example updating the size or modified date metadata.
  • prior systems commonly use a complex and inefficient two- phase commit process to ensure that the updates to the file data and metadata are synchronized and intact.
  • Figure 3 illustrates an example 300 of updating data and metadata of a file system according to an embodiment of the invention.
  • a client 305 sends a command 307 to update or modify file data.
  • This command is intercepted by the storage front-end 310, which converts it into a corresponding data storage command 315.
  • Data storage command 315 is adapted to be processed by a file data storage system 320, which is similar to the file data storage 210 discussed above.
  • data storage command 315 includes metadata transaction parameters 317.
  • the metadata transaction parameters 317 are adapted to update the metadata associated with the file being updated by the data storage command 315. For example, if the command 307 is adapted to change the size of the file, then the corresponding data storage command 315 will include metadata transaction parameters 317 specifying changes in the file size and modified date attributes of the file's metadata.
  • metadata transaction parameters 317 are generated by the storage front-end 310.
  • a client 305 may be capable of communicating directly with the file data storage system 320.
  • the client generates the data storage command 315 and its metadata transaction parameters 317 directly and the command 307 and storage front-end 310 may be bypassed.
  • the data storage command 315 including the metadata transaction parameters 317, is provided to the file data storage 320.
  • the file data storage 320 attempts to modify the appropriate file data as specified by the data storage command 315. If the file data storage 320 is successful in executing the data storage command 315, the file data storage 320 provides the metadata transaction parameters 317 included with the data storage command 315 to a metadata update queue 325.
  • the metadata transaction parameters 317 are atomically committed to the metadata update queue 325 to ensure data integrity.
  • the storage front-end 310 may respond to the command 307 of the client 305 following the completion of the data storage command 315 by file data storage 320, without waiting for the metadata transaction parameters 317 to be processed by the metadata storage 330. This allows storage commands that affect data and metadata to be processed faster than with two-phase commit methods.
  • the metadata update queue 325 temporarily stores one or more sets of metadata transaction parameters until these metadata transaction parameters are processed by the metadata storage 330.
  • the metadata update queue 325 is persistent and durable across system reboots to ensure reliability.
  • the metadata storage 330 retrieves each set of metadata transaction parameters in order of receipt from the metadata update queue 325.
  • the metadata storage 330 processes each set of metadata transaction parameters to update the file metadata of one or more files. As a result of this processing by the metadata storage 330, the file metadata becomes synchronized with the state of the file data.
  • the file data storage 320 and metadata storage 330 operate in parallel to process incoming data update commands and previously queued metadata transaction parameters, respectively.
  • the storage front-end 310 maintains the metadata update queue 325 in its memory. As described above, the storage front-end 310 sends the metadata update operation to the metadata storage 330 after responding to the client data command 307, thus improving performance as the client data command 307 does not have to wait for metadata operation to be processed by the metadata storage 330.
  • the storage front-end 310 may recover unprocessed metadata transaction parameters in the metadata update queue following crashes or restarts. In this embodiment, following a restart, the storage front-end 310 automatically requests all pending metadata transaction parameters previously stored in the metadata update queue 325 from the data storage system. These pending metadata transaction parameters are then processed by the metadata storage system 330.
  • a storage front-end interfaces between the file system in its native format and users and applications.
  • the storage front-end may present the data and metadata of the file system to clients as a virtual file system, such that the underlying structure and arrangement of data and metadata is hidden from users and applications. Instead, the storage front-end presents users and applications with a view of the file system data and metadata as a local or networked file system, such as an XFS, CIFS, or NFS file system. Because the storage front-end presents a virtual file system to one or more users or applications, depending upon the file system protocol, a user or application may believe that it is managing files and data on a raw volume directly.
  • the storage front-end intercepts and processes all client commands to the virtual file system, accesses and optionally updates the data and metadata in the underlying file data and metadata storage in the native file system, and optionally provides a result back to the users or applications.
  • the storage front-end may be implemented as a stack of virtual file system modules.
  • Figure 5 illustrates a virtual file system stack 500 suitable for implementing file systems according to embodiments of the invention.
  • virtual file system stack 500 includes at least one front-end virtual file system layer 505, a data deduplication layer 510, a direct access layer 515, and at least one backend layer 520.
  • the virtual file system layer 505 maintains an in-memory state of the virtual file system, such as files that are open or locked.
  • the virtual file system layer 505 also provides an interface to the virtual file to users and applications.
  • the virtual file system stack 500 includes one or more virtual file system layers that support multiple virtual file systems or other data storage interfaces. This allows for data storage and data transformations such as data deduplication to be consolidated over multiple file systems and data interfaces. For example, if two copies of the same file (or a portion thereof) are stored in separate virtual file systems, the underlying deduplicating data storage will only require one copy of the file data.
  • Other data interfaces such as e-mail server or database application interfaces, may be implemented by the virtual file system layer, allowing for further storage efficiencies.
  • the e-mail server may maintain a copy of the e- mail message and the attached file. However, if the e-mail server's storage is implemented within the deduplicated file system, then no additional copies of the attached file are required.
  • Virtual file system stack 500 also includes a data deduplication layer 510.
  • data deduplication layer 510 performs data deduplication as described above to improve storage efficiency and performance.
  • data deduplication is implemented as described in related application (R000200US, entitled “Log Structured Content Addressable Deduplicating Storage), which is incorporated by reference herein for all purposes.
  • data deduplication layer 510 In addition to data deduplication layer 510, additional data processing and transformation layers may be included in this portion of the virtual file system stack 500 to improve performance, efficiency, reliability, or other aspects of the data storage system, and/or to perform other data processing functions, such as encryption or virus scanning.
  • Virtual file system stack 500 also includes direct access layer 515 adapted to cache the directory hierarchy and metadata.
  • Direct access layer may also include a metadata update queue as described above for updating file metadata efficiently.
  • Virtual file system stack 500 includes at least one backend layer 520 providing an interface between modules in the virtual file system stack 500 and the underlying file system, such as a CIFS, NFS, or other network file system; or XFS, VxFS, or other native file system.
  • Embodiments of virtual file system stack 500 may include one or more backend layers 520 adapted to interface with two or more underlying file systems, allowing two or more separate storage devices or networks to be considered as a single logical storage device or storage network.
  • each stack layer module may wish to include additional metadata with file data being processed.
  • the NTFS file system supports a "creation time" metadata attribute to indicate the creation time of a file object.
  • file systems such as XFS do not natively support this metadata attribute.
  • a front-end virtual file system layer 505 provides a type of virtual file system to users and application, the underlying native file system needs to be able to support all the virtual file system's metadata attributes, even if the native file system is of a different type that does not provide similar metadata attributes.
  • An embodiment of the invention supports arbitrary file metadata attributes in virtual file systems by storing file metadata attributes using one or more additional data streams of the file object.
  • Figures 6A-6C illustrate storing virtual file system layer data in additional file data streams according to embodiments of the invention.
  • a file object includes a single additional data stream adapted to store metadata attributes from one or more virtual file system stack layers.
  • Figure 6 A illustrates an example file Fl 605 including a first data stream 610a adapted to store file data or a corresponding data layout.
  • a second data stream 610b stores additional file metadata from one or more virtual file system stack layers.
  • Figure 6B illustrates an example file Fl 615 including a first data stream 610a adapted to store file data or a corresponding data layout.
  • metadata from each virtual file system stack layer is stored in a separate data stream.
  • data streams 620b, 620c, 62Od, and 62Oe store file metadata associated with the front-end layer 505, data deduplication layer 510, direct access layer 515, and backend layer 520, respectively.
  • FIG. 6C illustrates an example file Fl 630 including a first data stream 635 a adapted to store file data or a corresponding data layout.
  • a second data stream 635b is empty, but has its name set to the additional metadata attribute values provided by one or more virtual file system stack layers.
  • data transformations performed by virtual file system stack layers may alter the metadata attributes of a file.
  • a data deduplication layer reduces the size of file data. Accordingly, the file size metadata attribute for this file should be reduced.
  • the storage front-end should provide the size of the original file to the application, not the actual size of the deduplicated file on disk. Otherwise, the application may not function correctly. In this case, the storage front-end would have to reconstruct the original file from its data layout and the data segment storage to determine the original file size. This operation is inefficient and may be time-consuming, especially if the application does not actually require access to the original file data.
  • an embodiment of the invention sets the file size attribute or other metadata attributes of a transformed data file to the attribute values of the untransformed file.
  • the file size attribute of a deduplicated file may be set to the file size of the original uncompressed file.
  • Many file systems such as NTFS and XFS, allow for the creation of sparse files.
  • a sparse file may have a file size attribute set independently of the actual size of the data in the file. In a sparse file, the file system allocates space for the file as needed.
  • a storage front-end may determine the metadata attributes of untransformed files simply by accessing the metadata of their corresponding transformed files. Little or no intermediate processing or data transformation is required.
  • Embodiments of the invention may be implemented in a variety of forms.
  • an embodiment of the invention may include a storage front-end software and/or hardware adapted to provide one or more virtual file systems and associated interfaces to third-party users and applications, and to interface with one or more third-party data storage devices or storage area networks.
  • storage front-end and/or a virtual file system stack may be integrated with one or more data storage devices or storage area networks.
  • Another embodiment of the invention may be implemented as portions of the above-described virtual file system stack, such as a data deduplication layer module, a direct access layer module, or other data transformation layer modules.
  • the modules including embodiments of the invention are adapted to interface with other third- party modules to form a complete virtual file system stack.
  • the data segmentation and deduplication may be integrated with wide-area network (WAN) acceleration, such as that described in co-pending patent application "Hybrid Segment-Oriented File Server and WAN Accelerator, U.S. Patent.
  • WAN wide-area network
  • the data deduplication storage and WAN acceleration systems use the same type of segmentation scheme to minimize data redundancy.
  • the data deduplicating storage and the WAN acceleration systems communicate using a segment-oriented file system (SFS) protocol adapted to specify data in the form of segments. This allows more efficient storage and communication of data, especially over wide-area networks.
  • FSS segment-oriented file system
  • Figure 7 illustrates an example hybrid WAN acceleration and deduplicating data storage system 1000 suitable for use with embodiments of the invention.
  • Figure 7 depicts one configuration including two segment-orientated file server (SFS) gateways and an SFS server situated at two different sites in a network along with WAN accelerators configured at each site.
  • clients in groups 1090 and 1091 access files ultimately stored on file servers 1040, 1041, and 1042.
  • Local area networks 1010, 1011, 1012, and 1013 provide data communications between clients, SFS gateways, SFS servers, file servers, WAN accelerators, wide-area networks, and other devices.
  • Local area networks 1010, 1011, 1012, and 1013 may include switches, hubs, routers, wireless access points, and other local area networking devices.
  • Local area networks are connected via routers 1020, 1021, 1022, and 1023 with a wide-area network (WAN).
  • WAN wide-area network
  • the clients may access files and data directly using native file server protocols, like CIFS and NFS, or using data interfaces, such as database protocols.
  • file server protocols local or remote clients access file and data by mounting a file system or "file share.”
  • Each file system may be a real file system provided by a file server such as file servers 1040, 1041, and 1042, or a virtual file system provided by a SFS gateway or storage front-end, such as SFS gateways 1072 and 1073.
  • SFS gateway or storage front-end such as SFS gateways 1072 and 1073.
  • a client in group 1091 might access file server 1040 and WAN accelerators 1030 and 1032 would optimize that file server connection, typically providing "LAN-like" performance over the WAN using techniques as those described in U.S. Patent 7,120,666 entitled “Transaction Accelerator for Client-Server Communication Systems”; U.S. Patent 6,667,700 entitled “Content-Based Segmentation Scheme for Data Compression in Storage and Transmission Including Hierarchical Segment Representation”; and U.S. Patent Publication 2004/0215746, published October 28, 2004 entitled “Transparent Client- Server Transaction Accelerator", which are incorporated by reference herein for all purposes.
  • WAN accelerators 1031 and 1033 will optimize network traffic for passage through WAN 1065.
  • each of the WAN accelerators 1031 and 1033 will partition network traffic into data segments, similar to those described above.
  • WAN accelerators 1031 and 1033 will cache frequently used data segments.
  • WAN accelerator 1032 when one of the clients 1090 requests a file, WAN accelerator 1032 reads the requested file from a file system and partitions the file into data segments. WAN accelerator 1032 determines the data layout or set of data segments comprising the requested file. WAN accelerator 1032 communicates the data layout of the requested file to WAN accelerator 1030, which in turn attempts to reconstruct the file using the data layout provided by WAN accelerator 1032 and its cached data segments. Any data segments required by a data layout and not cached by WAN accelerator 1030 may be communicated via WAN 165 to WAN accelerator 1030.
  • SFS gateways 1072 and 1073 export one or more virtual file systems.
  • the SFS gateways 1072 and 1073 may implement data deduplicated storage using the file servers 1040 and/or 1041 to store data segments, data layouts, and file or other metadata.
  • an embodiment of system 1000 allows WAN accelerators to access data segments and data layouts directly in deduplicating data storage using a SFS protocol.
  • WAN accelerator 1032 accesses a SFS gateway, such as SFS gateways 1072 and 1073, or a SFS server, such as SFS server 1050, to retrieve the data layout of the requested file directly.
  • WAN accelerator 1032 then communicates this data layout to WAN accelerator 1030 to reconstruct the requested file from its cached data segments.
  • WAN accelerator 1030 does not have to read the entire requested file and partition it into data segments; instead, the WAN accelerators leverage the segmentation and data layout determinations already employed by the data deduplicating storage.
  • WAN accelerator 1032 can retrieve these additional data segments from an SFS gateway or SFS server using a SFS protocol.
  • WAN accelerator 1032 may retrieve one or more data segments from a file system or SFS server using their associated labels or other identifiers, without requiring any reference to any data layouts or files.
  • SFS server 1050 acts as a combination of a SFS gateway and an associated file server or data storage system.
  • SFS server 1050 manages its own file system on a raw volume directly, e.g., located on a disk array and accessed via iSCSI or Fibre channel over a storage- area network (SAN).
  • SAN storage- area network
  • the SFS server 1050 may include an external disk array as depicted, such as a storage area network, and/or include internal disk-based storage.
  • the SFS server 1050 is configured by an administrator to export one or more virtual file systems or other data interfaces, such as database or e-mail server APIs. Then, a client, for example, from group 1090 mounts one of the exported virtual file systems or interfaces located on SFS server 1050 via a transport connection. This transport connection is then optimized by WAN accelerators 1030 and 1033. Furthermore, because these WAN accelerators are SFS-aware, they intercommunicate with SFS server 1050 using SFS rather than a legacy file protocol like CIFS or NFS. In turn, the SFS server stores all of the data associated with the file system on its internal disks or external storage volume over a SAN.
  • the data deduplication storage system may leverage the use of WAN accelerators to partition incoming data into data segments and determine data layouts. For example, if one of the clients 1090 attempts to write a new file to the storage system, WAN accelerator 1030 will receive the entire file from the client. WAN accelerator
  • WAN accelerator 1030 will send the data layout of this new file to WAN accelerator 1032.
  • WAN accelerator 1030 may also send any new data segments to WAN accelerator 1032 if copies of these data segments are not already in the data storage.
  • WAN accelerator 1032 Upon receiving the data layout of the new file, WAN accelerator 1032 stores the data layout and optionally file metadata in the data deduplicating file system.
  • WAN accelerator 1032, a SFS gateway, and/or a SFS server issues one or more segment operations to store new data segments and to update reference counts and other label metadata for all of the data segments referenced by the new file's data layout.
  • an embodiment of a SFS gateway or SFS server redirects all incoming data from the local client to a local WAN accelerator, such as WAN accelerator 1032, for partitioning into data segments and for determining the data layout.

Abstract

A data virtualization storage appliance performs data deduplication transformations on the data. The original or non-deduplicated file system is used as shell to hold directory/file hierarchy and metadata. The data of the file system is stored by a separate data storage in a transformed and deduplicated form and may be implemented as one or more hidden files. The shell file system preserves the hierarchy structure and potentially the file metadata of the original, non-deduplicated file system in its original format, allowing clients to access file metadata and hierarchy information easily. The data of a file may be removed from the shell file system and replaced with a data layout that specifies the arrangement of deduplicated data segments needed to reconstruct the file data. The data layout associated with a file may be stored in a separate data stream in the shell file system.

Description

STORAGE SYSTEM FOR DATA VIRTUALIZATION AND
DEDUPLICATION
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is related to U.S. Patent Application No. 12/117,629, filed May 8, 2008, and entitled "Hybrid Segment-Oriented File Server and WAN Accelerator"; and U.S. Patent Application No. 12/235,325, filed September 22, 2008, and entitled "Log Structured Content Addressable Deduplicating Storage," both of which are incorporated by reference herein for all purposes.
BACKGROUND
[0002] The present invention relates generally to data storage systems, and systems and methods to improve storage efficiency, compactness, performance, reliability, and compatibility. In computing, a file system specifies an arrangement for storing, retrieving, and organizing data files or other types of data on data storage devices, such as hard disk devices. A file system may include functionality for maintaining the physical location or address of data on a data storage device and for providing access to data files from local or remote users or applications. A file system may include functionality for organizing data files, such as directories, folders, or other container structures for files. Additionally, a file system may maintain file metadata describing attributes of data files, such as the length of the data contained in a file; the time that the file was created, last modified, and/or last accessed; and security features, such as group or owner identification and access permission settings (e.g., whether the file is read-only, executable, etc.).
[0003] Many file systems are tasked with handling enormous amounts of data. Additionally, file systems often provide data access to large numbers of simultaneous users and software applications. Users and software applications may access the file system via local communications connections, such as a high-speed data bus within a single computer; local area network connections, such as an Ethernet networking or storage area network (SAN) connection; and wide area network connections, such as the Internet, cellular data networks, and other low-bandwidth, high-latency data communications networks. Storage appliances allow clients access to store and retrieve data on a file system using network storage protocols, such as NFS, and CIFS. Storage appliances often build their file systems using raw disk interfaces to access disk storage systems.
[0004] A file system may support multiple data streams or file forks for each file. A data stream is an additional data set associated with a file system object. Many file systems allow for multiple independent data streams. Unlike typical file metadata, data streams typically may have any arbitrary size, such as the same size or even larger than the file's primary data. Each data stream is logically separate from other data streams, regardless of how it is physically stored. For files with multiple data streams, file data is typically stored in a primary or default data stream, so that applications that are not aware of streams will be able to access file data. File systems such as NTFS refer to logical data streams as alternate data streams. File systems such as XFS use the term extended attributes to describe additional data streams. Network File Protocols such as CIF and NFSv4 support naming, reading, writing, creating and deleting of additional data streams.
[0005] Storage virtualization appliances are storage front-ends that export virtual file systems that are built using storage appliances and accessed through file storage protocols. The storage virtualization may present the data and metadata of the file system to clients as a virtual file system, such that the underlying structure and arrangement of data and metadata is hidden from users and applications. The storage virtualization appliance intercepts and processes all client commands to the virtual file system, accesses and optionally updates the data and metadata in the underlying file data and metadata storage in the native file system, and optionally provides a result back to the users or applications. Many storage virtualization appliances do metadata virtualization wherein a virtual directory and files hierarchy is exported from one or more directory/file hierarchies. Such storage virtualization appliances my be referred as metadata virtualization appliance. A data virtualization storage appliance is an storage virtualization system that uses the file/directory hierarchy of exiting storage appliance but for clients' data write operations applies transformations to the data and stores the data in a format different than the format in which client sent the data and on read operations by the client sends the data to the client in client's original format applying transformation on the fly. BRIEF SUMMARY
[0006] An embodiment of the invention includes a data virtualization storage appliance that performs data deduplication transformations on the data. In an embodiment, the original or non-deduplicated file system is used as shell to hold the directory/file hierarchy and file metadata. In an embodiment, the data of the file system is stored by a separate data storage in a transformed and deduplicated form. In an embodiment, the deduplicated data store can be implemented as one or more hidden files. The shell file system preserves the hierarchy structure and potentially the file metadata of the original, non-deduplicated file system in its original format, allowing clients to access file metadata and hierarchy information easily.
[0007] In an embodiment, the data of a file is removed from the shell file system and replaced with a data layout that specifies the arrangement of deduplicated data segments needed to reconstruct the file data. In an embodiment, the data layout associated with a file may be stored in a separate data stream in the shell file system. In another embodiment, the data layout may be stored in the main data stream of the associated file in the original file system.
BRIEF DESCRIPTION OF THE DRAWINGS [0008] The invention will be described with reference to the drawings, in which:
Figure 1 illustrates an example file system suitable for implementation with embodiments of the invention;
Figure 2 illustrates an example arrangement of data and metadata of a file system according to an embodiment of the invention;
Figure 3 illustrates updating data and metadata of a file system according to an embodiment of the invention;
Figures 4A-4C illustrate examples of deduplicating data storage according to an embodiment of the invention;
Figure 5 illustrates a virtual file system stack suitable for implementing file systems according to embodiments of the invention;
Figures 6A-6C illustrate storing virtual file system layer data in additional file streams according to embodiments of the invention; and Figure 7 illustrates an example hybrid WAN acceleration and deduplicating data storage system suitable for use with embodiments of the invention.
In the drawings, the use of identical reference numbers indicates identical components.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0009] Figure 1 illustrates an example file system 100 suitable for implementation with embodiments of the invention. File system 100 organizes files within a hierarchy of directories. For example, root directory 105 includes directories A 110 and B 115 as well as file A 120. Directory B 115 includes file B 130. Directory A 110 includes directory C 125. Directory C 125 includes file C 135. Each file may include file data and file metadata. File metadata is information maintained by the file system to describe the location and attributes of a file. For example, file C 135 includes file C data 140 and file C metadata 145. In this example, the file C metadata 145 includes data defining the file type, the file size, the file's most recent modification date, and access control parameters, such as granting or denying users or applications read and/or write access to the file.
[0010] Figure 2 illustrates an example arrangement of data and metadata of a file system 200 according to an embodiment of the invention. In file system 200, the file data and file metadata are stored in separate logical, and potentially physical, locations. This allows the file system 200 to scale more efficiently over large numbers of storage devices.
[0011] File system 200 includes metadata storage 205. Metadata storage 205 includes metadata 207 for all of the files and other objects, such as directories, aliases, and symbolic links, stored by the file system. For example, metadata storage 205 may store metadata 207a, 207b, and 207c associated with files A 120, B 130, and C 135 of file system 100 in figure 1, in addition to metadata 207d for any additional files or objects in the file system.
[0012] File system 200 also includes file data storage 210. File data storage 210 includes data 212 for all of the files and other objects, such as directories, aliases, and symbolic links, stored by the file system. For example, data storage 210 may store data 212a, 212b, and 212c associated with files A 120, B 130, and C 135 of file system 100 in figure 1, in addition to data 212d for any additional files or objects in the file system. The data 212 may be stored in its native format, as specified by applications or users, or, as described in detail below, the data 212 may be transformed, compressed, or otherwise modified to improve storage efficiency, file system speed or performance, or any other aspect of the file system 200. [0013] Embodiments of metadata storage 205 and data storage 210 may each be implemented using one or more physical data storage devices 225, such as hard disks or hard disk arrays, tape libraries, optical drives or optical disk libraries, or volatile or non-volatile solid state data storage devices. Metadata storage 205 and data storage 210 may be implemented entirely or partially on the same physical storage devices 225 or may be implemented on separate data storage devices. The physical data storage devices 225 used to implement metadata storage 205 and data storage 210 may each comprise a logical storage device, which in turn is comprised of a number of physical storage devices, such as RAID devices.
[0014] The metadata storage 205 and data storage 210 are connected with storage front-end 220. In an embodiment, storage front-end 220 is connected with the physical storage devices 225 storing metadata storage 205 and data storage 210 via storage network 215. Storage network 215 may include Fibre Channel, InfiniBand, Ethernet, and/or any other type of physical data communication connection between physical storage devices 225 and the storage front-end 220. Storage network 215 may use any data communications or data storage protocol to communicate data between physical storage devices 225 and the front-end 220, including Fibre Channel Protocol, iFCP, and other variations thereof; SCSI, iSCSI, HyperSCSI, and other variations thereof; and ATA over Ethernet and other storage device interfaces.
[0015] The storage front-end 220 provides file system and data virtualization and is adapted to interface one or more client systems 230 with the data and metadata stored by the file system 200. In this example, the term client means any computer or device accessing the file system 200, including server computers hosting applications and individual user computers. A client 230 may connect with storage front-end via network connection 227, which may include wired or wireless physical data communications connections, for example Fibre Channel, Ethernet and/or 802. Hx wireless networking connection, and may use networking protocols such TCP/IP or Fibre Channel Protocol to communicate with storage front-end 220.
[0016] The storage front-end 220 may present the data and metadata of the file system 200 to clients as a virtual file system, such that the underlying structure and arrangement of data and metadata within the metadata storage 205 and data storage 210 is hidden from clients
230. The virtual file system provided by storage front-end 220 presents clients 230 with a view of the file system data and metadata as a local or networked file system, such as an XFS, CIFS, or NFS file system. Because the storage front-end 220 presents a virtual file system to one or more clients 230, depending upon the file system protocol, a client may believe that it is managing files and data on a raw volume directly. The storage front-end 220 intercepts and processes all client commands to the virtual file system, accesses and optionally updates the data and metadata in the data storage 210 and metadata storage 205, and optionally provides a result back to the clients 230. In processing client commands to the virtual file system, the storage front-end may perform data processing, caching, data transformation, data compression, and numerous other operations to translate between the virtual file system and the underlying format of data in the data storage 210 and metadata storage 205.
[0017] Data virtualization refers to any process or technique for converting data from its original format into a different format for more efficient storage, communication, or processing. Data virtualization also refers to any process or technique for converting virtualized data back to original format for users and applications. Data deduplication is one type of data virtualization that eliminates redundant data for the purposes of storage or communication. To reduce the storage capacity requirements and improve file system performance, embodiments of the invention may be used with a dedup Heating file system that reduces redundant data stored within a single file or over many files. Figures 4A-4C illustrate examples of deduplicating data storage according to an embodiment of the invention.
[0018] Figure 4 A illustrates an example 400 of a deduplicating file storage suitable for use with an embodiment of the invention. A file Fl 405 includes file data 406 and file metadata 407. In an embodiment, the file data 406 is partitioned or segmented into one or more segments based on factors including the contents of the file data 406, the potential size of a segment, and the type of file data. There are many possible approaches for segmenting data for the purposes of deduplication, some of which make use of hashes or other types of data characterizations. One such approach, which may make use of hashes in some embodiments, is the hierarchical segmentation scheme described in U.S. Patent 6,667,700 entitled "Content- Based Segmentation Scheme for Data Compression in Storage and Transmission Including Hierarchical Segment Representation," which is incorporated by reference herein for all purposes. Hierarchical schemes which make use of hashes may take on a number of variations according to various embodiments, including making use of hashes of hashes. In addition, many other segmentation schemes and variations are known in the art and may be used with embodiments of the invention.
[0019] Regardless of the technique used to segment file data 407, the result is a segmented file 408 having its file data represented as segments 409, such as segments 409a, 409b, 409c, and 409d in example 400. In example 400, segment 409a includes data Dl and segment 409c includes data D3. Additionally, segments 409b and 409d include identical copies of data D2. Segmented file 408 also includes the same file metadata 407 as file 405. In embodiments of the invention, file data segmentation occurs in memory and segmented file 408 is not written back to data storage in this form.
[0020] Following the segmentation of the file data 406 into file segments 409, each segment is associated with a unique label. In example 400, segment 409a representing data Dl is associated with label Ll, segments 409b and 409d representing data D2 are associated with label L2, and segment 409c representing data D3 is associated with label L3. In an embodiment, the file Fl 405 is replaced with deduplicated file Fl 410. Deduplicated file Fl 410 includes data layout Fl 412 specifying a sequence of labels 413 corresponding with the data segments identified in the file data 406. In this example, the data layout Fl 412 includes a sequence of labels Ll 413a, L2 413b, L3 413c, L2 413d, corresponding with the sequence of data segments Dl 409a, D2 409b, D3 409c, and a second instance of segment D2 409d. Deduplicated file 410 also includes a copy of the file metadata 407
[0021] A data segment storage 415 includes copies of the segment labels and corresponding segment data. In example 400, data segment storage 415 includes segment data Dl, D2, and D3, and corresponding labels Ll, L2, and L3. Using the data layout within a file and the data segment storage 415, a storage system can reconstruct the original file data by matching in sequence each label in a file's data layout with its corresponding segment data from the data segment storage 415.
[0022] As shown in example 400 of figure 4A, the use of data deduplication reduces the storage required for file Fl 405, assuming that the storage overhead for storing labels 417 in the data layout 415 and data segment storage 415 is negligible. Furthermore, data deduplication can be applied over multiple files to further increase storage efficiency and increase performance.
[0023] Figure 4B illustrates an example 440 of data deduplication applied over several files. Example 440 continues the example 400 and begins with deduplicated file Fl 410 and data segment storage 415 as described above. Example 440 also includes a second file, file F2 444 including file metadata 448 and file data segmented into data segments Dl 446a, D2 446b, D3 446c, and D4 446d. Data segments 446a, 446b, and 446c are identical in content to the data segments 409a, 409b, and 409c, respectively, discussed in figure 4A.
[0024] In an embodiment, the file F2 444 is replaced with deduplicated file F2 450. Deduplicated file F2 450 includes data layout F2 452 specifying a sequence of labels 454 corresponding with the data segments identified in the file data 446. In this example, the data layout F2 452 includes a sequence of labels L5 454c and L4 454d. Additionally, example 440 replaces deduplicated file Fl 410 with a more efficient deduplicated file Fl 410'. The deduplicated file Fl 410' includes data layout 412' including labels L5 454a and L2 454b.
[0025] An updated data segment storage 415' includes copies of the segment labels and corresponding segment data. In example 440, data segment storage 415' includes segment data Dl and labels Ll 417b, segment data D2 and label L2 417c, segment data D3 and label L3 417d, and segment data D4 and label L4 417e.
[0026] Additionally, in this example implementation of data deduplication, labels may be hierarchical. A hierarchical label is associated with a sequence of one or more additional labels. Each of these additional labels may be associated with data segments or with further labels. For example, data segment storage 415' includes label L5 417a. Label L5 417a is associated with a sequence of labels Ll, L2, and L3, which in turn are associated with data segments Dl, D2, and D3, respectively. In other embodiments, labels or label-equivalents may be non-hierarchical.
[0027] Using the data layout within a file and the data segment storage 415', a storage system can reconstruct the original file data of a file by recursively matching in sequence each label in a file's data layout with its corresponding segment data from the data segment storage 415'. For example, an storage system may reconstruct the data of file F2 444 by matching label L5 454c in data layout F2 452 with the sequence of labels "Ll, L2, and L3" using label 417a in data segment storage 415'. The storage system then uses labels Ll 417b, L2 417c, and L3 417d to reconstruct data segments Dl 446a, D2 446b, and D3 446c in file F2. Similarly, label 454d in data layout F2 452 is matched to label 417e in data segment storage 415', which reconstructs data segment D4 446d.
[0028] The data layouts and file system metadata of files in a deduplicating data storage system may be arranged in a number of ways. Figure 4C illustrates one example of a deduplicating file system 460 according to an embodiment of the invention. File system 460 organizes files within a hierarchy of directories. For example, root directory 465 includes directories A 470 and B 475 as well as file A 480. Directory B 475 includes file B 490. Directory A 470 includes directory C 485. Directory C 485 includes file C 495.
[0029] In example file system 460, each file may include a file data layout and file metadata. As described above, file data layout specifies a sequence of labels representing data segments needed to reconstruct the original data of the file. For example, file A 480 includes file A data layout 484 and file C metadata 482, file B 490 includes file B data layout 494 and file B metadata 492, and file C 495 includes file C data layout 499 and file C metadata 497.
[0030] The data segment storage 462 exists as one or more separate files. In an embodiment, the data segment storage 462 is implemented as visible or hidden files on a separate logical storage partition or storage device. In a further embodiment, the data segment storage 462 is implemented in a manner similar to file data storage 210 discussed above. Additionally, the deduplicated file system 460 may be implemented, at least in part, using the metadata storage 205 discussed above.
[0031] In an embodiment, file data layout may be stored as the contents of the file.
[0032] A file system may support multiple data streams or file forks for each file. A data stream is an additional data set associated with a file system object. Many file systems allow for multiple independent data streams. Unlike typical file metadata, data streams typically may have any arbitrary size, such as the same size or even larger than the file's primary data. Each data stream is logically separate from other data streams, regardless of how it is physically stored. For files with multiple data streams, file data is typically stored in a primary or default data stream, so that applications that are not aware of streams will be able to access file data. File systems such as NTFS refer to logical data streams as alternate data streams. File systems such as XFS use the term extended attributes to describe additional data streams. Network file protocols such as CIFS and some versions of NFS also support additional data streams.
[0033] In an embodiment, the data layout of a deduplicated file may be stored in a separate data stream. The primary or default data stream of a file may be empty or contain other data associated with a file object. In this embodiment, the deduplicated file system is a "shell" of the original file system. The deduplicated file system preserves the hierarchy structure and potentially the file metadata of the original, non-deduplicated file system in its original format. However, the file data itself is removed from file objects and replaced with data layouts in a different data stream.
[0034] When an application or client attempts to read file data from a file system, an embodiment of a storage front-end intercepts the read request. This embodiment then accesses the data layout of the file from the appropriate data stream. Using the data layout, an embodiment of the storage front-end retrieves one or more data segments specified by the data layout to reconstructs all or a portion of the file data. This embodiment of the storage front-end then returns the reconstructed data satisfying the read request to the application or client.
[0035] Similarly, when an application or client attempts to write file data to a file system, an embodiment of the storage front-end intercepts the write request and the data to be stored. The storage front-end transforms the data to be stored into one or more data segments. The storage front-end may perform the data segmentation itself, or, as discussed in detail below, a WAN accelerator may optionally be leveraged to perform data segmentation. Unique labels for each data segment are generated. In an embodiment, the label is based on the contents of the data segment, for example using a hash function, so that data segments with identical data will have the same label.
[0036] An embodiment of the storage front-end then stores the data layout for the write data in the file system, for example in a separate data stream, and stores the associated data segments and labels in the data segment storage. In an embodiment, the storage front-end first queries the data segment storage to determines if any of the data segments representing the write data have been previously stored, for example as the result of previous data write operations including the one or more of the same data segments. The storage front-end stores any data segments that have not been previously stored along with their associated labels in the data segment storage. For data segments that have been previously stored in the data segment storage, an embodiment of the storage front-end updates label metadata in the data segment storage to indicate that an additional data layout is referencing these previously stored data segments.
[0037] As shown in figure 2, file system 200 separates the storage of file metadata from the storage of file data for improved efficiency, performance, and scalability. However, this may create problems when updating both the file data and file metadata. For example, some file data operations, for example changing the data in a file, may also cause changes in the file's associated metadata, for example updating the size or modified date metadata. With separate storage of file data and metadata, prior systems commonly use a complex and inefficient two- phase commit process to ensure that the updates to the file data and metadata are synchronized and intact.
[0038] Figure 3 illustrates an example 300 of updating data and metadata of a file system according to an embodiment of the invention. In example 300, a client 305 sends a command 307 to update or modify file data. This command is intercepted by the storage front-end 310, which converts it into a corresponding data storage command 315. Data storage command 315 is adapted to be processed by a file data storage system 320, which is similar to the file data storage 210 discussed above.
[0039] In an embodiment, data storage command 315 includes metadata transaction parameters 317. The metadata transaction parameters 317 are adapted to update the metadata associated with the file being updated by the data storage command 315. For example, if the command 307 is adapted to change the size of the file, then the corresponding data storage command 315 will include metadata transaction parameters 317 specifying changes in the file size and modified date attributes of the file's metadata.
[0040] In an embodiment, metadata transaction parameters 317 are generated by the storage front-end 310. In an alternate embodiment, a client 305 may be capable of communicating directly with the file data storage system 320. In this embodiment, the client generates the data storage command 315 and its metadata transaction parameters 317 directly and the command 307 and storage front-end 310 may be bypassed.
[0041] In an embodiment, the data storage command 315, including the metadata transaction parameters 317, is provided to the file data storage 320. In response to receiving the data storage command 315, the file data storage 320 attempts to modify the appropriate file data as specified by the data storage command 315. If the file data storage 320 is successful in executing the data storage command 315, the file data storage 320 provides the metadata transaction parameters 317 included with the data storage command 315 to a metadata update queue 325. In an embodiment, the metadata transaction parameters 317 are atomically committed to the metadata update queue 325 to ensure data integrity. Conversely, if the file data storage 320 is not successful in executing the data storage command 315, then the metadata transaction parameters 317 are discarded and an error or other response may be returned to the storage front-end 310 and/or the client 305. In an embodiment, the storage front-end 310 may respond to the command 307 of the client 305 following the completion of the data storage command 315 by file data storage 320, without waiting for the metadata transaction parameters 317 to be processed by the metadata storage 330. This allows storage commands that affect data and metadata to be processed faster than with two-phase commit methods.
[0042] The metadata update queue 325 temporarily stores one or more sets of metadata transaction parameters until these metadata transaction parameters are processed by the metadata storage 330. In an embodiment, the metadata update queue 325 is persistent and durable across system reboots to ensure reliability. In an embodiment, the metadata storage 330 retrieves each set of metadata transaction parameters in order of receipt from the metadata update queue 325. The metadata storage 330 processes each set of metadata transaction parameters to update the file metadata of one or more files. As a result of this processing by the metadata storage 330, the file metadata becomes synchronized with the state of the file data. In an embodiment, the file data storage 320 and metadata storage 330 operate in parallel to process incoming data update commands and previously queued metadata transaction parameters, respectively.
[0043] In an embodiment, the storage front-end 310 maintains the metadata update queue 325 in its memory. As described above, the storage front-end 310 sends the metadata update operation to the metadata storage 330 after responding to the client data command 307, thus improving performance as the client data command 307 does not have to wait for metadata operation to be processed by the metadata storage 330. In a further embodiment, the storage front-end 310 may recover unprocessed metadata transaction parameters in the metadata update queue following crashes or restarts. In this embodiment, following a restart, the storage front-end 310 automatically requests all pending metadata transaction parameters previously stored in the metadata update queue 325 from the data storage system. These pending metadata transaction parameters are then processed by the metadata storage system 330.
[0044] As discussed above, changing the structure of a file system, the arrangement of file data and metadata, and data transformations such as data duplication can improve the efficiency, performance, scalability, and even the reliability of data storage systems. However, applications and users typically expect to interact with more typically structured file systems and file data.
[0045] Because of this need, a storage front-end interfaces between the file system in its native format and users and applications. The storage front-end may present the data and metadata of the file system to clients as a virtual file system, such that the underlying structure and arrangement of data and metadata is hidden from users and applications. Instead, the storage front-end presents users and applications with a view of the file system data and metadata as a local or networked file system, such as an XFS, CIFS, or NFS file system. Because the storage front-end presents a virtual file system to one or more users or applications, depending upon the file system protocol, a user or application may believe that it is managing files and data on a raw volume directly. The storage front-end intercepts and processes all client commands to the virtual file system, accesses and optionally updates the data and metadata in the underlying file data and metadata storage in the native file system, and optionally provides a result back to the users or applications.
[0046] Because of the wide range of data and metadata processing, interfacing, caching, data transformation and compression, and numerous other operations to translate between the virtual file system and the underlying format of data, the storage front-end may be implemented as a stack of virtual file system modules. Figure 5 illustrates a virtual file system stack 500 suitable for implementing file systems according to embodiments of the invention.
[0047] In an embodiment, virtual file system stack 500 includes at least one front-end virtual file system layer 505, a data deduplication layer 510, a direct access layer 515, and at least one backend layer 520. The virtual file system layer 505 maintains an in-memory state of the virtual file system, such as files that are open or locked. The virtual file system layer 505 also provides an interface to the virtual file to users and applications.
[0048] In a further embodiment, the virtual file system stack 500 includes one or more virtual file system layers that support multiple virtual file systems or other data storage interfaces. This allows for data storage and data transformations such as data deduplication to be consolidated over multiple file systems and data interfaces. For example, if two copies of the same file (or a portion thereof) are stored in separate virtual file systems, the underlying deduplicating data storage will only require one copy of the file data. Other data interfaces, such as e-mail server or database application interfaces, may be implemented by the virtual file system layer, allowing for further storage efficiencies. For example, if a file stored in a file system is e-mailed by a user, the e-mail server may maintain a copy of the e- mail message and the attached file. However, if the e-mail server's storage is implemented within the deduplicated file system, then no additional copies of the attached file are required.
[0049] Virtual file system stack 500 also includes a data deduplication layer 510. In an embodiment, data deduplication layer 510 performs data deduplication as described above to improve storage efficiency and performance. In an additional embodiment, data deduplication is implemented as described in related application (R000200US, entitled "Log Structured Content Addressable Deduplicating Storage), which is incorporated by reference herein for all purposes.
[0050] In addition to data deduplication layer 510, additional data processing and transformation layers may be included in this portion of the virtual file system stack 500 to improve performance, efficiency, reliability, or other aspects of the data storage system, and/or to perform other data processing functions, such as encryption or virus scanning.
[0051] Virtual file system stack 500 also includes direct access layer 515 adapted to cache the directory hierarchy and metadata. Direct access layer may also include a metadata update queue as described above for updating file metadata efficiently.
[0052] Virtual file system stack 500 includes at least one backend layer 520 providing an interface between modules in the virtual file system stack 500 and the underlying file system, such as a CIFS, NFS, or other network file system; or XFS, VxFS, or other native file system. Embodiments of virtual file system stack 500 may include one or more backend layers 520 adapted to interface with two or more underlying file systems, allowing two or more separate storage devices or networks to be considered as a single logical storage device or storage network.
[0053] One problem with using a file system stack such as virtual file system stack 500 is that each stack layer module may wish to include additional metadata with file data being processed. For example, the NTFS file system supports a "creation time" metadata attribute to indicate the creation time of a file object. However, file systems such as XFS do not natively support this metadata attribute. If a front-end virtual file system layer 505 provides a type of virtual file system to users and application, the underlying native file system needs to be able to support all the virtual file system's metadata attributes, even if the native file system is of a different type that does not provide similar metadata attributes. [0054] An embodiment of the invention supports arbitrary file metadata attributes in virtual file systems by storing file metadata attributes using one or more additional data streams of the file object. Figures 6A-6C illustrate storing virtual file system layer data in additional file data streams according to embodiments of the invention.
[0055] In one embodiment, a file object includes a single additional data stream adapted to store metadata attributes from one or more virtual file system stack layers. Figure 6 A illustrates an example file Fl 605 including a first data stream 610a adapted to store file data or a corresponding data layout. A second data stream 610b stores additional file metadata from one or more virtual file system stack layers.
[0056] Figure 6B illustrates an example file Fl 615 including a first data stream 610a adapted to store file data or a corresponding data layout. In this example file Fl 615, metadata from each virtual file system stack layer is stored in a separate data stream. For example, data streams 620b, 620c, 62Od, and 62Oe store file metadata associated with the front-end layer 505, data deduplication layer 510, direct access layer 515, and backend layer 520, respectively.
[0057] In another embodiment, additional file metadata is stored using an additional data stream. However, the contents of this additional data stream remains empty. Instead, the additional file metadata is stored in the name of the additional data stream. This embodiment is useful when reading or writing additional data streams is slower or less efficient than reading or writing the name of an additional data stream. Figure 6C illustrates an example file Fl 630 including a first data stream 635 a adapted to store file data or a corresponding data layout. A second data stream 635b is empty, but has its name set to the additional metadata attribute values provided by one or more virtual file system stack layers.
[0058] Additionally, data transformations performed by virtual file system stack layers may alter the metadata attributes of a file. For example, a data deduplication layer reduces the size of file data. Accordingly, the file size metadata attribute for this file should be reduced.
However, many file system operations require metadata access. If the metadata attributes of a file have been changed due to a data transformation, such as data deduplication, then the expected original file metadata attribute values will need to be reconstructed by the storage front-end.
[0059] For example, if an application requests the file size of a file that has been reduced in size using data deduplication, the storage front-end should provide the size of the original file to the application, not the actual size of the deduplicated file on disk. Otherwise, the application may not function correctly. In this case, the storage front-end would have to reconstruct the original file from its data layout and the data segment storage to determine the original file size. This operation is inefficient and may be time-consuming, especially if the application does not actually require access to the original file data.
[0060] To improve efficiency in accessing metadata attributes, an embodiment of the invention sets the file size attribute or other metadata attributes of a transformed data file to the attribute values of the untransformed file. For example, the file size attribute of a deduplicated file may be set to the file size of the original uncompressed file. Many file systems, such as NTFS and XFS, allow for the creation of sparse files. A sparse file may have a file size attribute set independently of the actual size of the data in the file. In a sparse file, the file system allocates space for the file as needed.
[0061] Because the metadata attributes of transformed files are set to the values of their untransformed files, a storage front-end may determine the metadata attributes of untransformed files simply by accessing the metadata of their corresponding transformed files. Little or no intermediate processing or data transformation is required.
[0062] Embodiments of the invention may be implemented in a variety of forms. For example, an embodiment of the invention may include a storage front-end software and/or hardware adapted to provide one or more virtual file systems and associated interfaces to third-party users and applications, and to interface with one or more third-party data storage devices or storage area networks. In a further embodiment, storage front-end and/or a virtual file system stack may be integrated with one or more data storage devices or storage area networks.
[0063] Another embodiment of the invention may be implemented as portions of the above-described virtual file system stack, such as a data deduplication layer module, a direct access layer module, or other data transformation layer modules. In this embodiment, the modules including embodiments of the invention are adapted to interface with other third- party modules to form a complete virtual file system stack.
[0064] In still further embodiments, the data segmentation and deduplication may be integrated with wide-area network (WAN) acceleration, such as that described in co-pending patent application "Hybrid Segment-Oriented File Server and WAN Accelerator, U.S. Patent.
Application No. 12/117,269, filed May 8, 2008. In these embodiments, the data deduplication storage and WAN acceleration systems use the same type of segmentation scheme to minimize data redundancy. The data deduplicating storage and the WAN acceleration systems communicate using a segment-oriented file system (SFS) protocol adapted to specify data in the form of segments. This allows more efficient storage and communication of data, especially over wide-area networks.
[0065] Figure 7 illustrates an example hybrid WAN acceleration and deduplicating data storage system 1000 suitable for use with embodiments of the invention. Figure 7 depicts one configuration including two segment-orientated file server (SFS) gateways and an SFS server situated at two different sites in a network along with WAN accelerators configured at each site. In this configuration, clients in groups 1090 and 1091 access files ultimately stored on file servers 1040, 1041, and 1042. Local area networks 1010, 1011, 1012, and 1013 provide data communications between clients, SFS gateways, SFS servers, file servers, WAN accelerators, wide-area networks, and other devices. Local area networks 1010, 1011, 1012, and 1013 may include switches, hubs, routers, wireless access points, and other local area networking devices. Local area networks are connected via routers 1020, 1021, 1022, and 1023 with a wide-area network (WAN).
[0066] The clients may access files and data directly using native file server protocols, like CIFS and NFS, or using data interfaces, such as database protocols. In the case of file server protocols, local or remote clients access file and data by mounting a file system or "file share." Each file system may be a real file system provided by a file server such as file servers 1040, 1041, and 1042, or a virtual file system provided by a SFS gateway or storage front-end, such as SFS gateways 1072 and 1073. Once a file system is mounted via a transport connection, files can be accessed and manipulated over that connection by applications or file system tools invoked by the user. Traditionally, these protocols have performed poorly over the WAN but are accelerated by the WAN accelerators present in the network.
[0067] For example, a client in group 1091 might access file server 1040 and WAN accelerators 1030 and 1032 would optimize that file server connection, typically providing "LAN-like" performance over the WAN using techniques as those described in U.S. Patent 7,120,666 entitled "Transaction Accelerator for Client-Server Communication Systems"; U.S. Patent 6,667,700 entitled "Content-Based Segmentation Scheme for Data Compression in Storage and Transmission Including Hierarchical Segment Representation"; and U.S. Patent Publication 2004/0215746, published October 28, 2004 entitled "Transparent Client- Server Transaction Accelerator", which are incorporated by reference herein for all purposes.
[0068] If a client, for example, from group 1091, mounts one of the exported file systems located on SFS gateway 1073 via a transport connection including WAN 1065, WAN accelerators 1031 and 1033 will optimize network traffic for passage through WAN 1065. In an embodiment, each of the WAN accelerators 1031 and 1033 will partition network traffic into data segments, similar to those described above. WAN accelerators 1031 and 1033 will cache frequently used data segments.
[0069] In an example of prior systems, when one of the clients 1090 requests a file, WAN accelerator 1032 reads the requested file from a file system and partitions the file into data segments. WAN accelerator 1032 determines the data layout or set of data segments comprising the requested file. WAN accelerator 1032 communicates the data layout of the requested file to WAN accelerator 1030, which in turn attempts to reconstruct the file using the data layout provided by WAN accelerator 1032 and its cached data segments. Any data segments required by a data layout and not cached by WAN accelerator 1030 may be communicated via WAN 165 to WAN accelerator 1030.
[0070] Further benefits are achieved, however, by arranging for clients to access the files stored on file servers 1040, 1041 and 1042 via the SFS gateways 1072 and 1073 or SFS server 1050. In this scenario, SFS gateways 1072 and 1073 export one or more virtual file systems. The SFS gateways 1072 and 1073 may implement data deduplicated storage using the file servers 1040 and/or 1041 to store data segments, data layouts, and file or other metadata.
[0071] To improve performance, an embodiment of system 1000 allows WAN accelerators to access data segments and data layouts directly in deduplicating data storage using a SFS protocol. In this embodiment, when one of the clients 1090 requests a file, WAN accelerator 1032 accesses a SFS gateway, such as SFS gateways 1072 and 1073, or a SFS server, such as SFS server 1050, to retrieve the data layout of the requested file directly. WAN accelerator 1032 then communicates this data layout to WAN accelerator 1030 to reconstruct the requested file from its cached data segments. The advantage to this approach is that WAN accelerator 1030 does not have to read the entire requested file and partition it into data segments; instead, the WAN accelerators leverage the segmentation and data layout determinations already employed by the data deduplicating storage. [0072] Furthermore, if WAN accelerator 1030 requires data segments that are not locally cached to reconstruct some or all of the requested file, WAN accelerator 1032 can retrieve these additional data segments from an SFS gateway or SFS server using a SFS protocol. In this example, WAN accelerator 1032 may retrieve one or more data segments from a file system or SFS server using their associated labels or other identifiers, without requiring any reference to any data layouts or files.
[0073] The benefits of the SFS architecture can accrue to an SFS file server as depicted in Figure 7, whereby SFS server 1050 is interconnected to disk array 1060. In an embodiment, the SFS server acts as a combination of a SFS gateway and an associated file server or data storage system. For example, SFS server 1050 manages its own file system on a raw volume directly, e.g., located on a disk array and accessed via iSCSI or Fibre channel over a storage- area network (SAN). In this scenario, there is no need for backend file servers, because the SFS server 1050 implements or interfaces with its own data storage system. The SFS server 1050 may include an external disk array as depicted, such as a storage area network, and/or include internal disk-based storage.
[0074] The SFS server 1050 is configured by an administrator to export one or more virtual file systems or other data interfaces, such as database or e-mail server APIs. Then, a client, for example, from group 1090 mounts one of the exported virtual file systems or interfaces located on SFS server 1050 via a transport connection. This transport connection is then optimized by WAN accelerators 1030 and 1033. Furthermore, because these WAN accelerators are SFS-aware, they intercommunicate with SFS server 1050 using SFS rather than a legacy file protocol like CIFS or NFS. In turn, the SFS server stores all of the data associated with the file system on its internal disks or external storage volume over a SAN.
[0075] In a further embodiment, the data deduplication storage system may leverage the use of WAN accelerators to partition incoming data into data segments and determine data layouts. For example, if one of the clients 1090 attempts to write a new file to the storage system, WAN accelerator 1030 will receive the entire file from the client. WAN accelerator
1030 will partition the received file into data segments and a corresponding data layout.
WAN accelerator 1030 will send the data layout of this new file to WAN accelerator 1032. WAN accelerator 1030 may also send any new data segments to WAN accelerator 1032 if copies of these data segments are not already in the data storage. Upon receiving the data layout of the new file, WAN accelerator 1032 stores the data layout and optionally file metadata in the data deduplicating file system. Additionally, WAN accelerator 1032, a SFS gateway, and/or a SFS server issues one or more segment operations to store new data segments and to update reference counts and other label metadata for all of the data segments referenced by the new file's data layout. By using WAN accelerator 1030 to partition data, the processing workload of the SFS gateways or SFS server in a data deduplicating storage system is substantially reduced.
[0076] Similarly, if a client is directly connected with local area network 1012, rather than connecting through LAN 165, an embodiment of a SFS gateway or SFS server redirects all incoming data from the local client to a local WAN accelerator, such as WAN accelerator 1032, for partitioning into data segments and for determining the data layout.
[0077] Further embodiments can be envisioned to one of ordinary skill in the art. In other embodiments, combinations or sub-combinations of the above disclosed invention can be advantageously made. The block diagrams of the architecture and flow charts are grouped for ease of understanding. However it should be understood that combinations of blocks, additions of new blocks, re-arrangement of blocks, and the like are contemplated in alternative embodiments of the present invention.
[0078] The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.

Claims

WHAT IS CLAIMED IS:
1. A method of storing data in a data storage system, the method comprising: receiving a file including file metadata and file data in a first file data format to be stored in the data storage system; transforming the file data into transformed file data and a data transformation layout, wherein the data transformation layout specifies an arrangement of the transformed file data that replicates the file data in the first file data format; storing the file metadata in a first data storage in the first file data format; storing the data transformation layout in the first data storage in the first file data format; and storing at least a portion of the transformed file data in a second data storage.
2. The method of claim 1, wherein the first data storage includes a file system adapted to store file metadata and file data in the file data format.
3. The method of claim 2, wherein storing the data transformation layout comprises storing the data transformation layout in a file data stream.
4. The method of claim 3, wherein the file data stream is associated with a main data stream of a file.
5. The method of claim 3, wherein the file data stream is associated with an alternate data stream of a file.
6. The method of claim 1, wherein the second data storage is adapted to store the transformed file data.
7. The method of claim 1 , wherein the data transformation layout includes at least one data segment label based on at least one hash of at least a portion of the file data.
8. A method of accessing data from a data storage system, the method comprising: receiving a storage command; determining if the storage command is associated with a metadata request; in response to the determination that the storage command is associated with the metadata request, retrieving file system metadata included in a file system; determining if the storage command is associated with a file data access; in response to the determination that the storage command is associated with the file data access, retrieving a data transformation layout from the file system; and retrieving transformed file data referenced by the data transformation layout from a second data storage.
9. The method of claim 8, comprising: arranging the transformed file data according to the data transformation layout to replicate file data associated with the file system.
10. The method of claim 8, wherein the file system metadata includes a path in the file system.
11. The method of claim 8, wherein the file system metadata includes an attribute of a file included the file system.
12. The method of claim 8, wherein the storage command is associated with a file included in the file system.
13. The method of claim 12, wherein the data transformation layout is retrieved from an additional data stream associated with the file.
14. The method of claim 12, wherein the data transformation layout is retrieved from the file.
15. A computer-readable storage medium including instructions adapted to direct a computer to perform an operation, the operation comprising: receiving a file including file metadata and file data in a first file data format to be stored in the data storage system; transforming the file data into transformed file data and a data transformation layout, wherein the data transformation layout specifies an arrangement of the transformed file data that replicates the file data in the first file data format; storing the file metadata in a first data storage in the first file data format; storing the data transformation layout in the first data storage in the first file data format; and storing at least a portion of the transformed file data in a second data storage.
16. The computer-readable storage medium of claim 15, wherein the first data storage includes a file system adapted to store file metadata and file data in the file data format.
17. The computer-readable storage medium of claim 16, wherein storing the data transformation layout comprises storing the data transformation layout in a file data stream.
18. The computer-readable storage medium of claim 15, wherein the second data storage is adapted to store the transformed file data.
19. The computer-readable storage medium of claim 15, wherein the data transformation layout includes at least one data segment label based on at least one hash of at least a portion of the file data.
20. A computer-readable storage medium including instructions adapted to direct a computer to perform an operation, the operation comprising: receiving a storage command; determining if the storage command is associated with a metadata request; in response to the determination that the storage command is associated with the metadata request, retrieving file system metadata included in a file system; determining if the storage command is associated with a file data access; in response to the determination that the storage command is associated with the file data access, retrieving a data transformation layout from the file system; and retrieving transformed file data referenced by the data transformation layout from a second data storage.
21. The computer-readable storage medium of claim 20, comprising: arranging the transformed file data according to the data transformation layout to replicate file data associated with the file system.
22. The computer-readable storage medium of claim 20, wherein the file system metadata includes a path in the file system.
23. The computer-readable storage medium of claim 20, wherein the storage command is associated with a file included in the file system.
24. The computer-readable storage medium of claim 23, wherein the data transformation layout is retrieved from an additional data stream associated with the file.
25. The computer-readable storage medium of claim 23, wherein the data transformation layout is retrieved from the file.
PCT/US2009/057772 2008-09-22 2009-09-22 Storage system for data virtualization and deduplication WO2010033961A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/235,548 US20100082700A1 (en) 2008-09-22 2008-09-22 Storage system for data virtualization and deduplication
US12/235,548 2008-09-22

Publications (1)

Publication Number Publication Date
WO2010033961A1 true WO2010033961A1 (en) 2010-03-25

Family

ID=42039915

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2009/057772 WO2010033961A1 (en) 2008-09-22 2009-09-22 Storage system for data virtualization and deduplication

Country Status (2)

Country Link
US (2) US20100082700A1 (en)
WO (1) WO2010033961A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2513341A (en) * 2013-04-23 2014-10-29 Ibm Method and system for data de-duplication
RU2581551C2 (en) * 2010-06-18 2016-04-20 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Method for optimisation of data storage and transmission
GB2542619A (en) * 2015-09-28 2017-03-29 Fujitsu Ltd A similarity module, a local computer, a server of a data hosting service and associated methods
US9910857B2 (en) 2013-04-28 2018-03-06 International Business Machines Corporation Data management
US10467197B2 (en) 2013-04-22 2019-11-05 Bacula Systems Sa Creating a universally deduplicatable archive volume

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009032776A2 (en) 2007-08-28 2009-03-12 Commvault Systems, Inc. Power management of data processing resources, such as power adaptive management of data storage operations
US8782266B2 (en) * 2008-12-24 2014-07-15 David A. Daniel Auto-detection and selection of an optimal storage virtualization protocol
US9483486B1 (en) * 2008-12-30 2016-11-01 Veritas Technologies Llc Data encryption for a segment-based single instance file storage system
US9164700B2 (en) * 2009-03-05 2015-10-20 Sandisk Il Ltd System for optimizing the transfer of stored content in response to a triggering event
CN101853254B (en) * 2009-03-31 2013-08-14 国际商业机器公司 Method and device for mounting file or catalogue to local or remote host
ES2384844B1 (en) * 2009-05-26 2013-07-04 Young & Franklin, Inc ACTUATOR BASED DRIVING SYSTEM FOR SOLAR COLLECTOR.
US8635184B2 (en) * 2009-06-25 2014-01-21 Emc Corporation System and method for providing long-term storage for data
US20100333116A1 (en) 2009-06-30 2010-12-30 Anand Prahlad Cloud gateway system for managing data storage to cloud storage sites
US8762338B2 (en) 2009-10-07 2014-06-24 Symantec Corporation Analyzing backup objects maintained by a de-duplication storage system
US8694469B2 (en) * 2009-12-28 2014-04-08 Riverbed Technology, Inc. Cloud synthetic backups
US8370305B2 (en) * 2010-04-19 2013-02-05 Greenbytes, Inc., A Rhode Island Corporation Method of minimizing the amount of network bandwidth needed to copy data between data deduplication storage systems
US9678688B2 (en) 2010-07-16 2017-06-13 EMC IP Holding Company LLC System and method for data deduplication for disk storage subsystems
US10394757B2 (en) 2010-11-18 2019-08-27 Microsoft Technology Licensing, Llc Scalable chunk store for data deduplication
US8438139B2 (en) 2010-12-01 2013-05-07 International Business Machines Corporation Dynamic rewrite of files within deduplication system
US8959293B2 (en) 2010-12-14 2015-02-17 Microsoft Corporation Data deduplication in a virtualization environment
US8886901B1 (en) 2010-12-31 2014-11-11 Emc Corporation Policy based storage tiering
US9280550B1 (en) 2010-12-31 2016-03-08 Emc Corporation Efficient storage tiering
US9081511B2 (en) 2011-02-23 2015-07-14 International Business Machines Corporation Source-target relations mapping
US9058212B2 (en) * 2011-03-21 2015-06-16 Microsoft Technology Licensing, Llc Combining memory pages having identical content
US9317377B1 (en) * 2011-03-23 2016-04-19 Riverbed Technology, Inc. Single-ended deduplication using cloud storage protocol
US9307025B1 (en) * 2011-03-29 2016-04-05 Riverbed Technology, Inc. Optimized file creation in WAN-optimized storage
US9916258B2 (en) 2011-03-31 2018-03-13 EMC IP Holding Company LLC Resource efficient scale-out file systems
US9619474B2 (en) 2011-03-31 2017-04-11 EMC IP Holding Company LLC Time-based data partitioning
US8954399B1 (en) 2011-04-18 2015-02-10 American Megatrends, Inc. Data de-duplication for information storage systems
US8930653B1 (en) 2011-04-18 2015-01-06 American Megatrends, Inc. Data de-duplication for information storage systems
US8521705B2 (en) * 2011-07-11 2013-08-27 Dell Products L.P. Accelerated deduplication
US8660997B2 (en) 2011-08-24 2014-02-25 International Business Machines Corporation File system object-based deduplication
US8990171B2 (en) 2011-09-01 2015-03-24 Microsoft Corporation Optimization of a partially deduplicated file
US9396198B2 (en) * 2011-09-21 2016-07-19 Hitachi, Ltd. Computer system, file management method and metadata server
US9514154B2 (en) * 2011-10-27 2016-12-06 International Business Machines Corporation Virtual file system interface for communicating changes of metadata in a data storage system
JP5851047B2 (en) * 2011-12-08 2016-02-03 エンパイア テクノロジー ディベロップメント エルエルシー Storage discount to enable deduplication between users
US8839374B1 (en) * 2011-12-15 2014-09-16 Symantec Corporation Systems and methods for identifying security risks in downloads
US9824131B2 (en) 2012-03-15 2017-11-21 Hewlett Packard Enterprise Development Lp Regulating a replication operation
US9262496B2 (en) 2012-03-30 2016-02-16 Commvault Systems, Inc. Unified access to personal data
US8950009B2 (en) 2012-03-30 2015-02-03 Commvault Systems, Inc. Information management of data associated with multiple cloud services
US20140050407A1 (en) 2012-08-17 2014-02-20 International Business Machines Corporation Virtual Machine Image Access De-Duplication
US20140115260A1 (en) * 2012-10-18 2014-04-24 Oracle International Corporation System and method for prioritizing data in a cache
US10346259B2 (en) 2012-12-28 2019-07-09 Commvault Systems, Inc. Data recovery using a cloud-based remote data recovery center
US11100051B1 (en) * 2013-03-15 2021-08-24 Comcast Cable Communications, Llc Management of content
US9195673B2 (en) * 2013-03-15 2015-11-24 International Business Machines Corporation Scalable graph modeling of metadata for deduplicated storage systems
US10496490B2 (en) 2013-05-16 2019-12-03 Hewlett Packard Enterprise Development Lp Selecting a store for deduplicated data
EP2997497B1 (en) 2013-05-16 2021-10-27 Hewlett Packard Enterprise Development LP Selecting a store for deduplicated data
US9836474B2 (en) 2013-07-15 2017-12-05 International Business Machines Corporation Data structures for digests matching in a data deduplication system
US9594766B2 (en) 2013-07-15 2017-03-14 International Business Machines Corporation Reducing activation of similarity search in a data deduplication system
US10296598B2 (en) 2013-07-15 2019-05-21 International Business Machines Corporation Digest based data matching in similarity based deduplication
US10133502B2 (en) 2013-07-15 2018-11-20 International Business Machines Corporation Compatibility and inclusion of similarity element resolutions
US10229132B2 (en) 2013-07-15 2019-03-12 International Business Machines Corporation Optimizing digest based data matching in similarity based deduplication
US10789213B2 (en) 2013-07-15 2020-09-29 International Business Machines Corporation Calculation of digest segmentations for input data using similar data in a data deduplication system
US9244830B2 (en) 2013-07-15 2016-01-26 Globalfoundries Inc. Hierarchical content defined segmentation of data
US10339109B2 (en) 2013-07-15 2019-07-02 International Business Machines Corporation Optimizing hash table structure for digest matching in a data deduplication system
US9892127B2 (en) 2013-07-15 2018-02-13 International Business Machines Corporation Global digests caching in a data deduplication system
US9268786B2 (en) 2013-07-15 2016-02-23 International Business Machines Corporation Applying a minimum size bound on content defined segmentation of data
US9286314B2 (en) 2013-07-15 2016-03-15 International Business Machines Corporation Applying a maximum size bound on content defined segmentation of data
US10229131B2 (en) 2013-07-15 2019-03-12 International Business Machines Corporation Digest block segmentation based on reference segmentation in a data deduplication system
US10296597B2 (en) 2013-07-15 2019-05-21 International Business Machines Corporation Read ahead of digests in similarity based data deduplicaton
US9892048B2 (en) 2013-07-15 2018-02-13 International Business Machines Corporation Tuning global digests caching in a data deduplication system
US9922042B2 (en) 2013-07-15 2018-03-20 International Business Machines Corporation Producing alternative segmentations of data into blocks in a data deduplication system
US9891857B2 (en) 2013-07-15 2018-02-13 International Business Machines Corporation Utilizing global digests caching in similarity based data deduplication
US10073853B2 (en) 2013-07-17 2018-09-11 International Business Machines Corporation Adaptive similarity search resolution in a data deduplication system
CN105612512A (en) * 2013-07-18 2016-05-25 慧与发展有限责任合伙企业 Remote storage
US10061653B1 (en) * 2013-09-23 2018-08-28 EMC IP Holding Company LLC Method to expose files on top of a virtual volume
CN103617177A (en) * 2013-11-05 2014-03-05 浪潮(北京)电子信息产业有限公司 Stackable repeating data deletion file system
US9575680B1 (en) 2014-08-22 2017-02-21 Veritas Technologies Llc Deduplication rehydration
US10423495B1 (en) 2014-09-08 2019-09-24 Veritas Technologies Llc Deduplication grouping
US9747292B2 (en) * 2014-11-07 2017-08-29 International Business Machines Corporation Simplifying the check-in of checked-out files in an ECM system
US10284433B2 (en) 2015-06-25 2019-05-07 International Business Machines Corporation Data synchronization using redundancy detection
US9910906B2 (en) 2015-06-25 2018-03-06 International Business Machines Corporation Data synchronization using redundancy detection
US10762069B2 (en) * 2015-09-30 2020-09-01 Pure Storage, Inc. Mechanism for a system where data and metadata are located closely together
US9917896B2 (en) * 2015-11-27 2018-03-13 Netapp Inc. Synchronous replication for storage area network protocol storage
US10198190B2 (en) 2016-10-31 2019-02-05 International Business Machines Corporation Performance oriented data deduplication and duplication
US10552294B2 (en) 2017-03-31 2020-02-04 Commvault Systems, Inc. Management of internet of things devices
US11221939B2 (en) 2017-03-31 2022-01-11 Commvault Systems, Inc. Managing data from internet of things devices in a vehicle
US11294786B2 (en) 2017-03-31 2022-04-05 Commvault Systems, Inc. Management of internet of things devices
US10732852B1 (en) * 2017-10-19 2020-08-04 EMC IP Holding Company LLC Telemetry service
US10891198B2 (en) 2018-07-30 2021-01-12 Commvault Systems, Inc. Storing data to cloud libraries in cloud native formats
US11321002B2 (en) 2018-12-11 2022-05-03 Hewlett Packard Enterprise Development Lp Converting a virtual volume between volume types
US10768971B2 (en) 2019-01-30 2020-09-08 Commvault Systems, Inc. Cross-hypervisor live mount of backed up virtual machine data
US11366723B2 (en) 2019-04-30 2022-06-21 Commvault Systems, Inc. Data storage management system for holistic protection and migration of serverless applications across multi-cloud computing environments
US11461184B2 (en) 2019-06-17 2022-10-04 Commvault Systems, Inc. Data storage management system for protecting cloud-based data including on-demand protection, recovery, and migration of databases-as-a-service and/or serverless database management systems
US11561866B2 (en) 2019-07-10 2023-01-24 Commvault Systems, Inc. Preparing containerized applications for backup using a backup services container and a backup services container-orchestration pod
US20210149918A1 (en) * 2019-11-15 2021-05-20 International Business Machines Corporation Intelligent data pool
US11467753B2 (en) 2020-02-14 2022-10-11 Commvault Systems, Inc. On-demand restore of virtual machine data
US11321188B2 (en) 2020-03-02 2022-05-03 Commvault Systems, Inc. Platform-agnostic containerized application data protection
US11422900B2 (en) 2020-03-02 2022-08-23 Commvault Systems, Inc. Platform-agnostic containerized application data protection
US11442768B2 (en) 2020-03-12 2022-09-13 Commvault Systems, Inc. Cross-hypervisor live recovery of virtual machines
US11748143B2 (en) 2020-05-15 2023-09-05 Commvault Systems, Inc. Live mount of virtual machines in a public cloud computing environment
US11314687B2 (en) 2020-09-24 2022-04-26 Commvault Systems, Inc. Container data mover for migrating data between distributed data storage systems integrated with application orchestrators
US11604706B2 (en) 2021-02-02 2023-03-14 Commvault Systems, Inc. Back up and restore related data on different cloud storage tiers

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6374266B1 (en) * 1998-07-28 2002-04-16 Ralph Shnelvar Method and apparatus for storing information in a data processing system
US20080005141A1 (en) * 2006-06-29 2008-01-03 Ling Zheng System and method for retrieving and using block fingerprints for data deduplication
US20080005201A1 (en) * 2006-06-29 2008-01-03 Daniel Ting System and method for managing data deduplication of storage systems utilizing persistent consistency point images

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7386532B2 (en) * 2002-12-19 2008-06-10 Mathon Systems, Inc. System and method for managing versions
US20050216472A1 (en) * 2004-03-29 2005-09-29 David Leon Efficient multicast/broadcast distribution of formatted data
WO2007062254A2 (en) * 2005-11-28 2007-05-31 Commvault Systems, Inc. Systems and methods for data management
US7987160B2 (en) * 2006-01-30 2011-07-26 Microsoft Corporation Status tool to expose metadata read and write queues
US8352540B2 (en) * 2008-03-06 2013-01-08 International Business Machines Corporation Distinguishing data streams to enhance data storage efficiency
US8086651B2 (en) * 2008-05-12 2011-12-27 Research In Motion Limited Managing media files using metadata injection

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6374266B1 (en) * 1998-07-28 2002-04-16 Ralph Shnelvar Method and apparatus for storing information in a data processing system
US20080005141A1 (en) * 2006-06-29 2008-01-03 Ling Zheng System and method for retrieving and using block fingerprints for data deduplication
US20080005201A1 (en) * 2006-06-29 2008-01-03 Daniel Ting System and method for managing data deduplication of storage systems utilizing persistent consistency point images

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AGGARWAL, G.: "Metadata services for the Parallax storage system", THESIS, THE UNIVERSITY OF BRITISH COLUMBIA, July 2008 (2008-07-01), Retrieved from the Internet <URL:https://circle.ubc.ca/bitstream/2429/5586/1/ubc_2008_fall_aggarwal_gitika.pdf> [retrieved on 20091026] *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2581551C2 (en) * 2010-06-18 2016-04-20 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Method for optimisation of data storage and transmission
US10467197B2 (en) 2013-04-22 2019-11-05 Bacula Systems Sa Creating a universally deduplicatable archive volume
GB2513341A (en) * 2013-04-23 2014-10-29 Ibm Method and system for data de-duplication
US9547663B2 (en) 2013-04-23 2017-01-17 International Business Machines Corporation Data de-duplication
US9910857B2 (en) 2013-04-28 2018-03-06 International Business Machines Corporation Data management
GB2542619A (en) * 2015-09-28 2017-03-29 Fujitsu Ltd A similarity module, a local computer, a server of a data hosting service and associated methods

Also Published As

Publication number Publication date
US20100088349A1 (en) 2010-04-08
US20100082700A1 (en) 2010-04-01

Similar Documents

Publication Publication Date Title
US20100082700A1 (en) Storage system for data virtualization and deduplication
US9208031B2 (en) Log structured content addressable deduplicating storage
EP1875384B1 (en) System and method for multi-tiered meta-data caching and distribution in a clustered computer environment
EP1875385B1 (en) Storage system architecture for striping data container content across volumes of a cluster
US7457982B2 (en) Writable virtual disk of read-only snapshot file objects
US7809693B2 (en) System and method for restoring data on demand for instant volume restoration
US7165096B2 (en) Storage area network file system
EP1877903B1 (en) System and method for generating consistent images of a set of data objects
US8578090B1 (en) System and method for restriping data across a plurality of volumes
EP1543424B1 (en) Storage virtualization by layering virtual disk objects on a file system
EP1880271B1 (en) Data placement technique for striping data containers across volumes of a storage system cluster
US7917539B1 (en) Zero copy write datapath
US8041888B2 (en) System and method for LUN cloning
US20070288693A1 (en) System and Method for Supporting File and Block Access to Storage Object On A Storage Appliance
US7243207B1 (en) Technique for translating a pure virtual file system data stream into a hybrid virtual volume
US7962689B1 (en) System and method for performing transactional processing in a striped volume set
US11625306B2 (en) Data connector component for implementing data requests
WO2011082123A1 (en) Wan-optimized local and cloud spanning deduplicated storage system
EP1882223B1 (en) System and method for restoring data on demand for instant volume restoration
US7730277B1 (en) System and method for using pvbn placeholders in a flexible volume of a storage system
US9727588B1 (en) Applying XAM processes
US7783611B1 (en) System and method for managing file metadata during consistency points
US7506111B1 (en) System and method for determining a number of overwitten blocks between data containers
US10521159B2 (en) Non-disruptive automatic application regrouping
CN117076413B (en) Object multi-version storage system supporting multi-protocol intercommunication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09815361

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09815361

Country of ref document: EP

Kind code of ref document: A1