Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050021565 A1
Publication typeApplication
Application numberUS 10/616,128
Publication dateJan 27, 2005
Filing dateJul 8, 2003
Priority dateJul 8, 2003
Also published asEP1642216A2, EP1642216A4, EP1642216B1, US6959313, US7257606, US7653669, US20050240635, US20070266066, WO2005008377A2, WO2005008377A3
Publication number10616128, 616128, US 2005/0021565 A1, US 2005/021565 A1, US 20050021565 A1, US 20050021565A1, US 2005021565 A1, US 2005021565A1, US-A1-20050021565, US-A1-2005021565, US2005/0021565A1, US2005/021565A1, US20050021565 A1, US20050021565A1, US2005021565 A1, US2005021565A1
InventorsVikram Kapoor, Kurt Shoens, Mark Schultz, Rex Hamilton
Original AssigneeVikram Kapoor, Shoens Kurt Alan, Schultz Mark Steven, Hamilton Rex Rilen
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Snapshots of file systems in data storage systems
US 20050021565 A1
Abstract
The present invention relates to methods and systems of snapshot management of a file system in a data storage system. To represent the snapshots, the invention maintains pointers to the root block pointer of each snapshot. When the active file system is modified, this invention avoids overwriting any blocks used by previous snapshots by allocating new blocks for the modified blocks. When the invention needs to put an established block in a new location, it must update a parent block to point to the new location. The update to the parent block may then require allocating a new block for the new parent block and so forth. Parts of the file system not modified since a snapshot remain in place. The amount of space required to represent snapshots scales with the fraction of the file system that users modify. To maintain snapshot integrity, this invention keeps track of the first and last snapshots that use each block in space map blocks spread throughout the file system data space. When users delete snapshots, this invention may use a background process to find blocks no longer used by any snapshot and makes them available for future use.
Images(17)
Previous page
Next page
Claims(52)
1. A method of snapshot management in a data storage system that maintains multiple snapshot versions and an active file system, comprising:
(a) maintaining an index table that contains an entry for each snapshot and the active file system; and
(b) maintaining a space map block entry (b, e), wherein b and e represent index table entries, b indicates a first snapshot that uses the first block, and e indicates a last snapshot that uses the first block.
2. The method of claim 1, further comprising:
(c) allocating a second block;
(d) writing the data in the second block;
(e) updating any other blocks that pointed to the first block to point to the second block; and
(f) repeating the steps (c) through (e) for updating other blocks.
3. The method of claim 1, wherein the index table entry includes one or more attributes selected from a group of attributes comprising a version number, an image state, a time stamp, a root block pointer, and an image name.
4. The method of claim 2, further comprising (g) reading the associated space map block to determine if the first block is only used for the active file system and if so, updating the first block.
5. The method of claim 1, wherein the space map block entry (b, e) are indexes into the index table.
6. The method of claim 1, wherein the space map block entry (b, e) are version numbers in the index table.
7. The method of claim 4, wherein the space map block entry (a, 0) indicates the first block is only used by the active file system, wherein “a” represents the active file system.
8. The method of claim 1, further comprising:
(c) reading a first index table entry associated with the active file system;
(d) locating a second index table entry that is free-to-use;
(e) assigning a version number to the second index table entry that is larger than that of the first index table entry;
(f) copying the root block pointer from the first index table to the second index table entry;
(g) setting the image state of the first index table entry to an in-use snapshot; and
(h) setting the image state of the second index table entry to the active file system to create a snapshot.
9. The method of claim 1, further comprising:
(c) maintaining in the index table an image state that indicates if an entry is deleted or not; and
(d) marking the image state as deleted to delete a snapshot.
10. A method of claim 1, further comprising:
(c) ordering the index table by time of snapshot creation;
(d) reading each space map block entry to determine if the first snapshot was deleted and if so, replacing the index b with the earliest index of a later undeleted snapshot or the active file system, determining if the last snapshot was deleted and if so, replacing the index e with the latest index of an earlier undeleted snapshot to clean deleted snapshots.
11. The method of claim 10, further comprising (e) resetting the image state to free for all index table entries of deleted snapshots when all space map block entries have been processed.
12. The method of claim 10, further comprising (e) setting the space map block entry to indicate that the associated block is free if no undeleted snapshot exists between index b and index e.
13. The method of claim 12, further comprising (f) resetting the image state to free for all index table entries of deleted snapshots when all space map block entries have been processed.
14. The method of claim 1, further comprising:
(c) maintaining in the index table an image state that indicates if an entry is obsolete or not;
(d) creating a new snapshot c;
(e) creating an active file system a; and
(f) setting the image state of all in-use snapshots before snapshot c and after snapshot p to obsolete to revert to a previous snapshot p.
15. The method of claim 1, further comprising:
(c) maintaining in the index table an image state that indicates if an entry is obsolete or not;
(d) reading a snapshot c;
(e) reading a snapshot p;
(f) reading each space map block entry to determine:
(i) if the first snapshot is snapshot p or earlier than snapshot p and the last snapshot is earlier than snapshot c, replacing the index e with a value indicating that the block is still in use by the active file system,
(ii) if the first snapshot is later than snapshot p and earlier than snapshot c, setting the space map block entry to indicate that the associated block is free;
(g) marking the image state of snapshot c as deleted; and
(h) resetting the image state of all obsolete index table entries to free to clean obsolete snapshots after a revert operation to snapshot p.
16. The method of claim 15, further comprising repeating steps (f) and (g) over a list of snapshots p and of snapshots c
17. The method of claim 16, wherein the pending list includes the reverted snapshots p and the created snapshots c.
18. A snapshot management system including a processor for maintaining multiple snapshot versions and an active file system, comprising:
an index table that contains an entry for each snapshot and the active file system;
a space map block entry (b, e), wherein b and e represent index table entries, b indicates a first snapshot that uses the first block, and e indicates a last snapshot that uses the first block; and
a usable space for storing the snapshot versions and the active file system.
19. The system of claim 18, wherein the processor is programmed to execute steps of:
allocating a second block;
writing the data in the second block;
updating any other blocks that pointed to the first block to point to the second block; and
repeating the above steps for updating other blocks.
20. The system of claim 18, wherein the index table entry includes one or more attributes selected from a group of attributes comprising a version number, an image state, a time stamp, a root block pointer, and an image name.
21. The system of claim 19, wherein the processor reads the associated space map block to determine if the first block is only used for the active file system and if so, updates the first block.
22. The system of claim 18, wherein the space map block entry (b, e) are indexes into the index table.
23. The system of claim 18, wherein the space map block entry (b, e) are version numbers in the index table.
24. The system of claim 18, wherein the space map block entry (a, 0) indicates the first block is only used by the active file system, wherein “a” represents the active file system.
25. The system of claim 18, wherein the processor is programmed to execute steps of:
reading a first index table entry associated with the active file system;
locating a second index table entry that is free-to-use;
assigning a version number to the second index table entry that is larger than that of the first index table entry;
copying the root block pointer from the first index table to the second index table entry;
setting the image state of the first index table entry to an in-use snapshot; and
setting the image state of the second index table entry to the active file system to create a snapshot.
26. The system of claim 18, wherein the processor is programmed to execute steps:
maintaining in the index table an image state that indicates if an entry is deleted or not; and
marking the image state as deleted to delete a snapshot.
27. The system of claim 18, wherein the processor is programmed to execute steps:
ordering the index table by time of snapshot creation;
reading each space map block entry to determine if the first snapshot was deleted and if so, replacing the index b with the earliest index of a later undeleted snapshot or the active file system, determining if the last snapshot was deleted and if so, replacing the index e with the latest index of an earlier undeleted snapshot to clean deleted snapshots.
28. The system of claim 27, wherein the processor is programmed to reset the image state to free for all index table entries of deleted snapshots when all space map block entries have been processed.
29. The system of claim 27, wherein the processor is programmed to set the space map block entry to indicate the associated block is free if no undeleted snapshot exists earlier than index e or if index b is later than index e.
30. The system of claim 29, wherein the processor is programmed to reset the image state to free for all index table entries of deleted snapshots when all space map block entries have been processed.
31. The system of claim 18, wherein the processor is programmed to execute:
maintaining in the index table an image state that indicates if an entry is obsolete or not;
creating a new snapshot c;
creating an active file system a; and
setting the image state of all in-use snapshots before snapshot c and after snapshot p to obsolete to revert to a previous snapshot p.
32. The system of claim 27, wherein the processor is programmed to set the space map block entry to indicate that the associated block is free if no undeleted snapshot exists earlier than index e or if index b is later than index e.
33. The system of claim 18, wherein the processor is programmed to execute:
maintaining in the index table an image state that indicates if an entry is obsolete or not;
reading a snapshot c;
reading a snapshot p;
reading each space map block entry to determine:
(i) if the first snapshot is snapshot p or earlier than snapshot p and the last snapshot is earlier than snapshot c, replacing the index e with a value indicates that the block is still in use by the active file system,
(ii) if the first snapshot is later than snapshot p and earlier than snapshot c, setting the space map block entry to indicate that the associated block is free;
marking the image state of snapshot c as deleted; and
resetting the image state of all obsolete index table entries to free to clean obsolete snapshots after a revert operation to snapshot p.
34. The system of claim 33, wherein the processor is programmed to repeat the reading and marking over a list of snapshots p and of snapshots c
35. The system of claim 34, wherein the pending list includes the reverted snapshots p and the created snapshots c.
36. A snapshot management system that maintains multiple snapshot versions and an active file system, comprising:
means for maintaining an index table that contains an entry for each snapshot and the active file system; and
means for maintaining space map block entry (b, e), wherein b and e represent index table entries, b indicates a first snapshot that uses the first block, and e indicates a last snapshot that uses the first block.
37. The system of claim 36, further comprising:
means for allocating a second block;
means for writing the data in the second block;
means for updating any other blocks that pointed to the first block to point to the second block; and
means for repeating the above steps for updating other blocks.
38. The system of claim 36, wherein the index table entry includes one or more attributes selected from a group of attributes comprising a version number, an image state, a time stamp, a root block pointer, and an image name.
39. The system of claim 37, further comprising means for reading the associated space map block to determine if the first block is only used for the active file system and if so, updating the first block.
40. The system of claim 36, wherein the space map block entry (b, e) are indexes into the index table.
41. The system of claim 36, wherein the space map block entry (b, e) are version numbers in the index table.
42. The system of claim 39, wherein the space map block entry (a, 0) indicates the first block is only used by the active file system, wherein “a” represents the active file system.
43. The system of claim 36, further comprising:
means for reading a first index table entry associated with the active file system;
means for locating a second index table entry that is free-to-use;
means for assigning a version number to the second index table entry that is larger than that of the first index table entry;
means for copying the root block pointer from the first index table to the second index table entry;
means for setting the image state of the first index table entry to an in-use snapshot; and
means for setting the image state of the second index table entry to the active file system to create a snapshot.
44. The system of claim 36, further comprising:
means for maintaining in the index table an image state that indicates if an entry is deleted or not; and
means for marking the image state as deleted to delete a snapshot.
45. The system of claim 36, further comprising:
means for ordering the index table by time of snapshot creation; and
means for reading each space map block entry to determine if the first snapshot was deleted and if so, replacing the index b with the earliest index of a later undeleted snapshot or the active file system, determining if the last snapshot was deleted and if so, replacing the index e with the latest index of an earlier undeleted snapshot to clean deleted snapshots.
46. The system of claim 45, further comprising means for resetting the image state to free of all index table entries of deleted snapshots when all space map block entries have been processed.
47. The system of claim 45, further comprising means for setting the space map block entry to indicate that the associated block is free if no undeleted snapshot exists earlier than index e or if index b is later than index e.
48. The system of claim 47, further comprising means for resetting the image state to free of all index table entries of deleted snapshots when all space map block entries have been processed.
49. The system of claim 36, further comprising:
means for maintaining in the index table an image state that indicates if an entry is obsolete or not;
means for creating a new snapshot c;
means for creating an active file system a; and
means for setting the image state of all in-use snapshots before snapshot c and after snapshot p to obsolete to revert to a previous snapshot p.
50. The system of claim 36, further comprising:
means for maintaining in the index table an image state that indicates if an entry is obsolete or not;
means for reading a snapshot c;
means for reading a snapshot p;
means for reading each space map block entry to determine:
(i) if the first snapshot is snapshot p or earlier than snapshot p and the last snapshot is earlier than snapshot c, replacing the index e with a value indicating that the block is still in use by the active file system,
(ii) if the first snapshot is later than snapshot p and earlier than snapshot c, setting the space map block entry to indicate that the associated block is free;
means for marking the image state of snapshot c as deleted; and
means for resetting the image state of all obsolete index table entries to free to clean obsolete snapshots after a revert operation to snapshot p.
51. The system of claim 50, further comprising means for repeating the reading and marking functions over a list of snapshots p and of snapshots c
52. The system of claim 51, wherein the list includes the unclean reverted snapshots p and the created snapshots c.
Description
    BACKGROUND
  • [0001]
    The present invention relates to snapshots of file systems in data storage systems.
  • [0002]
    This application incorporates herein by reference as follows:
      • U.S. application Ser. No. 10/354,797, Methods and Systems of Host Caching, filed on Jan. 29, 2003 (Attorney Docket No. Pillar 709);
      • U.S. application Ser. No. 10/440,347, Methods and Systems of Cache Memory Management and Snapshot Operations, filed on May 16, 2003 (Attorney Docket No. Pillar 713); and
      • U.S. Application No. Unknown, Systems and Methods of Data Migration in Snapshot Operations, filed on Jun. 19, 2003 (Attorney Docket No. Pillar 711), Express Mail Label No. EJ039579912US.
  • [0006]
    Files exist to store information on storage devices (e.g., magnetic disks) and allow the information to be retrieved later. A file system is a collection of files and directories plus operations on them. To keep track of files, file systems have directories. A directory entry provides the information needed to find the blocks associated with a given file. Many file systems today are organized in a general hierarchy (i.e., a tree of directories) because it gives users the ability to organize their files by creating subdirectories. Each file may be specified by giving the absolute path name from the root directory to the file. Every file system contains file attributes such as each file owner and creation time and must be stored somewhere such as in a directory entry.
  • [0007]
    A snapshot of a file system will capture the content (i.e., files and directories) at an instant in time. A snapshot results in two data images: (1) the active data that an application can be read and write as soon as the snapshot is created and (2) the snapshot data. Snapshots can be taken periodically, hourly, daily, or weekly or on user demand. They are useful for a variety of applications including recovery of earlier versions of a file following an unintended deletion or modification, backup, data mining, or testing of software.
  • [0008]
    The need for high data availability often requires frequent snapshots that consume resources such as memory, internal memory bandwidth, storage device capacity and the storage device bandwidth. Some important issues for snapshots of file systems is how to manage the allocation of space in the storage devices, how to keep track of the blocks of a given file, and how to make snapshots of file systems work efficiently and reliably.
  • SUMMARY OF THE INVENTION
  • [0009]
    The invention provides methods and systems for management of snapshots of a file system.
  • [0010]
    In a first aspect of the invention, a snapshot management system performs a method for managing multiple snapshots and an active file system by (a) maintaining an index table that contains an entry for each snapshot and the active file system; and (b) maintaining space map block entry (b, e) where b and e represent index table entries, b indicates a first snapshot that uses the first block and e indicates a last snapshot that uses the first block.
  • [0011]
    In a second aspect of the invention, a snapshot management system includes a processor for maintaining multiple snapshot versions and an active file system, comprising: (a) an index table that contains an entry for each snapshot and the active file system; (b) a space map block including space map block entry (b, e), wherein b and e represent index table entries, b indicates a first snapshot that uses the first block, and e indicates a last snapshot that uses the first block; and (c) a usable space for storing the snapshot versions and the active file system.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0012]
    FIG. 1 illustrates an embodiment of a data storage system.
  • [0013]
    FIG. 2 illustrates the data storage as a virtualized storage subsystem.
  • [0014]
    FIG. 3 illustrates details of the virtualized data storage subsystem organized into file system blocks including, snapshot tables, space map blocks, and usable file system data space.
  • [0015]
    FIG. 4 illustrates details of the space map blocks and a block tracking and index system.
  • [0016]
    FIG. 5 illustrates examples of a snapshot tracking status in the space map blocks.
  • [0017]
    FIG. 6 illustrates details and examples of the snapshot table and snapshot table elements.
  • [0018]
    FIG. 7 illustrates a flow diagram for the creation of a file system.
  • [0019]
    FIG. 8 illustrates a flow diagram for file system block management.
  • [0020]
    FIG. 9 illustrates a flow diagram for the creation of a file system snapshot.
  • [0021]
    FIG. 10 illustrates a flow diagram of a method to obsolete a file system snapshot.
  • [0022]
    FIG. 11 illustrates a flow diagram of a method to delete a snapshot and for a method to clean unneeded snapshots from space map blocks.
  • [0023]
    FIG. 12 illustrates a flow diagram of a method to remove obsolete snapshots from the index table and for a method to remove deleted snapshots from the index table.
  • [0024]
    FIG. 13 illustrates a flow diagram of a method to clean obsolete snapshot indexes from space map block entries.
  • [0025]
    FIG. 14 illustrates a flow diagram of a method to clean deleted snapshot indexes from space map block entries.
  • [0026]
    FIG. 15 a illustrates a diagram of an active file system with a request to revert to an earlier snapshot.
  • [0027]
    FIG. 15 b illustrates a diagram of an active file system on hold to obsolete snapshots after the earlier snapshot.
  • [0028]
    FIG. 15 c illustrates a diagram of the cleaning of the obsolete snapshots.
  • [0029]
    FIG. 15 d illustrates a diagram of the file system after reversion to the earlier snapshot.
  • [0030]
    FIG. 16 illustrates a diagram of multiple reversions to earlier snapshots.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • [0031]
    The following description includes the best mode of carrying out the invention. The detailed description is made for the purpose of illustrating the general principles of the invention and should not be taken in a limiting sense. The scope of the invention is determined by reference to the claims. Each part is assigned its own part number throughout the specification and drawings.
  • [0032]
    FIG. 1 illustrates a data storage system 10, including a plurality of hosts coupled to data storage subsystem(s). Each host is a computer that can connect to client(s), to data storage subsystem(s), and each other. Each host provides software/hardware interfaces such as network interface cards and software drivers to implement Ethernet, Fibre Channel, ATM, and SCSI, and InfiniBand. Hennessy and Patterson, Computer Architecture: A Quantitative Approach (2003), and Patterson and Hennessy, Computer organization and Design: The Hardware/Software Interface (1998) describe computer hardware and software, storage systems, caching, and networks and are incorporated by reference.
  • [0033]
    In an embodiment, the first host includes a motherboard with a CPU-memory bus 14 that communicates with dual processors 12 and 41. The processor used is not essential to the invention and could be any suitable processor such as the Intel Pentium 4 processor. A processor could be any suitable general purpose processor running software, an ASIC dedicated to perform the operations described herein or a field programmable gate array (FPGA). Also, one could implement the invention using a single processor in each host or more than two processors to meet more stringent performance requirements. The arrangement of the processors is not essential to the invention.
  • [0034]
    The first host cache memory 20 includes a cache manager 13, a cache directory 15, and cache lines 16. The cache memory 20 is nonvolatile memory or volatile memory or a combination of both. Nonvolatile memory protects data in the event of a power interruption or a host failure. Data is defined as including user data, instructions, and metadata. Nonvolatile memory may be implemented with a battery that supplies power to the DRAM to make it nonvolatile memory when a conventional external power interrupt circuit detects a power interruption or with inherently nonvolatile semiconductor memory.
  • [0035]
    Each host includes a bus adapter 22 between the CPU-memory bus 14 and an interface bus 24. Each host runs an operating system such as Linux, UNIX, a Windows OS, or another suitable operating system. Tanenbaum, Modern Operating Systems (2001) describes operating systems in detail and is hereby incorporated by reference. The first host is representative of the other hosts, but this feature is not essential to the invention.
  • [0036]
    The first host can communicate with the second host through an interconnect 40, shown as connected to an adapter 25 to the interface bus 24. The PCI bus is one suitable interface bus and the interconnect 40 may be any suitable known bus, SAN, LAN, or WAN technology. In an embodiment, the interconnect 40 is a dedicated Fibre Channel (FC) point-to-point link that connects to FC-PCI bus adapter 25 to provide fast point-to-point communication between the hosts.
  • [0037]
    In an alternative embodiment, the interconnect network 30 such as a FC fabric provides extra bandwidth for host-to-host communications. In this embodiment, links 28, 38 connect to the interconnect network 30 and the hosts use link 28 and link 38 when available. FC standard software can set priority levels to ensure high priority peer-to-peer requests, but there will still be some arbitration overhead and latency in claiming ownership of the links. For example, if links 28 and 38 are busy transferring data when a write request arrives, that operation must complete before either link is free for arbitration.
  • [0038]
    If the interconnect 40 ever fails, communication between hosts can be handled using the interconnect network 30. The interconnect network 30 can be implemented by interconnects used in data storage systems such as Fibre Channel, SCSI, InfiniBand, or Ethernet, and the type of interconnect is not essential to the invention. In either embodiment, redundant communication between hosts ensures the data storage system has high availability. See Clark, IP SANs: A Guide to iSCSI, IFCP, and FCIP Protocols for Storage Area Networks (2002) and Clark, Designing Storage Area Networks (1999) are incorporated herein by reference.
  • [0039]
    In an embodiment, the data storage subsystems shown in FIG. 1 can be those described in the co-pending U.S. patent application Ser. No. 10/264,603, entitled, Systems and Methods of Multiple Access Paths to Single Ported Storage Devices, filed on Oct. 3, 2002, and incorporated herein by reference. It is understood, however, that other storage device(s) or data storage subsystems could be used instead of the data storage subsystem described in that U.S. patent application.
  • [0040]
    As shown in FIG. 1, the first host connects, or couples, to the first data storage subsystem through the bus adapter 22, the interface bus 24, the adapter 26, the link 28, the interconnection network 30, and the link 32. To connect to the second data storage subsystem, the first host uses the same I/O path except the data passes through link 34, while the second host uses the same type of I/O path plus link 32 to communicate with the first data storage subsystem, or link 34 to communicate with the second data storage subsystem, or link 36 to the data storage subsystem N.
  • [0041]
    FIG. 2 illustrates that each host of the data storage system can store and retrieve files from a data storage subsystem 35 using an interconnect 28, an interconnect 33, and an interconnect network 30. In an embodiment, each storage device in the data storage subsystem is assigned a logical unit number (LUN) that is an identifier for the storage device. A virtual logical unit number (VLUN) is as an abstraction of the storage device(s) or the virtualization of the data storage subsystems such as a linear array of blocks as it appears to the data storage system users. In various embodiments, the implementation of a VLUN may be striped (i.e., spread) over multiple RAID groups for added performance, spread over sections of a RAID group for flexibility, or copied on multiple RAID groups for reliability. As shown, the storage devices of the data storage subsystem are virtualized as a file system employing contiguous fixed sized blocks 0-n where the size of each block is some value preferably 1-KB to 64-KB.
  • [0042]
    FIG. 3 illustrates a data storage subsystem for maintaining (e.g., allocating, reading, writing, and deallocating) some blocks for index tables, some for space maps, and others for usable space for data storage. The block(s) allocated to an index table depends on the size of each block and the number of concurrent snapshots supported. For example, three 8-KB blocks may be sufficient space to support an index table of 254 snapshots. As shown, the file system has a pair of index tables 195 and 196 and thus uses six 8-KB blocks so the host can alternate writes to the index tables to ensure recovery in case of a data storage system failure. Thus, if the system fails during a write to one index table, the host can retrieve the unmodified copy of the other index table. While we describe this method of writing to alternate index table copies, other methods, such as write journaling, can be used to protect against system failure during index table writes. The remainder of the storage is allocated to space map blocks with usable space for data storage.
  • [0043]
    Each index table includes an index value of the active file system 17 permitting fast location of the active file system. The index table includes a known algorithm to verify the data integrity such as a checksum 18, a cyclic redundancy check, or a digital signature. The index table provides an index to the snapshots and the active file system. Each entry in the index table represents a snapshot or the active file system. As illustrated, the index range is 1-255, but this range is not essential to the invention. In various embodiments, each snapshot and the active file system has one or more associated attributes such as a version number, timestamp and/or image name to identify the snapshot or active file system, an image state, a root block pointer, and an image name as described below. When the data storage system takes a snapshot of the file system it assigns the snapshot a unique version number such as a 32-bit unsigned integer that increases monotonically for each subsequent snapshot. The version number is not reused even as snapshots are deleted or made obsolete to the file system.
  • [0044]
    The image state can be one of the following states:
      • Active—representing the active file system
      • In-use snapshot—representing a snapshot that users can access
      • Free—representing available for writing by a snapshot or active file system
      • Deleted snapshot—representing a user has deleted the associated snapshot but a cleaner process or thread has not yet removed the space map block entry for this snapshot
      • Obsolete snapshot—representing a user has reverted to an earlier snapshot and the cleaner process or thread has not yet removed the space map block entry for this snapshot
  • [0050]
    In an embodiment, when the data storage system takes a snapshot of the file system, the host provides a timestamp (e.g., time and date) when the snapshot or active data image was created. The root block pointer provides the address of the root block in the hierarchical structure of the snapshot and the image name is a character string used to easily identify the snapshot to users.
  • [0051]
    Referring to FIG. 4, the remainder of the data storage subsystem is allocated to space map blocks and usable space for data. Each space map block keeps track of the blocks in its usable space for data storage. For example, a space map block can keep track of 2,047 blocks of usable space. Each space map block entry contains a pair of indexes (“a space map block entry”), for example, 8-bits in length that represent any of 254 snapshots or the active file system. Each space map block entry is an index into the index table shown in FIG. 3. Each space map block entry has a beginning value b that indicates the first snapshot (i.e., snapshot b) and an ending value e that indicates the last snapshot (i.e., snapshot e) to use the associated block. Thus, each space map block entry (b, e) in the space map block is used to track the usage of an associated block in the usable space:
    Beginning Index, b Ending Index, e Meaning
    0 0 The block is free to use by a
    snapshot or the active file
    system
    8-bit Integer 0 The block is in use by one or
    more snapshots and has not been
    changed since the first snapshot
    was taken. The block is also in
    use by the active file system
    a 0 The block is in use by the active
    file system only and there are no
    snapshots associated with the
    block
    8-bit Integer Another 8-bit The block is in use by a
    Integer snapshot and is used by all
    subsequent snapshots through a
    last snapshot. The data has
    changed since the last snapshot
    was created and is, therefore, no
    longer in use by the active file
    system
  • [0052]
    In an alternative embodiment, each space map block entry contains a pair of version numbers (e.g., 32-bit) that represent snapshots or the active file system. Thus, each version pair (b, e) in the space map block would be used to track the usage of an associated block in the usable space.
  • [0053]
    FIG. 5 illustrates how a space map block entry is used to track a block in the usable space. In an earlier stage of operation, the space map may contain many entries with beginning and ending values equal to zero indicating that many blocks in the data storage subsystem are free-to-use for snapshots or the active file system. At the same time, other blocks will be in-use that is allocated to snapshots or the active file system. FIG. 5 shows one such block used by snapshots assigned version number 10344 through version number 10388 inclusive. The space map block entry (16, 13) indicates the snapshots that use this block. The host associates the space map block entry with the version number of the snapshot by reading the index table. The space map block also contains space map block entry (212, 0) to show that the active file system, for example, assigned version number 65993 is using an associated block.
  • [0054]
    FIG. 6 illustrates the relationship between the index table 200 and the snapshot attributes and the active file system attributes. The table below illustrates the group of attributes 203, 204, 205, 206, 207, and 208 that are shown in FIG. 6:
    Root
    Index Table Version Image block Image
    Entry Number State Timestamp Pointer Name
    Snapshot 1 10344 In-use 4 AM, May 8, 1002 Fred
    2003
    Snapshot 3 10388 In-use 10 AM, May 9, 1004 Smokey
    2003
    Active File 65993 Active 6 PM, May 14, 1006 Hilda
    System File 2003
    System
    Snapsxhot 5 12608 Deleted 2 PM, Apr. 2, 1008 Rufus
    2003
    Snapshot 55478 Obsolete 3 AM, May 9, 1010 Vern
    253 2003
    Snapshot 0 Free 0 0 0
    254
  • [0055]
    FIG. 7 illustrates a flow diagram of a method for creating a file system. This method can occur during the process of initialization. In an embodiment, the initialization process has proceeded to the point where the next steps relate specifically to file system creation. Although the method is described serially below, the steps can be performed in parallel, for example, asynchronously or in a pipelined manner. There is no requirement the method be performed in the order shown except where indicated. Further, the steps are implemented by computer such as one or more host(s) described earlier. For brevity, we describe the methods as executed by a host.
  • [0056]
    Referring to step 105 of FIG. 7, the host sets all of the space map block entries equal to (0, 0). This indicates that the blocks corresponding to the entries are free-to-use. At step 106, the host selects an 8-bit index “a” that represents the active file system. At step 108, the host assigns a starting version number to index a. At step 110, the host loads index “a” into the index of the active file system 201 in the directory 200 (FIG. 6). At step 112, the host selects the first available space map block and at step 114 loads the beginning index 8-bit index “a” and an 8-bit ending index 0 into the first entry in the selected space map block. At step 116, the host sets the starting version number in the associated attributes for the active file system in index table entry “a”. The host further sets the image state to active at step 118, the timestamp to the current date and time at step 120, and a starting root block pointer at step 122, calls an algorithm to verify the data integrity (e.g., checksum) of the snapshot attributes, and stores the results in index table entry “a” at step 124. At step 126, the host may write the index table to nonvolatile storage. In one embodiment, at step 128, the host continues with any other activities such as initialization. In another embodiment, the other activities can precede the creation of the file system.
  • [0057]
    FIG. 8 illustrates a flow diagram of a method of block management. At step 42, the host receives a request to update the file system data. At step 44, the host reads the space map block entry of the associated received data to determine if that block is used by the active file system only. If yes, as indicated by the space map block entry=(a, 0), the host determines at step 45 whether or not the data is a modification of existing data or an addition to existing data. If the received data is a modification of existing data, the host overwrites the block at step 46 and returns to normal operation at step 58. If the received data is an addition to the existing data, the host determines at step 48 if the space available in the current block is enough to hold all of the received data. If yes, the host adds the received data to the current block at step 50 and returns to normal operation at step 58. If not, the host allocates a free-to-use block at step 52 to hold the additional data and changes the associated space map block entry from (0, 0)-->(a, 0). At step 54, the host adds the received data to the newly allocated block. At step 56, the host updates the file system block pointers to point to the new data. At step 58, the block management routine returns to normal system operation.
  • [0058]
    At step 44, if the space map block entry of the block associated with the received data indicates an in-use snapshot uses the block, that is, the space map block entry (b, 0), the host allocates a free-to-use block for the received data at step 60. At step 62, the host adds the received data to the new allocated block. At step 63, the host changes the space map block entry of the new allocated block from (0, 0)-->(a, 0) indicating the new block is used by the active file system only. At step 64, the host updates the file system block pointers to point to the new data. At step 66, the host determines if there are other in-use snapshots pointing to the same old block. If the index b is associated with the latest snapshot version number, there is no other in-use snapshots pointing to the same old block. Therefore, at step 67, the host updates the old space map block entry from (b, 0)-->(b, b) indicating snapshot b is the only snapshot pointing to the associated old block and that the old data has been modified since snapshot b was created. If the index b is not associated with the latest snapshot version number, there is another in-use snapshot pointing to the same old block. Therefore, at step 68, the host updates the old space map block entry from (b, 0)-->(b, e) to indicate that snapshot b is the beginning snapshot and snapshot e is the ending snapshot (i.e., current in-use snapshot with the latest snapshot version number) pointing to the associated old block. In this case, there may be other snapshots with version numbers less than snapshot e and greater than snapshot b pointing to the same old block. In either case, the block management routine returns to normal system operation at step 58.
  • [0059]
    FIG. 9 illustrates a flow diagram of a method of creating a snapshot. After receiving a request for a new snapshot of the file system, the host holds off from updating the active file system at step 140. At step 142, the host searches through the index table for the first snapshot with an image state equal to free. At step 144, if the host searches the entire index table and does not find a free image state, the routine reports no free snapshots and the host resumes normal file system operation at step 164 and if appropriate, the operator can delete some snapshots. If, at step 144, a free image state is found, the host changes the active file system's image state to in-use at step 148. At step 150, the host enters a timestamp of the new in-use snapshot. When this snapshot is created, the version number and the root block pointer remain as they were when the block was allocated to the active file system. At step 151, the host assigns a user-friendly image name for the in-use snapshot. This completes creation of the new snapshot. Next, the host establishes an active file system for normal use. At step 152, the host changes snapshot attributes containing the image state free to the active file system. At step 154, the host assigns the next version number to the new active file system. At step 156, the host enters the current root block pointer (same as the new snapshot) in the attributes of the active file system. At step 158, the host saves a user-friendly image name of the active file system. The snapshot table is written to nonvolatile storage at step 162. The host returns to normal operation at step 164.
  • [0060]
    FIG. 10 illustrates a flow diagram for a method used to revert to an earlier version of a snapshot. FIGS. 15 a and 15 b illustrate diagrams of the method of reversion. At times it is desirable or necessary to revert to an earlier version of the file system. An earlier version of the file system is any previous snapshot of the active file system. Once a previous snapshot is selected, the host discards all versions of the file system after the chosen version, including the current active file system. After receiving a request to revert to the previous snapshot, for example, snapshot p shown in FIG. 15 a, the host will hold off updates to the current active file system at step 210. At step 212, the host changes the image state of all snapshots after snapshot p from in-use to obsolete and changes the image state of the active file system from active to obsolete (See FIG. 15 b). At step 214, the host makes a copy of snapshot p, for example, called snapshot c. Snapshot c is used to receive any updates to space map block entry (p, 0) that were held off during the process of reverting to the previous snapshot version. This permits snapshot p to be preserved in its present state after the system is brought back to an active image state, while at the same time, not losing the pending updates. At step 216, the host sets the image state of snapshot c to in-use. At step 218, the host assigns the next unused version to snapshot c. At step 220, the host sets the root block pointer of snapshot c to the same root block pointer of snapshot p. At step 222, the host creates another copy of snapshot p, for example, called copy a. The copy a will become the active file system of the desired image of snapshot p. At step 224, the host sets the image state of copy a to the active file system. At step 226, the host assigns the next version number to copy a. At step 228, the host sets the root block pointer of copy a to the same root block pointer of snapshot p. At step 230 the host records index a of the active file system into the index table 200 (FIG. 3). At step 232, the host writes the index table to nonvolatile storage. At step 234, the host returns to normal file system activity.
  • [0061]
    FIG. 11 a illustrates a flow chart for a method to delete a snapshot. At step 75, after receiving a request to delete a snapshot (see also FIG. 15 c) the host searches the index table for the requested snapshot. At step 76, the host sets the image state of the requested snapshot to deleted. At step 77, the host returns to normal file system operation.
  • [0062]
    FIG. 11 b illustrates a high level flow chart for cleaning deleted and obsolete snapshots from the space map blocks and index table of the file system. At step 79, the host determines if any obsolete snapshots exist. If yes, the host goes to reference A in FIG. 13 to clean obsolete snapshots from the space map blocks. If not, the host goes to step 81 and determines if any deleted snapshots exist. If not, then no work needs to be done and the method is complete. At step 81, if a deleted snapshot is found, the host goes to reference H in FIG. 14 to clean deleted snapshots from the space map blocks and index table of the file system.
  • [0063]
    FIG. 13 illustrates the detailed flow chart for cleaning obsolete snapshots from space map block entries after a reversion to snapshot p. Step 300 examines each space map block entry one by one in the file system. Step 310 tests whether the beginning index of the space map block entry either matches the snapshot p to which we reverted or precedes snapshot p while the ending index refers to an obsolete snapshot later than p and earlier than c, the snapshot copy created in step 220 on FIG. 10. If the space map block entry matches these conditions, step 312 changes the space map block entry to (b, 0) to indicate that the block is now in use by the active file system.
  • [0064]
    Step 314 tests if the beginning index of the space map block entry indicates a snapshot later than the reverted-to snapshot p and the ending index indicates an obsolete snapshot earlier than the copy snapshot c. If so, step 316 sets the space map block entry to (0, 0) to indicate that the entry is free-to-use since no snapshot any longer references it.
  • [0065]
    If neither of the conditions tested by steps 310 or 314 are true, then step 318 leaves the space map block entry unchanged.
  • [0066]
    After executing step 312, 316, or 318, step 306 tests if we have processed the last space map block entry in the file system. If we have processed the last entry, processing continues at Reference J on FIG. 12 a to remove the index table entry for all the obsolete snapshots. Otherwise, step 308 moves to the next space map block entry and processing continues at step 300.
  • [0067]
    After completing the processing of all obsolete snapshots in the space map blocks, processing continues at Reference J on FIG. 12 a to remove the index table entries corresponding to obsolete snapshots. Processing begins at the first index table entry in step 400. Step 410 tests if the index table entry is obsolete. If so, step 420 clears the index table entry by setting the image state to free-to-use, the timestamp to 0, the root block pointer to 0, and by clearing the name reference. Step 430 tests if we have processed the last index table entry. If this is not the last index table entry, step 440 moves to the next index table entry and processing continues at step 410. After all index table entries have been processed, all obsolete snapshots have been completely removed from the file system.
  • [0068]
    Returning to FIG. 11 b, if step 81 detects any deleted snapshots in the index table, processing continues at Reference H on FIG. 14. On FIG. 14, step 600 begins with the first space map block entry. Step 610 tests if the beginning index of the space map block entry references a deleted snapshot. If yes, then step 620 tests for any active file system or in-use snapshot with a version later than the beginning space map block entry index. If no snapshot or active file system is found later than the space map block entry beginning index, then step 680 sets the entry to (0, 0) to indicate the corresponding block is free to use. If a later snapshot or active file system is found, step 630 sets the beginning index of the space map block entry to the index of the found snapshot or active file system and continues processing at Reference G on the same sheet.
  • [0069]
    Step 640 similarly tests the ending index of the space map block entry to see if it references a deleted snapshot. If so, step 650 tests if there is a snapshot with version less than the current ending index and later than or equal to the version of the beginning index. If not, step 680 sets the space map block entry to (0, 0) to indicate that the block is free-to-use. Otherwise, step 660 sets the ending index to the latest in-use snapshot before the current ending index.
  • [0070]
    After completion of either step 660 or 680, step 670 tests for another space map block entry. If there are more space map block entries to process, control returns to step 610. After all space map block entries have been processed, control resumes at Reference K on FIG. 12 b to remove index table entries for deleted snapshots.
  • [0071]
    FIG. 16 illustrates a diagram of a case where a second reversion to a prior snapshot s has occurred before the background cleaning process for the first reversion to snapshot p has completed. As the file system reverts to a prior snapshot, a pending list is maintained to record the indexes and associated version numbers of the affected snapshots each time the reversion process is invoked. If the file system reverts to more than one snapshot over a span of time where the background cleaning process has not completed, the pending list organizes the cleaning activity by individual reversion event to maintain data reliability of the snapshots. Multiple reversions are likely to occur in large and/or high activity test environments.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5317731 *Feb 25, 1991May 31, 1994International Business Machines CorporationIntelligent page store for concurrent and consistent access to a database by a transaction processor and a query processor
US5664186 *May 8, 1995Sep 2, 1997International Business Machines CorporationComputer file management and backup system
US5819292 *May 31, 1995Oct 6, 1998Network Appliance, Inc.Method for maintaining consistent states of a file system and for creating user-accessible read-only copies of a file system
US6205450 *Jun 29, 1998Mar 20, 2001Kabushiki Kaisha ToshibaComputer system capable of restarting system using disk image of arbitrary snapshot
US6247099 *Jun 3, 1999Jun 12, 2001International Business Machines CorporationSystem and method for maintaining cache coherency and data synchronization in a computer system having multiple active controllers
US6289356 *Sep 14, 1998Sep 11, 2001Network Appliance, Inc.Write anywhere file-system layout
US6311193 *Sep 28, 1998Oct 30, 2001Kabushiki Kaisha ToshibaComputer system
US6484186 *Feb 15, 2000Nov 19, 2002Novell, Inc.Method for backing up consistent versions of open files
US6490659 *Mar 31, 2000Dec 3, 2002International Business Machines CorporationWarm start cache recovery in a dual active controller with cache coherency using stripe locks for implied storage volume reservations
US6636879 *Aug 18, 2000Oct 21, 2003Network Appliance, Inc.Space allocation in a write anywhere file system
US20020049718 *May 10, 2001Apr 25, 2002Kleiman Steven R.File system image transfer
US20020083037 *Aug 17, 2001Jun 27, 2002Network Appliance, Inc.Instant snapshot
US20020133735 *Jan 16, 2001Sep 19, 2002International Business Machines CorporationSystem and method for efficient failover/failback techniques for fault-tolerant data storage system
US20030018878 *Jul 18, 2002Jan 23, 2003Sean Matthew DorwardMethod and apparatus for archival data storage
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7636821 *Jan 15, 2004Dec 22, 2009International Business Machines CorporationAsynchronous hybrid mirroring system
US7660837Oct 6, 2006Feb 9, 2010Broadcom CorporationMethod for automatically managing disk fragmentation
US7680838 *Nov 12, 2004Mar 16, 2010Intuit Inc.Maintaining data synchronization in a file-sharing environment
US7716171 *Aug 18, 2005May 11, 2010Emc CorporationSnapshot indexing
US7765244 *Oct 6, 2006Jul 27, 2010Broadcom CorporationFast and efficient method for deleting very large files from a filesystem
US7860896Jan 12, 2010Dec 28, 2010Broadcom CorporationMethod for automatically managing disk fragmentation
US7921081 *May 30, 2007Apr 5, 2011International Business Machines CorporationManaging a snapshot stored within a file system space for efficient detection of in-use blocks
US7966351Jul 26, 2010Jun 21, 2011Broadcom CorporationFast and efficient method for deleting very large files from a filesystem
US8200922Dec 17, 2008Jun 12, 2012Netapp, Inc.Storage system snapshot assisted by SSD technology
US8260753Mar 18, 2005Sep 4, 2012Emc CorporationBackup information management
US8346826 *Sep 28, 2005Jan 1, 2013Nec CorporationSwitch device, system, backup method and computer program
US8533411Mar 2, 2011Sep 10, 2013International Business Machines CorporationMultiple backup processes
US8600939 *Oct 24, 2011Dec 3, 2013Oracle International CorporationWritable snapshots
US8666939Jun 28, 2011Mar 4, 2014Sandisk Enterprise Ip LlcApproaches for the replication of write sets
US8667001Jun 20, 2012Mar 4, 2014Sandisk Enterprise Ip LlcScalable database management software on a cluster of nodes using a shared-distributed flash memory
US8667212Aug 13, 2012Mar 4, 2014Sandisk Enterprise Ip LlcSystem including a fine-grained memory and a less-fine-grained memory
US8676862Mar 18, 2005Mar 18, 2014Emc CorporationInformation management
US8677055Jan 3, 2011Mar 18, 2014Sandisk Enterprises IP LLCFlexible way of specifying storage attributes in a flash memory-based object store
US8694733Feb 17, 2012Apr 8, 2014Sandisk Enterprise Ip LlcSlave consistency in a synchronous replication environment
US8700842Jan 3, 2011Apr 15, 2014Sandisk Enterprise Ip LlcMinimizing write operations to a flash memory-based object store
US8725951Jan 3, 2011May 13, 2014Sandisk Enterprise Ip LlcEfficient flash memory-based object store
US8732386Aug 25, 2008May 20, 2014Sandisk Enterprise IP LLC.Sharing data fabric for coherent-distributed caching of multi-node shared-distributed flash memory
US8788770Mar 22, 2011Jul 22, 2014International Business Machines CorporationMultiple cascaded backup process
US8793453 *May 29, 2012Jul 29, 2014International Business Machines CorporationMultiple cascaded backup process
US8793531Apr 11, 2011Jul 29, 2014Sandisk Enterprise Ip LlcRecovery and replication of a flash memory-based object store
US8856472Mar 20, 2013Oct 7, 2014International Business Machines CorporationRestore in cascaded copy environment
US8856593Apr 12, 2011Oct 7, 2014Sandisk Enterprise Ip LlcFailure recovery using consensus replication in a distributed flash memory system
US8868487Apr 11, 2011Oct 21, 2014Sandisk Enterprise Ip LlcEvent processing in a flash memory-based object store
US8868860Sep 23, 2011Oct 21, 2014International Business Machines CorporationRestore in cascaded copy environment
US8874515 *Apr 11, 2011Oct 28, 2014Sandisk Enterprise Ip LlcLow level object version tracking using non-volatile memory write generations
US8954385Jun 28, 2011Feb 10, 2015Sandisk Enterprise Ip LlcEfficient recovery of transactional data stores
US9002794 *Aug 6, 2013Apr 7, 2015American Megatrends, Inc.Reclaiming space from a file system
US9026512Aug 18, 2005May 5, 2015Emc CorporationData object search and retrieval
US9047351Apr 11, 2011Jun 2, 2015Sandisk Enterprise Ip LlcCluster of processing nodes with distributed global flash memory using commodity server technology
US9135064Mar 7, 2012Sep 15, 2015Sandisk Enterprise Ip LlcFine grained adaptive throttling of background processes
US9164554Apr 11, 2011Oct 20, 2015Sandisk Enterprise Ip LlcNon-volatile solid-state storage system supporting high bandwidth and random access
US9183236Apr 28, 2014Nov 10, 2015Sandisk Enterprise Ip LlcLow level object version tracking using non-volatile memory write generations
US9454440Mar 18, 2005Sep 27, 2016Emc CorporationVersatile information management
US9514004Oct 15, 2014Dec 6, 2016International Business Machines CorporationRestore in cascaded copy environment
US20050160242 *Jan 15, 2004Jul 21, 2005International Business Machines CorporationAsynchronous hybrid mirroring system
US20050273545 *Aug 5, 2005Dec 8, 2005International Business Machines CorporationFlexible techniques for associating cache memories with processors and main memory
US20060080370 *Sep 28, 2005Apr 13, 2006Nec CorporationSwitch device, system, backup method and computer program
US20060149793 *Mar 18, 2005Jul 6, 2006Emc CorporationBackup information management
US20070043705 *Aug 18, 2005Feb 22, 2007Emc CorporationSearchable backups
US20070043790 *Aug 18, 2005Feb 22, 2007Emc CorporationSnapshot indexing
US20080005205 *Oct 6, 2006Jan 3, 2008Broadcom CorporationFast and efficient method for deleting very large files from a filesystem
US20080005206 *Oct 6, 2006Jan 3, 2008Broadcom CorporationMethod for automatically managing disk fragmentation
US20080162595 *Mar 18, 2005Jul 3, 2008Emc CorporationFile and block information management
US20080162608 *Mar 11, 2008Jul 3, 2008Nec CorporationSwitch device, system, backup method and computer program
US20080162685 *Mar 18, 2005Jul 3, 2008Emc CorporationInformation management architecture
US20080162719 *Mar 18, 2005Jul 3, 2008Emc CorporationVersatile information management
US20080301203 *May 30, 2007Dec 4, 2008Adkins Janet EManaging a snapshot stored within a file system space for efficient detecting of in-use blocks
US20100153620 *Dec 17, 2008Jun 17, 2010Mckean BrianStorage system snapshot assisted by SSD technology
US20100290755 *Jul 26, 2010Nov 18, 2010Broadcom CorporationFast and efficient method for deleting very large files from a filesystem
US20110225380 *Mar 2, 2011Sep 15, 2011International Business Machines CorporationMultiple backup processes
US20120259863 *Apr 11, 2011Oct 11, 2012Bodwin James MLow Level Object Version Tracking Using Non-Volatile Memory Write Generations
WO2010071662A1 *Mar 30, 2009Jun 24, 2010Lsi CorporationStorage system snapshot assisted by ssd technology
Classifications
U.S. Classification1/1, 707/E17.01, 707/999.2
International ClassificationG06F12/00, G06F17/30, G06F
Cooperative ClassificationY10S707/99956, Y10S707/915, Y10S707/99953, G06F17/30067
European ClassificationG06F17/30F
Legal Events
DateCodeEventDescription
Sep 13, 2004ASAssignment
Owner name: PILLAR DATA SYSTEMS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KAPOOR, VIKRAM;SHOENS, KURT ALAN;SCHULTZ, MARK STEVEN;AND OTHERS;REEL/FRAME:015772/0041
Effective date: 20040602
Apr 24, 2009FPAYFee payment
Year of fee payment: 4
Oct 25, 2011ASAssignment
Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA
Free format text: IP TRANSFER AGREEMENT;ASSIGNOR:PILLAR DATA SYSTEMS, INC.;REEL/FRAME:027116/0608
Effective date: 20110926
Mar 6, 2013FPAYFee payment
Year of fee payment: 8
Apr 13, 2017FPAYFee payment
Year of fee payment: 12