DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This office action is in response to the amendment filed on 06/18/2026.
Claims 1-3, 5-7, 9-10 and 12-20 are presented for further examination.
Applicant amended independent claims 1, 19, and 20 to incorporate limitations previously recited in dependent claims 4, 8, and 11, and canceled claims 4, 8, and 11. The amended independent claims now require, inter alia, forward metadata indicating a logical-to-physical mapping, a root node address of a metadata tree written into a superblock of a header of the logical volume, and accessing the forward metadata according to the root node address.
Applicant's amendment necessitated the new ground of rejection presented below. In particular, Zheng is newly relied upon to address the limitations incorporated into independent claims 1, 19, and 20 by Applicant's amendment. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a).
Response to Argument
Applicant's arguments filed 06/18/2026 have been fully considered but are not persuasive with respect to the claims as presently amended and the new grounds of rejection set forth below.
Applicant argues that Pawar concerns file-system clean/dirty status rather than recovery of metadata of a logical volume, and that Warszawski does not cure this deficiency. The argument has been considered. The rejection does not rely upon Pawar alone for the logical-volume context. Pawar teaches maintaining a clean/dirty status and using that status during initialization/recovery, while Warszawski teaches metadata associated with logical volumes and mappings between logical volumes and physical storage. The references are relied upon for their respective teachings as set forth in detail in the rejection below.
Applicant further argues that the cited references fail to teach, when the metadata is in the clean state, determining that forward metadata indicating a logical-block-address-to-physical-block-address mapping is stored on persistent storage, reading the forward metadata into memory, and thereby restoring the metadata to an accessible state.
This argument has been considered. As explained in the rejection below, Pawar teaches logical-to-physical address mapping information and recovery based upon the clean/dirty status, Warszawski provides the logical-volume metadata context, and newly cited Zheng further teaches persistent volume metadata associated with host-accessible logical addresses and reading persistent volume metadata back into memory during recovery to reconstruct the in-memory metadata structure. The teachings of the references are relied upon in combination rather than individually.
Applicant further argues that Pawar does not teach writing a root node address of the claimed metadata tree into a superblock of a header of the logical volume. The argument is persuasive as to Pawar considered alone, but does not overcome the new combination presented herein. Newly cited Zheng teaches a volume metadata tree and expressly teaches maintaining in a volume superblock a region key referencing the root of the volume metadata tree. Zheng further teaches that the top level of the metadata tree may be implemented as a B+ tree having a root node. Accordingly, the new rejection does not rely upon Pawar's inode hierarchy as teaching the newly incorporated superblock/root-node relationship.
Applicant additionally argues that Pawar does not teach reading a root node address and accessing forward metadata of the logical volume according to that root node address. This argument likewise does not overcome the new rejection. Zheng teaches applying the region key maintained in the volume superblock to access the corresponding volume metadata tree and further teaches updating the region key of the volume superblock to reference the root of the active metadata tree. Thus, Zheng is relied upon for the root-reference-to-metadata-tree access relationship that Applicant argues is absent from Pawar.
Accordingly, Applicant's arguments directed to the absence of the newly incorporated limitations from Pawar and Warszawski do not overcome the rejection because the rejection has been modified, as necessitated by Applicant's amendment, to further rely upon Zheng for the volume-superblock, metadata-tree-root, and root-based metadata-access teachings. The complete teachings of the references and the rationale for their combination are set forth in the new grounds of rejection below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 5-6, 9-10, 12-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pawar et al. (US9542396; hereinafter Pawar), in view of Warszawski et al. (US2014/0208045; hereinafter Warszawski) and further in view of Zheng et al. (US 2015/0142817; hereinafter Zheng).
Regarding independent claims 1, 19, and 20, taking claim 1 as exemplary,
Pawar teaches a method of recovering a storage system having file-system metadata and associated transaction logs stored in non-volatile storage, including maintaining a status parameter indicative of whether metadata changes have been written in place and whether the file system is clean or dirty:
See col. 3, ll. 40-62, Pawar teaches a storage system including file systems and associated transaction logs stored non-volatile storage devices used for metadata recovery “the file system may include a status parameter, a value of which indicates whether the file system is clean or dirty”; Claim 19, A non-transitory computer-readable medium encoded with computer-executable instructions that, as a result of being executed by a computer, control the computer to perform a method comprising: determining whether the one or more changes to metadata represented by each of the plurality of log entries have been written in place in the file system; and in response to the determination, setting the status parameter to a value indicative of the determination), comprising:
in a case where metadata of a logical volume has not been modified, marking a state of the metadata of the logical volume as a clean state (
Pawar teaches maintaining a status parameter indicative of whether metadata changes have been written in place and whether the file system is clean or dirty. Pawar teaches a file-system status parameter indicating whether the file system is clean or dirty: see col. 11, l. 67–col. 12, l. 2, “a file system may include a status parameter indicating whether the file system is ‘clean’ or ‘dirty,’ which may be used to determine whether it is necessary to replay the transaction log.”
Pawar further teaches changing the status to dirty when metadata is modified (Fig. 8A, step 818) and marking the file system clean when the metadata changes have been written in place (Fig. 11).
Pawar further teaches, after the storage system is powered back on, reading/using the state to determine the recovery operation: see col. 3, ll. 56–62, when the metadata changes represented by the transaction-log entries have been written in place, “the status parameter is set to a first value indicating to not replay the transaction log when the file system is initialized. During an initializing of the file system, replaying any portion of the metadata transaction log is refrained from based on the first value.”
Thus, when the status indicates that the metadata changes have been written in place, Pawar initializes the file system without replaying the corresponding transaction log.
Pawar further teaches logical-to-physical address mapping metadata: see col. 1, ll. 62–64, “An inode of a file defines an address map that converts a logical address of the file to a physical address of the file”; col. 7, ll. 28–31, cached disk array 19 may include multiple disk drives, cache memory, and a “logical-to-physical mapping between the cache memory and the disk drives.” Pawar also teaches that its file system operates upon logical volumes: see col. 7, ll. 53–56, “File system manager 46 may be configured to access data organized into logical volumes defined by a logical volume layer module 47.”
However, Pawar does not expressly teach that the claimed metadata is volume metadata organized in a tree whose root reference is maintained in a volume superblock and used to access the volume metadata.
Warszawski teaches metadata specifically describing logical volumes. In particular, Warszawski teaches that LVM metadata stored on the drives contains configuration details of logical volumes and may indicate mappings between drives and logical volumes. Warszawski further teaches that committed metadata is permanent metadata used for accessing the logical volumes. See, e.g., [0036]–[0038].
Warszawski also expressly claims in claim 8, “the committed metadata indicates a mapping between the plurality of logical volumes and one or more of: the plurality of drives or portions of the plurality of drives.”
Thus, Warszawski supplies the express logical-volume metadata context lacking in Pawar.
Pawar and Warszawski do not expressly teach: “writing, into a superblock of a header of the logical volume, a root node address of a tree structure where the metadata is located,” and thereafter: “reading the root node address; and accessing forward metadata of the logical volume according to the root node address.”
Zheng cures these deficiencies. Zheng teaches a storage architecture in which storage devices are SSDs embodied as flash storage devices, and the metadata managed by a volume layer is volume metadata organized as a multi-level dense tree metadata structure. Zheng further teaches that the volume metadata provides mappings from host-accessible LUN addresses (LBAs) to durable extent keys. Most significantly, Zheng teaches in Fig. 7, “A region key 762 to a root, e.g., level 0 header 730 (and top level 800), of the dense tree 700 is illustratively stored on-flash and maintained in a volume root extent, e.g., a volume superblock 760.”. Zheng further teaches: “the volume superblock 760 contains region keys to the roots of the dense tree metadata structures for all regions in a volume.”
Accordingly, Zheng expressly teaches the claimed architectural relationship of a volume superblock containing a reference to the root of the tree in which volume metadata is located.
Zheng further teaches that the top level of the dense tree may be a B+ tree: see Fig. 8, the top level 800 “is maintained in-core as a balanced tree, which is illustratively embodied as a B+ tree data structure,” including “a root node 810, one or more internal nodes 820 and a plurality of leaf nodes 830.”
Zheng further expressly teaches using the stored root reference to access the volume metadata tree: see Fig. 10, “the volume metadata process 710 applies the region key 762 to access the dense tree 700 (i.e., top level 800)” of the appropriate volume region. Zheng additionally teaches updating the volume superblock to point to the current root after a metadata-tree update: “Upon completion of the merge, the region key 762 of volume superblock 760 is updated to reference (point to) the root ... of the active dense tree 1150.”
Thus, Zheng teaches writing/maintaining a root reference in a volume superblock, reading/applying that reference, and thereby accessing the volume metadata tree.
Zheng additionally teaches the claimed recovery relationship between persistent metadata and memory. Zheng's volume layer log contains volume metadata entries that are flushed to SSD. During recovery: “the volume layer log 345 is read back to memory 220 to reconstruct the in-core top level 800 (i.e., level 0) of dense tree 700. Other levels may be demand paged via the page cache 448.”
Thus Zheng expressly teaches persistent volume metadata being read from SSD into memory during recovery to restore the in-memory metadata tree.
It would have been obvious to one of ordinary skill in the art before the effective filing date to apply Pawar's clean/dirty metadata-state recovery mechanism to Warszawski's logical-volume metadata, organized and persistently located according to Zheng's volume-superblock/rooted-tree architecture.
Pawar and Warszawski concern about maintaining reliable persistent metadata used to access stored information, while Zheng expressly addresses efficient organization, persistence, checkpointing, lookup, and recovery of volume metadata in flash/SSD storage. Zheng teaches maintaining a root reference in the volume superblock so that the appropriate metadata tree can be located and accessed efficiently, and teaches recovering persistent volume metadata into memory. A person of ordinary skill seeking to apply Pawar's clean-state recovery technique to logical-volume metadata would therefore have had reason to employ Zheng's volume metadata organization so that the persistent metadata could be efficiently located and accessed following initialization.
The combination would predictably result in a system wherein, when the metadata is determined to be clean, the persistent volume metadata can be located through the root reference maintained in the volume superblock and accessed/restored without requiring reconstruction associated with an inconsistent state.
Therefore, Pawar in view of Warszawski and Zheng teaches or suggests the limitations of amended claims 1, 19, and 20.
Regarding claim 5, in view of Warszawski and Zheng, Pawar further teaches
wherein the marking a state of the metadata of the logical volume as a clean state comprises: marking, in the logical volume, the state of the metadata of the logical volume as the clean state (Pawar discloses file system metadata structures including superblocks and metadata structures stored on disk as shown in Fig. 3. Pawar further teaches maintaining the clean/dirty state as a status parameter associated with the file system and expressly teaches that the status parameter may be maintained in the file-system superblock (col. 20, ll. 54–63). Warszawski supplies the logical-volume metadata context, and Zheng teaches persistent metadata associated with a volume and maintained through a volume superblock. It would therefore have been obvious to maintain Pawar's clean/dirty state as part of the metadata associated with the logical volume in the combined system).
Regarding claim 6, the combination of Pawar, Warszawski and Zheng further teaches wherein marking, in the logical volume, the state of the metadata of the logical volume as the clean state comprises: marking, in a superblock of a header of the logical volume, the state of the metadata of the logical volume as the clean state (Pawar discloses file system metadata structures including superblocks and other metadata blocks stored on disk as shown in Fig. 3;
col. 20, ll. 54-63, “file system 724 may include a status parameter 725 (e.g., in its superblock), a value of which may be indicative of whether to replay the transaction log 726 if/when the file system is initialized. That is, parameter 725 may indicate whether the file system 724 is “clean” or “dirty.” The file system may be deemed clean if all sectors of the transaction log are clear (e.g., as reflected in log use map 728)”
In combination with Warszawski's logical-volume metadata and Zheng's volume superblock 760, it would have been obvious to maintain Pawar's clean/dirty status in the persistent volume-superblock metadata used to identify and recover the logical-volume metadata).
Regarding claim 9, Zheng further teaches wherein writing, into the superblock of the header of the logical volume, a root node address of a tree structure where the metadata is located comprises writing a root node address of a B+ tree, because Zheng teaches that top level 800 of the dense metadata tree is illustratively embodied as a B+ tree data structure including root node 810, internal nodes 820, and leaf nodes 830 (Zheng, Fig. 8). As discussed with respect to claim 1, Zheng further teaches maintaining in volume superblock 760 a region key referencing the root of the volume metadata tree.
Regarding claim 10, Pawar teaches determining that all relevant metadata changes have been written in place and, upon that determination, marking the corresponding metadata/file-system state clean, while Zheng teaches checkpointing/merging updated volume metadata into the persistent B+ tree and updating the volume-superblock root reference upon completion of the merge. Although neither reference expressly describes each B+ tree node using the claimed “clean state” terminology, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply Pawar's clean-state determination to Zheng's B+ tree metadata organization, such that B+ tree nodes having no outstanding modified metadata remaining to be persisted are determined to be in the clean state. Upon completion of the metadata persistence/merge, the corresponding metadata state would be marked clean and Zheng's volume superblock would contain the root reference identifying the current persistent B+ tree. Such application predictably uses Pawar's clean/dirty status technique to indicate whether Zheng's persistent metadata-tree contents include outstanding modifications requiring persistence, while preserving Zheng's volume-superblock root reference for subsequent access and recovery.
Thus, Pawar teaches determining that the relevant metadata modifications have been written in place and thereafter marking the metadata/file-system state clean, while Zheng teaches organizing the volume metadata as a B+ tree, persisting updates to that tree, and maintaining/updating in the volume superblock a reference to the root of the active tree. Accordingly, Pawar, Warszawski, and Zheng render obvious the additional limitations of claim 10.
Regarding claim 12, in view of Warszawski and Zheng, Pawar further teaches in a case where the metadata of the logical volume has been modified, marking the state of the metadata of the logical volume as a dirty state (Fig. 8A step 818: “If file system is marked as clean, change to dirty”; Pawar discloses file system metadata structures including superblocks and metadata structures stored on disk as shown in Fig. 3. These structure store metadata and file-system attributes including state information; col. 20, ll. 54-67.
In view of Warszawski's logical-volume metadata and Zheng's volume superblock, the combination teaches or suggests applying that clean/dirty state to the claimed logical-volume metadata and maintaining the state in the corresponding persistent volume metadata structure).
Regarding claim 13, in view of Warszawski and Zheng, Pawar further teaches wherein the marking the state of the metadata of the logical volume as the dirty state comprises: marking, in the logical volume, the state of the metadata of the logical volume as the dirty state (Fig. 8A step 818: “If file system is marked as clean, change to dirty”; Pawar discloses file system metadata structures including superblocks and metadata structures stored on disk as shown in Fig. 3. These structure store metadata and file-system attributes including state information; col. 20, ll. 54-67).
Regarding claim 14, the combination of Pawar, Warszawski and Zheng further teaches wherein the marking, in the logical volume, the state of the metadata of the logical volume as the dirty state comprises: marking, in a superblock of a header of the logical volume, the state of the metadata of the logical volume as the dirty state (Pawar, Fig. 8A step 818: “If file system is marked as clean, change to dirty”; Pawar discloses file system metadata structures including superblocks and metadata structures stored on disk as shown in Fig. 3. These structure store metadata and file-system attributes including state information; col. 20, ll. 54-67
In view of Warszawski's logical-volume metadata and Zheng's volume superblock, it would have been obvious to maintain Pawar's clean/dirty status parameter in the volume superblock of the combined system).
Regarding claim 15, in view of Warszawski and Zheng, Pawar further teaches wherein in a case where the metadata of the logical volume has been modified, marking the state of the metadata of the logical volume as the dirty state comprises: in a case where there is written data for the logical volume, determining whether the state of the metadata of the logical volume is the clean state; and, in a case where the state is the clean state, changing the state to the dirty state (Pawar, Fig. 8A, step 818: “If file system is marked as clean, change to dirty”; see also col. 20, ll. 54–67, teaching a status parameter indicating whether the file system is clean or dirty).
Pawar therefore expressly teaches the claimed determination of the existing clean state and the resulting clean-to-dirty state transition in response to an operation that modifies metadata. Although Pawar does not expressly characterize the control operations implementing step 818 using the claimed terminology of “initiating a request ... to cause a control end of a state machine to trigger the state machine to run, and initiate a task of changing the state ... and executing the task,” Pawar's Fig. 8A expressly implements the clean-to-dirty change as a sequential control operation: the process determines whether the file system is clean and, upon satisfaction of that condition, proceeds to the operation that changes the state to dirty.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Pawar's expressly taught conditional clean-to-dirty control operation using a state-machine implementation in which the occurrence of the condition causes the state-changing operation to be initiated and executed. Such implementation does not alter the condition being evaluated or the state transition taught by Pawar, but merely implements Pawar's sequential control flow as a corresponding state transition, predictably resulting in the status being changed from clean to dirty when the predetermined condition is satisfied.
Accordingly, Pawar, in view of Warszawski and Zheng, renders obvious the additional limitations of claim 15.
Regarding claim 16, Pawar teaches recovering metadata by replaying transaction-log entries and separately teaches logical-to-physical address-map metadata (Fig. 12; col. 1, l. 51–col. 2, l. 7). Warszawski further teaches persistent logical-volume mapping metadata, and Zheng teaches recovery of persistent volume metadata into memory. It would have been obvious to use the recovered/reconstructed persistent volume metadata to restore the logical-to-physical mapping information used for accessing the logical volume.
Thus, the combination of Pawar, Warszawski and Zheng teaches reconstructing forward metadata being configured to indicate a mapping relationship from a logical block address to a physical block address in a case where the state of the metadata of the logical volume is the dirty state restoring the metadata of the logical volume to the accessible state after the forward metadata is reconstructed (Pawar, Fig. 12 illustrates replay of transaction-log entries to recover metadata; col. 1, line 51 to col.2 line 7, “An inode of a file defines an address map that converts a logical address of the file to a physical address of the file. Further, in order to create the address map, the inode includes direct data block pointers and indirect block pointers; Warszawski, Claim 8; “the committed metadata indicates a mapping between the plurality of logical volumes and one or more of: the plurality of drives or portions of the plurality of drives”).
Claims 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over Pawar et al. (US9542396; hereinafter Pawar) in view of Warszawski et al. (US2014/0208045; hereinafter Warszawski) and Zheng et al. (US 2015/0142817; hereinafter Zheng), further in view of Chen et al. (US 10235066; hereinafter Chen).
Regarding claim 2, in view of Warszawski and Zheng, Pawar further teaches
wherein in a case where metadata of a logical volume has not been modified, marking a state of the metadata of the logical volume as a clean state comprises: in a case where, …and the metadata of the logical volume has been written from a cache to a data storage device, marking the state of the metadata of the logical volume as the clean state (Pawar further teaches metadata cached in volatile memory being flushed to persistent storage: see col. 2, ll. 29–38, data and metadata cached in volatile memory are written to disk “at intervals or in response to an event,” and “[f]lushing of a cache may be triggered at a determinate time interval.”
Pawar further teaches that the clean state corresponds to the condition in which all relevant metadata changes have been written in place: see col. 20, ll. 54–67, the file system may be deemed clean when the transaction-log sectors are clear, i.e., “all changes to metadata for which transaction entries have been recorded ... have been written in place.”
Pawar discloses caching metadata in volatile memory and writing committed metadata blocks to disk. Fig. 11 shows writing metadata blocks to disk and marking the file system clean when the dirty block list is cleared;
col. 2, ll. 30-34, Data and metadata of a file cached in the volatile memory is written to the disk at intervals or in response to an event, …Flushing of a cache may be triggered at a determinate time interval).
Pawar teaches periodic/event-driven flushing of cached metadata and transitioning to the clean state after the metadata changes have been written in place, but
does not expressly teach conditioning the operation upon an interval during which no user-accessible data is written to the volume.
Chen, col. 16, ll. 47–52 teaches the conventional technique of an “idle” destage to flush metadata to disk.
It would have been obvious to perform Pawar's metadata destage/clean-state operation during Chen's idle destage period because doing so permits pending metadata to be persisted when foreground/user write activity is idle, thereby reducing interference with user I/O.
Regarding claim 3, the combination of Pawar, Warszawski, Zheng, and Chen further teaches wherein in a case where, within a preset timing period, there is no user-accessible data written to the logical volume and the metadata of the logical volume has been written from a cache to a data storage device, marking the state of the metadata of the logical volume as the clean state.
Pawar teaches caching metadata in volatile memory and writing the cached metadata to disk at intervals or in response to an event (Pawar, col. 2, ll. 30–34). Pawar further teaches determining that the metadata changes have been written in place and thereafter marking the file system clean. In particular, Fig. 11 teaches writing metadata blocks to disk and, upon completion of the relevant metadata writes/clearing of the dirty-block condition, marking the file system clean; see also Pawar, col. 20, ll. 54–67.
Chen additionally teaches an “idle” destage used to flush metadata to disk (Chen, col. 16, ll. 47–52), corresponding to the claimed starting an idle task of writing the metadata from the cache to the data storage device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to perform Pawar's metadata flushing and subsequent clean-state update during the idle destage taught by Chen, because Chen's idle destage provides an available period for flushing metadata to persistent storage, while Pawar teaches marking the status clean after the relevant metadata changes have been written in place. The combination predictably performs Pawar's metadata persistence and clean-state update during Chen's taught idle destage operation.
Thus, Chen teaches starting an idle task of writing the metadata from the cache to the data storage device (col. 16, ll. 47–52), while Pawar teaches determining whether the metadata has been written to the data storage device and, when the relevant metadata has been written in place, changing the state to clean (Fig. 11; col. 20, ll. 54–67).
Although Pawar does not expressly characterize the control operations implementing the clean-state update using the claimed terminology of “initiating a request ... to cause a control end of a state machine to trigger the state machine to run, and initiate a task of changing the state ... and executing the task,” Pawar's Fig. 11 expressly implements the clean-state update as a conditional sequential control operation: after determining that the relevant metadata changes have been written in place, the process proceeds to the operation that marks the file system clean.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Pawar's expressly taught conditional clean-state update using a state-machine implementation in which satisfaction of the metadata-write condition causes the state-changing operation to be initiated and executed. Such implementation does not change Pawar's condition or resulting clean-state transition, but merely implements the taught sequential control flow as a corresponding state transition, predictably resulting in the status being marked clean after the metadata has been written in place. Accordingly, Pawar, Warszawski, Zheng, and Chen render obvious the additional limitations of claim 3.
Claim 17 are rejected under 35 U.S.C. 103 as being unpatentable over Pawar et al. (US9542396; hereinafter Pawar), in view of Warszawski et al. (US2014/0208045; hereinafter Warszawski) and Zheng et al. (US 2015/0142817; hereinafter Zheng), further in view of Peltz et al. (US 2020/0226038; hereinafter Peltz).
Regarding claim 17, the combination of Pawar, Warszawski and Zheng teaches the underlying volume-metadata recovery system but does not expressly teach reconstructing the forward mapping by scanning physical storage using metadata associated with physically stored data.
In an analogous art of data recovery, Peltz teaches reading a logical partition space of the logical volume in a physical disk, and reconstructing the forward metadata using backward metadata ([0040], Control data rebuild circuit 616 may check the last recorded entries in control data 614 to see where the last recorded writes occurred in open blocks 602, 604, 606. Control data rebuild circuit 616 may then scan beyond the last recorded writes in open blocks 602, 604, 606 to see if there was any data written after these writes. If there were additional writes, metadata written with such data (e.g. LBA and/or other identifying information) is read and used to rebuild control data 610 (e.g. to build a logical-to-physical map based on physical locations where data is found and LBAs associated with the data)).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention was made, with the teachings of Pawar, Warszawski, Zheng and Peltz before them, to incorporate Peltz’s scanning based recovery into Pawar’s metadata recovery system because scanning storage blocks allows reconstruction of metadata that was not recorded in a journal or checkpoint prior to a power failure.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Pawar et al. (US9542396; hereinafter Pawar), in view of Warszawski et al. (US2014/0208045; hereinafter Warszawski) and Zheng et al. (US 2015/0142817; hereinafter Zheng), further in view of Lv et al. (US 2021/0303196; hereinafter Lv).
Regarding claim 18, the combination of Pawar, Warszawski, Zheng, and Lv further teaches in a case where the state of the metadata of the logical volume is the clean state, and each time new user-accessible data is written, inserting a new mapping relationship from a logical block address to a physical block address into the tree structure, to cause at least one node of the tree structure to be modified and cause the tree structure to be in the dirty state.
Pawar teaches a persistent clean/dirty status and expressly teaches changing the status from clean to dirty when a new write operation produces metadata changes. In particular, when the file system is currently marked clean, Pawar changes the file system to dirty because a newly created transaction-log entry represents corresponding metadata that has not yet been written in place (Pawar, Fig. 8A, step 818; col. 20, ll. 54–67).
Pawar further teaches logical-to-physical mapping metadata. Specifically, Pawar teaches that an inode defines an address map converting a logical address to a physical address (Pawar, col. 1, ll. 62–64), and further teaches a logical-to-physical mapping associated with the cached disk array (Pawar, col. 7, ll. 28–31).
Zheng further teaches organizing volume metadata associated with logical address ranges in a dense tree whose top level may be implemented as a B+ tree. Zheng teaches that incoming volume metadata entries resulting from new operations are inserted into the active tree, and that new index entries are generated as the metadata tree is updated. Zheng therefore supplies the tree-update architecture in which new volume metadata modifies the active metadata tree.
However, Pawar, Warszawski, and Zheng do not expressly characterize a B+ tree update that has not yet been persisted to the B+ tree on the solid-state storage as placing the tree in a “dirty” state.
Lv teaches such a dirty B+ tree update. In particular, Lv [0084] teaches a “dirty journal entry” comprising a B+ tree update that has not yet been written to the B+ tree on the solid-state disk. Lv [0081]–[0082] further teaches journaling insertions into the B+ tree and maintaining ordered metadata writes so that the B+ tree and other contents remain consistent on the solid-state disk in the event of abnormal shutdown.
It would have been obvious to one of ordinary skill in the art before the effective filing date to employ Lv's journaled B+ tree update technique in the combined Pawar/Warszawski/Zheng system when inserting new or modified mapping metadata into the metadata tree. Both Zheng and Lv address persistent metadata-tree updates in solid-state storage, and Lv's journaling technique provides a predictable mechanism for identifying and preserving B+ tree updates that have not yet been incorporated into the persistent tree, thereby maintaining metadata consistency and permitting recovery following an abnormal shutdown.
Accordingly, when a new write causes new or modified logical-to-physical mapping metadata to be inserted into the tree, the affected tree metadata is modified and remains dirty until the corresponding B+ tree update has been written to the persistent B+ tree. The combination therefore renders obvious the additional limitations of claim 18.
Allowable Subject Matter
Claim 7 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, TIM VO can be reached on (571)272-3642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRACY C CHAN/ Primary Examiner, Art Unit 2138
