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 Application
This office action is in response to the Application filed on 01/17/2025.
Claims 1-20 are presented for examination.
Drawings
The drawings submitted on 01/17/2025 are accepted.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because a computer-readable storage medium in the claimed invention are directed to non-statutory subject matter.
The claims recite a “A non-volatile computer-readable storage medium, wherein the non-volatile computer readable storage medium stores a computer program which, when executed by the processor, implements the steps of …”.
The specification does not disavow the term “computer-readable storage medium” from encompassing signals per se. Paragraph [0180] cites “The non-volatile readable storage medium may include any medium that can store program codes, such as a USB flash disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.”.
This language does not positively preclude the embodiments from encompassing a signal per se.
Applicant is suggested to amend the claims to recite a non-transitory non-volatile computer-readable storage medium to exclude non-statutory transitory embodiments disclosed in the specification and under a broadest reasonable interpretation of the claim language.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 3, 10, and 19-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claims 2, 3, and 10, the claims recite: “within a preset timing period, there is no user-accessible data dispatched for the logical volume.”
The term “dispatched” lacks a clear meaning in the storage-system art. It is unclear whether the phrase refers to:
• host write requests issued• IO commands queued to a storage controller• data written to storage• data flushed from cache
Because multiple reasonable interpretations exist, the scope of the limitation cannot be determined with reasonable certainty. See MPEP 2173.05(e). Therefore claims 2, 3, and 10 are indefinite.
Regarding claims 19 and 20, claim 19 is directed to a device, and claim 20 is directed to a computer-readable storage medium, yet both claims depend on claim 1, which is directed to a method.
Dependency of a claim on another claim of a different statutory class renders the claim scope unclear. See MPEP 2173.05(p).
Example: Claim 19 recites “a device … configured to implement the steps of the method according to claim 1.” Because claim 19 is an apparatus claim and claim 1 is a method claim, the dependency creates uncertainty regarding claim scope.
Thus claims 19 and 20 are indefinite.
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-2, 4-8, 11-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).
Regarding independent claims 1, 19 and 20, taking claim 1 as exemplary analysis,
Pawar teaches A method of recovering an all-flash storage system (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 discloses after a clean shutdown or when no metadata changes are pending, the system marks a status parameter (in the superblock) as “clean” so that, on power-on/initialization, the metadata can be restored to an accessible state without replaying any transaction log, as shown in claim 1 & claim 2;
maintaining a file system status parameter indicating whether the file system is clean or dirty: col. 11, line 67 to col. 12, line 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 metadata changes are written to disk (Fig. 11));
Pawar discloses file system metadata structures stored on logical storage units and used to describe data blocks and files accessing data organized into logical volumes within the storage system (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. Each logical volume maps to contiguous logical storage addresses in cached disk array 19”; col. 9, ll. 15-16, “A file system may be created from a logical device or logical volume”).
Pawar does not explicitly disclose metadata of a logical volume, nor does Pawar disclose utilizing an all-flash system. In an analogous art of storage recovery,
Warszawski cures these deficiencies and supplies the logical-volume and committed/uncommitted metadata handling (Abstract, “A logical volume manager (LVM) may manage a plurality of logical volumes… using metadata stored on the plurality of drives.” Warszawski also discloses distinguishing between committed metadata and uncommitted metadata stored on drives. Note that, committed metadata corresponds to metadata that has been written and represents a consistent state, i.e., the claimed clean state (see Fig. 2A–2B).
Warszawski further discloses the committed metadata explicitly includes mapping information between logical volumes and physical drive portions (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”)
Warszawski further discloses recovering an all-flash storage system ([0003], The VMs and/or the physical machines may use multiple drives (e.g., hard disk drives, flash drives, disc drives, mass storage devices, etc.) to store and/or access data, applications, files, etc)
It would have been obvious to a person of ordinary skill in the art designing a flash storage system to apply clean/dirty superblock flag technique of the metadata recovery architecture of Pawar to the logical volume metadata of Warszawski because both references address the reliability and recovery of metadata describing stored data in non-volatile storage systems. Applying Pawar’s recovery technique would predictably improve the reliability of logical volume metadata following restart events. Thus, the combination of Pawar and Warszawski teaches metadata associated with logical volumes, identifying metadata state (committed/uncommitted), and restoring metadata during recovery.
The combination of Pawar and Warszawski further teaches after an all-flash storage system is powered back on, reading the state of the metadata of the logic volume (Pawar discloses initialization logic determining whether transaction-log replay is required:
col. 3, ll. 56-62, “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 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, Pawar reads the metadata state during restart);
and in a case where the metadata of the logical volume is in the clean state, restoring the metadata of the logical volume to an accessible state (
Pawar teaches that when the file system is clean, the transaction log is not replayed and the file system is immediately usable. Initialization logic in Fig. 12 determines whether replay is required. Thus, metadata stored on disk becomes directly accessible).
Regarding claim 2, in view of Warszawski, 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, within a preset timing period, there is no user-accessible data dispatched for 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 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).
Regarding claim 4, in view of Warszawski, Pawar further teaches wherein in a case where the metadata of the logical volume is in the clean state, the restoring the metadata of the logical volume to an accessible state comprises: in a case where the metadata of the logical volume is in the clean state, determining that forward metadata is stored in a hard disk, the forward metadata being configured to indicate a mapping relationship from a logical block address to a physical block address; and reading the forward metadata from the hard disk to a memory, and restoring the metadata of the logical volume to the accessible state (Pawar, 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. 30-31, “Cached disk array 19 may include any of: multiple disk drives, a high-speed random-access cache memory, and a logical-to-physical mapping {forward metadata} between the cache memory and the disk drives”).
Regarding claim 5, in view of Warszawski, 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. These structure store metadata and file-system attributes including state information).
Regarding claim 6, the combination of Pawar and Warszawski 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)”).
Regarding claim 7, in view of Warszawski, Pawar further teaches
wherein the marking a state of the metadata of the logical volume as a clean state comprises: marking, at a location other than the logical volume, the state of the metadata of the logical volume as the clean state (as shown in Fig. 3, Pawar discloses file system metadata structures including superblocks and other metadata blocks stored on disk. 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)”).
Regarding claim 8, in view of Warszawski, Pawar further teaches in a case where the metadata of the logical volume has not been modified, writing, into a superblock of a header of the logical volume, a root node address of a tree structure where the metadata is located (Pawar in Fig. 3 and col. 9, ll. 40-50 discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks. This hierarchy forms a tree-structured metadata organization rooted at top-level directory col. 1, line 59 to col. 2, line 7 discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks;
col. 20, ll. 54-63 and Fig. 3, Pawar discloses file system metadata structures including superblocks and other metadata blocks stored on disk; Thus, Pawar teaches writing metadata information into the superblock structure).
Regarding claim 11, in view of Warszawski, Pawar further teaches
reading the root node address; and accessing forward metadata of the logical volume according to the root node address (Pawar discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks. This hierarchy forms a tree-structured metadata organization rooted at top-level directory;
Pawar teaches navigating metadata structure starting from inode and directory hierarchy structure. The inode hierarchy maps logical addresses to physical addressed.
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. A data block pointer points to a data block of a file system that contains block that contains an array of block pointers (to either other indirect blocks or to data blocks). There may be as many as five levels of indirect blocks arranged in a hierarchy depending upon the size of a file where each level of indirect blocks includes pointers to indirect blocks at the next lower level.”).
Regarding claim 12, in view of Warszawski, 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).
Regarding claim 13, in view of Warszawski, 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, in view of Warszawski, Pawar 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 (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 15, in view of Warszawski, 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 dispatched for the logical volume, determining whether the state of the metadata of the logical volume is the clean state; in a case where the state of the metadata of the logical volume is the clean state, initiating a request for changing the state of the metadata as the dirty state, to cause a control end of a state machine to trigger the state machine to run, and initiate a task of changing the state of the metadata as the dirty state; and executing the task, and marking 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”; col. 20, ll. 54-67).
Regarding claim 16, the combination of Pawar and Warszawski teaches recover metadata (Pawar, Fig. 12 illustrates replay of transaction-log entries to recover metadata) and metadata include forward metadata (Pawar, 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; col. 7, 28-31, Cached disk array 19 may include any of: multiple disk drives, a high-speed random-access cache memory, and a logical-to-physical mapping between the cache memory and the disk drives; col. 18, ll. 40-48; col. 21, ll. 4-21; Warszawski discloses the committed metadata includes mapping information between logical volumes and physical drive portions as shown 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, the combination of Pawar and Warszawski 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”).
Claim 3 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), further in view of Chen et al. (US 10235066; hereinafter Chen).
Regarding claim 3, in view of Warszawski, Pawar further teaches
wherein in a case where, within a preset timing period, there is no user-accessible data dispatched for 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 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) comprises:
Pawar does not expressly teach starting an idle task.
In an analogous art of data recovery, Chen teaches conventional method starting an idle task of writing the metadata of the logical volume from the cache to the data storage device (col. 16, ll. 47-52, prior methods of destage involve the underlying system relying on a so-called “idle” destage to flush metadata to disk).
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, and Chen before them, to utilize the conventional method of “idle” destage to flush metadata to disk disclosed by Chen because idle destage is one of many conventional design choices.
Thus, the combination of Pawar, Warszawski, and Chen teaches starting an idle task of writing the metadata of the logical volume from the cache to the data storage device (Chen, col. 16, ll. 47-52), and determining whether the metadata of the logical volume has been written from the cache to the data storage device; in a case where the metadata of the logical volume has been written from the cache to the data storage device, initiating a request for changing the state of the metadata as the clean state, to cause a control end of a state machine to trigger the state machine to run, and initiate a task of changing the state of the metadata as the clean state; and executing the task, and marking the state of the metadata of the logical volume as the clean state (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).
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), further in view of Peltz et al. (US 2020/0226038; hereinafter Peltz).
Regarding claim 17, Pawar and Warszawski do not expressly teach reading a logical partition space of the logical volume in a physical disk, and reconstructing the forward metadata using backward metadata.
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 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.
Claims 9-10 and 18 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), further in view of Lv et al. (US 2021/0303196; hereinafter Lv).
Regarding claim 9, in view of Warszawski, Pawar further teaches
wherein the writing, into a superblock of a header of the logical volume, a root node address of a tree structure where the metadata is located comprises: (Pawar Fig. 3 and col. 9, ll. 40-50 discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks. This hierarchy forms a tree-structured metadata organization rooted at top-level directory; col. 1, line 59 to col. 2, line 7 discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks;
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))
Pawar and Warszawski do not expressly teach B+ tree, In an analogous art of data recovery, Lv teaches writing, into the superblock of the header of the logical volume, a root node address of a B+ tree where the metadata is located ([0042], A single B+ tree node journal entry is represented as a header and a list of bkeys, where the bkeys are sequentially contiguous in a memory; [0081]-[0083], The journal is written into a ring buffer of the bucket, which is retained in the superblock)
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 and Lv before them, to incorporate Lv’s B+ tree for the motivation that Metadata write is always strictly ordered, such that the B+ tree and all other contents are maintained consistent on the solid state disk in the case of abnormal shutdown (Lv [0081]).
Regarding claim 10, the combination of Pawar, Warszawski and Lv further teaches
wherein writing, into the superblock of the header of the logical volume, a root node address of a B+ tree where the metadata is located comprises:
in a case where, within a timing period, there is no user-accessible data dispatched for the logical volume and all modified metadata has been written from the cache to the data storage device (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), i.e., not active; that is, all changes to metadata for which transaction entries have been recorded to transaction log 726 have been written in place in the file system 725. File system is dirty otherwise; i.e., if at least one transaction log sector is active; that is, if at least one metadata change for which transaction entries have been recorded to transaction log 726 have not been written in place in the file system 725”), determining that all nodes of the B+ tree are in the clean state, wherein in a case where there is data to be written, a corresponding node on the B+ tree becomes a dirty state; and marking, in the superblock of the logical volume, the state of the metadata of the logical volume as the clean state, and writing the root node address of the B+ tree (Lv, Fig. 4; [0084]-[0085], A dirty journal entry is a journal entry including a B+ tree update that has not yet been written to the B+ tree on the solid state disk;
Pawar col. 1, line 59 to col. 2, line 7 discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks. This hierarchy forms a B+ tree-structured metadata organization rooted at top-level directory;
col. 2, ll. 29-38, Data and metadata of a file cached in the volatile memory is written to the disk at intervals or in response to an event, as determined by an operating system of the data storage system, which often is referred to as “flushing of a cache. Flushing of a cache may be triggered at a determinate time interval. Caching data and metadata of a file of a file system in a volatile memory improves performance of the file system as accessing data from a disk involves an I/O operation to a disk which is slower than accessing data from the volatile memory. Fig. 11 shows the claimed condition, where all metadata changes have been written, the metadata structure becomes clean.
col. 20, ll. 54-67, “ 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), i.e., not active; that is, all changes to metadata for which transaction entries have been recorded to transaction log 726 have been written in place in the file system 725. File system is dirty otherwise; i.e., if at least one transaction log sector is active; that is, if at least one metadata change for which transaction entries have been recorded to transaction log 726 have not been written in place in the file system 725).
Regarding claim 18, in view of Warszawski, Pawar 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 changed to be modified and cause the tree structure to be in the dirty state (col. 20, ll. 54-67, “ 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), i.e., not active; that is, all changes to metadata for which transaction entries have been recorded to transaction log 726 have been written in place in the file system 725. File system is dirty otherwise; i.e., if at least one transaction log sector is active; that is, if at least one metadata change for which transaction entries have been recorded to transaction log 726 have not been written in place in the file system 725;
Pawar in col. 9, ll. 40-50 discloses hierarchical metadata structure including: directory hierarchy, inodes, indirect blocks, data blocks. This hierarchy forms a tree-structured metadata organization rooted at top-level directory;
Pawar, 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. 30-31, “Cached disk array 19 may include any of: multiple disk drives, a high-speed random-access cache memory, and a logical-to-physical mapping {forward metadata} between the cache memory and the disk drives”).
Pawar and Warszawski does not expressly teach In an analogous art of data recovery, Lv teaches cause at least one node of the tree structure to be changed to be modified and cause the tree structure to be in the dirty state (
[0048], [0084] A dirty journal entry is a journal entry including a B+ tree update that has not yet been written to the B+ tree on the solid state disk; [0081]-[0082], Metadata write is always strictly ordered, such that the B+ tree and all other contents are maintained consistent on the solid state disk in the case of abnormal shutdown … The journal is a logical journal, and is a list of insertions (bkeys) to reinsert on recovery in an order of their presences in the journal. Provided every index update is journaled, redoing these insertions is an idempotant operation. Keys appear in the journal in the same order as the order of insertions, so that both are done under write locks of the B+ tree nodes)
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 and Lv before them, to incorporate Lv’s B+ tree for the motivation that Metadata write is always strictly ordered, such that the B+ tree and all other contents are maintained consistent on the solid state disk in the case of abnormal shutdown (Lv [0081]).
Conclusion
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