FILE SYSTEM OPERATIONS IN STORAGE DEVICES

Abstract

Computer system (500) comprising: a processor (502); and a machine-readable memory (505) that stores instructions, wherein the instructions can be executed by the processor (502) to: check (510) a block-level input / output, hereinafter referred to as I / O, request (410) to be performed by a block-based storage device; determine whether the block-level I / O request (410) contains at least one file system operation; in response to the determination that the block-level I / O request (410) contains a file system operation, create a copy of the block-level I / O request (410); parse the copy of the block-level I / O request (410) to extract a variety of attributes of the file system operation (540), wherein the parsing of the copy of the block-level I / O request (410) is asynchronous to an execution of the block-level I / O request (410) by the block-based storage device;and storing (550) the extracted plurality of attributes of the file system operation in an entry of a file system operation database, wherein each entry of the file system operation database stores a set of attributes for a file system stored on the block-based storage device with another file system operation, wherein each entry in the file system operation database contains a timestamp for the file system operation associated with the entry.;

Description

background

[0001] Computing devices may include components such as a processor, memory, a caching system, and a storage device. The storage device may be a hard disk drive, which uses a magnetic medium to store and retrieve blocks of data. Some storage systems can transfer data between different locations or devices. For example, some systems can transfer and store copies of important data for archiving and recovery purposes. Brief description of the drawings

[0002] Some embodiments are described using the following figures. Fig. are schematic representations of an example computer system according to some implementations. The Fig. show example data structures in accordance with some implementations. Fig. is an illustration of a sample process in accordance with some implementations. Fig. are illustrations of example operations in accordance with some implementations. Fig. is a schematic diagram of an example computing device according to some implementations. Fig. is an illustration of a sample process in accordance with some implementations. Fig. is a diagram of a machine-readable medium that stores instructions in accordance with some implementations.

[0003] In the drawings, identical reference numbers indicate similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated to clarify the example shown. Furthermore, the drawings contain examples and / or embodiments consistent with the description; however, the description is not limited to the examples and / or embodiments shown in the drawings. Detailed description

[0004] In this disclosure, the use of the term "a," "an," or "the" includes the plural forms unless the context clearly indicates otherwise. Likewise, the term "comprises," "including," "comprises," "includes," "has," or "have," when used in this disclosure, specifies the presence of the specified elements but does not preclude the presence or addition of other elements.

[0005] In some examples, a computer system may permanently store data in one or more storage devices. For example, a server may store a data collection on a local storage array and also store a backup copy of the data collection on a remote backup device. In some examples, the backup copy may be stored in a different form than the data collection. For example, the backup copy may include a deduplicated representation of the data collection. As used herein, the term "storage system" may include a storage device or an array of storage devices. A storage system may also include one or more storage controllers that manage access to the storage device(s). A "unit of data" may refer to any piece of data that can be separately identified in the storage system.In some cases, a unit of data may refer to a chunk, a collection of chunks, or another piece of data. In some examples, a storage system may store units of data in persistent memory. Persistent storage may be performed using one or more persistent (e.g., non-volatile) storage devices, such as disk-based storage devices (e.g., hard disk drives (HDDs)), solid-state devices (SSDs) such as flash memory devices, or the like, or a combination thereof. As used herein, a "controller" may refer to hardware processing circuitry, which may include any one or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or other hardware processing circuitry.Alternatively, a “controller” may refer to a combination of hardware processing circuitry and machine-readable instructions (software and / or firmware) executable on the hardware processing circuitry.

[0006] In some examples, a collection of data may be specified in the form of one or more elements of a file system. As used herein, a "file system" is a system for organizing data stored on a storage device. For example, a file system may comprise a collection of data files stored in a hierarchy of directories (e.g., with a root directory and one or more levels of subdirectories). To present the data as a collection of data files and directories, the file system may maintain structures of metadata. The term "metadata," in the context of a file system, refers to information that describes volumes, files, and directories, but that is not part of the stored data files.For example, the following information describes a data file and is considered part of the file's metadata: file name, file size, creation time, last access / write time, user ID, and block pointers that point to the file's actual data on a storage device. The information elements that make up a directory's metadata primarily include names and references to data files and subdirectories contained within the directory. The term "file system operation" as used here can refer to an operation to modify the elements of a file system (e.g., files and directories). A file system operation can include, for example, adding a file system item, deleting a file system item, modifying a file system item, and so on.

[0007] In some examples, a collection of data may be stored in a block-based storage device. As used herein, the term "block-based" storage device may refer to a device that stores data at a block level. In the examples described here, the term "block level" refers to a data storage level that is below a file and directory level. In such examples, a block level may be a level at which a block-based storage device (e.g., a hard disk drive (HDD), a solid-state drive (SSD), or the like) or a virtual volume may store data, and a level at which files and directories are implemented by a file system. The block-based storage device may receive the data blocks that comprise a data collection as a stream of data blocks.

[0008] In some examples, a block-based storage device may store a file system in the form of data blocks. Furthermore, different types of data blocks (e.g., including both file data and file system metadata) may be stored in different parts or locations of the block-based storage device. For example, with a New Technology File System (NTFS) file system, the data blocks, including file system metadata, may be stored in an MFT (Master File Table) of the block-based storage device, while the data blocks, including file data, may be stored in a different part of the block-based storage device.

[0009] In some examples, a file system operation can be performed by sending one or more block-level input / output (I / O) requests to a block-based storage device. The block-based storage device can perform the block-level I / O requests but may not have visibility into the file system operation itself. For example, if the file system operation is to move a data file to a new directory, the block-based storage device can receive a block-level I / O request to modify the data blocks, including the corresponding metadata (for example, the metadata that records the current location of the data file). However, in this example, the block-based storage device cannot parse a file system operation embedded in the block-level I / O request and therefore may not have visibility into the movement of the data file to the new directory.Identifying changes to the file system that have occurred at different points in time may therefore require periodic processing to parse and analyze the entire file system, which may negatively impact the performance of the block-based storage device.

[0010] According to some implementations of the present disclosure, a controller may examine a block-level I / O request sent to a block-based storage device and determine whether the block-level I / O request contains a file system operation. If the block-level I / O request is determined to contain a file system operation, the block-level I / O request is copied to a queue. The controller may remove the copy of the block-level I / O request from the queue asynchronously with the execution of the block-level I / O request. Furthermore, the control unit may analyze the copy of the block-level I / O request to extract details of the contained file system operation. The controller may then incorporate the extracted information into a database of file system changes. The database may then be queried to identify specific changes to the file system.For example, the database can be queried to determine when a particular file was modified, to quickly detect mass changes to multiple files (e.g., as an indication of a malware attack), and so on. This allows the database to reveal changes in the file system without requiring repeated programming to analyze the entire file system, potentially improving the performance of block-based storage. Various aspects of the disclosed technique are discussed below with reference to the . Fig. . FIG. 1A-1B - Example system

[0011] Fig. shows an example system 100 in accordance with some implementations. As illustrated, the example system 100 may include a source system 110, a block-level storage device 120, and a file system operating system (FSO) 130. The source system 110 may be a physical computing device (e.g., server, appliance, desktop, etc.), a virtual computing device (e.g., virtual machine, container, etc.), and so on. Furthermore, the block-level storage device 120 may be, in whole or in part, a local storage device, a memory device, a storage array, a remote storage service, etc. In some implementations, the source system 110 and the block-level storage device 120 may be implemented in different devices and / or locations. However, in other implementations, the source system 110 and the block-level storage device 120 may be implemented in a single device and / or system (e.g., a server, a server rack, etc.).

[0012] In some implementations, block-level storage device 120 may store data blocks in deduplicated form. For example, a storage controller may perform deduplication operations, including comparing fingerprints of the incoming data blocks with fingerprints of the stored data blocks. As used herein, the term "fingerprint" refers to a value derived by applying a function to the contents of the data block (where the "contents" may include all or a subset of the contents of the data block). An example of a function that may be applied is a hash function that generates a hash value based on the incoming data block. Examples of hash functions include cryptographic hash functions such as the Secure Hash Algorithm 2 (SHA-2) hash functions, e.g., SHA-224, SHA-256, SHA-384, etc.In other examples, other types of hash functions or other types of fingerprint functions may also be used.

[0013] In some implementations, block-based storage device 120 may store a file system 125 in the form of data blocks. Furthermore, in some implementations, different types of data blocks of file system 125 may be stored in different parts or regions of block-based storage device 120. Fig. shows an example of a memory allocation 121. The memory allocation 121 may illustrate the manner in which the file system 125 allocates the memory space in the block-based storage device 120 (shown in Fig. can use. In some implementations, the storage allocation 121 may include a metadata area 122 and a file data area 124. The data area 124 may store file system data (i.e., the data contents of files in the file system). The metadata area 122 may contain data blocks that store file system metadata (i.e., metadata about files and directories in the file system). For example, if the file system 125 is a New Technology File System (NTFS), the metadata area 122 may be implemented as a Master File Table (MFT) of the block-based storage device 120. In another example, if the file system 125 is an Extended File System (EXT), the metadata area 122 may be implemented as an index node ("inode") table of the block-based storage device 120. Although Fig. shows an exemplary memory allocation 121 that includes only one metadata region 122 and one file data region 124. Implementations are not limited in this regard. For example, in some implementations, the memory allocation 121 may include multiple metadata regions 122 and multiple file data regions 124 (e.g., at specific locations). In some implementations, the location of the metadata region(s) 122 (e.g., MFT, inode table, etc.) may be determined by an initial scan of the block-based storage device 120 and permanently stored in a data structure included in the block-based storage device 120.

[0014] Referring again to Fig. Source system 110 may send block-level I / O requests to block storage device 120. In some implementations, a block-level I / O request may include a file system operation to be performed on file system 125. As used herein, a block-level I / O request may be referred to as "including" a file system operation if the block-level I / O request is to modify data blocks to perform the file system operation. For example, if a particular file system operation is to move a data file within file system 125 (e.g., to a different directory), source system 110 may submit a particular block-level I / O request to modify the data blocks that store metadata recording the location of the data file.Accordingly, the particular block-level I / O request can be described here as including the particular file system operation.

[0015] In some implementations, the FSO system 130 may include an FSO filter 140, an FSO queue 150, an FSO parser 160, and an FSO database 170. One or more components of the FSO system 130 (e.g., FSO filter 140, FSO parser 160) may be implemented as a processor that executes instructions (e.g., software and / or firmware) stored in a machine-readable storage medium, hardware (e.g., circuitry), etc. Furthermore, the FSO queue 150 and the FSO database 170 may be implemented using non-transitory storage media (e.g., hard disk drives, solid-state drives), semiconductor memory (e.g., random-access memory), etc. In some implementations, some or all components of the BFS system 130 may be implemented in a replication driver, a replication application, or a combination thereof.In other implementations, some or all components of the FSO system 130 may be located in a storage controller of the source system 110, the block-level storage device 120, or another device or system (in . Fig. not shown) must be implemented.

[0016] In some implementations, the BFS filter 140 may read or "sniff" a block-level I / O request transmitted from the source system 110 to the block storage device 120. The BFS filter 140 may read and evaluate a relatively small portion (e.g., less than 20%) of the block-level I / O request to determine whether the block-level I / O request contains a file system operation. In some implementations, the portion (evaluated by the FSO filter 140) may be a single field or string located at a specific location (e.g., offset and length) within the block-level I / O request. For example, the BFS filter 140 may determine whether a prefix (e.g., the leading N characters, where N is an integer) of the block-level I / O request matches a predefined string (e.g., "FILE") used by commands to write or modify the file system metadata.In another example, the BFS filter 140 may read a destination address at a predefined offset and length within the block-level I / O request and determine whether the destination address matches an address range reserved or specified for storing file metadata (e.g., the address range specified in . Fig. shown metadata region 122).

[0017] If the FSO filter 140 indicates that the block-level I / O request contains a file system operation, in some implementations, a copy of the block-level I / O request (also referred to herein as a "copy of the I / O request") may be stored in the FSO queue 150. Furthermore, the original block-level I / O request (i.e., not the copy of the I / O request added to the BFS queue 150) is transferred to the block storage device 120 and then executed by the block storage device 120. In other words, the BFS queue 150 is separate from and outside the execution path of the block-level I / O request (i.e., from the block storage device 120). The BFS queue 150 may store multiple I / O request copies (i.e., block-level copies of different I / O requests identified by the BFS filter 140) for later processing by the BFS parser 160.An example implementation of the BFS queue 150 is described below with reference to FIG. Fig. described.

[0018] In some implementations, in response to a trigger event, the BFS parser 160 may dequeue one of the I / O request copies from the BFS queue 150 and parse the dequeued I / O request copy. The trigger event may be asynchronous to the execution of the block-level I / O request by the block storage device 120. For example, the trigger event for the BFS parser 160 may include a determination that the available processing bandwidth of the BFS system 130 exceeds a threshold (e.g., an indication that a processor of the BFS system 130 is currently idle or has a relatively light workload). In another example, the trigger event may include a determination that the BFS queue 150 is full to a predefined level (e.g., a maximum number of I / O request copies in the queue).Other examples of the trigger event for the FSO parser 160 are possible. In the examples described here, the BFS parser 160 (which is separate from the block storage device 120) may parse an I / O request copy as operation(s) that are separate from and asynchronous to the block-level execution of the I / O request by the block storage device 120.

[0019] In some implementations, the BFS parser 160 may parse ( ) the queued I / O request copy to extract details of the embedded file system operation. For example, the BFS parser 160 may read part or all of the I / O request copy to find multiple delimiters and may use the multiple delimiters to extract multiple data fields from the I / O request copy. Furthermore, in some examples, the BFS parser 160 may parse a relatively large portion (e.g., more than 50%) of the queued I / O request copy. In some implementations, the extracted file system operation details may be used to populate an entry in the FSO database 170 that represents that particular file system operation. An example implementation of the BFS database 170 is described below with reference to Fig. described.

[0020] In some implementations, the BFS database 170 may be queried to obtain information about changes to the file system 125. For example, the BFS database 170 may be queried to determine the number of files modified in a specific time period. If the number of modified files is determined to exceed a predefined threshold, an alert may be triggered to indicate that the file system 125 may be affected by a malware attack (e.g., a ransomware attack attempting to encrypt all files). In another example, the BFS database 170 may be queried to determine the time period in which a particular file was last modified. Other examples are possible.In this way, the BFS database 170 can be used to detect changes to the file system 125 without having to analyze the entire file system 125 through repeated programming operations. Note that in . Fig. Although an example implementation is shown in which the BFS database 170 is integrated into the BFS system 130, other implementations are also possible. For example, it is conceivable that the BFS database 170 may be located in the source system 110, in the block-level storage device 120, in an external system, or at an external location (in Fig. not shown) or any combination thereof. FIG. 2A-2B - Example data structures

[0021] Fig. shows an illustration of an example file system operation (FSO) queue 210 corresponding to some implementations. The FSO queue 210 may generally correspond to an example implementation of the FSO queue 150 (shown in Fig. In some implementations, the FSO queue 210 may temporarily store copies of multiple block-level I / O requests for later analysis (e.g., by the Fig. Each I / O request may be copied and stored in the BFS queue 210 if it is determined that the I / O request contains a file system operation (e.g., by the Fig. BFS filter 140 shown). In some implementations, BFS queue 210 may store the I / O request copies in the order they arrived (i.e., as they were added to BFS queue 210). Further, I / O request copies may be removed from the queue in the order they were added to FSO queue 210 (e.g., by removing the oldest I / O request copy in FSO queue 210).

[0022] Fig. shows an illustration of an example BFS database 220 according to some implementations. The BFS database 220 may generally correspond to an example implementation of the BFS database 170 (illustrated in Fig. In some implementations, the BFS database 220 may store information about file system (BFS) operations performed in a block-based storage system (e.g., the one described in Fig. illustrated storage system 100). The BFS database 220 may, for example, contain a table consisting of multiple rows, each row corresponding to a different BFS. Furthermore, each row may contain multiple columns, each column representing a different attribute (ie, a parameter) of the BFS. As shown in Fig. For example, as shown, each row may contain a "BFS ID" column (i.e., an attribute) to capture a unique identifier for the BFS, and an "Item" column to identify a specific file system item (or items) affected by the BFS. Furthermore, each row may contain a "Type" column to capture the type of BFS. For example, the "Type" column may contain a file creation FSO, a directory creation FSO, a file / directory modification FSO (e.g., rename, move, edit, etc.), a file / directory deletion FSO, etc. In addition, each row may contain a "Time" column to record the creation time for the row and a "Parent" column to record the parents of the FSO item (e.g., identified by the "Item" column). Note that the BFS database 220 in Fig. Although it is represented as a row table, other data structures are also possible. For example, the BFS database 220 can be implemented as delimited text files (e.g., key-value pairs), stored as Extensible Markup Language (XML) files, structured text, delimited text, etc., hard-coded as program instructions, and so on.

[0023] In some implementations, the BFS database 220 can be queried to identify specific changes to a file system. For example, the BFS database 220 can be queried to determine when a specific file was modified, to quickly detect mass changes (e.g., encryptions or deletions) to multiple files as a result of a malware attack, etc. In this way, the BFS database 220 can make changes in the file system visible without requiring repetitive programming to analyze the entire file system, which can improve the performance of block-based storage.

[0024] In some implementations, the BFS database 220 can be queried to determine the full address path of each data file. As in Fig. For example, as shown, "File2" is contained in "Directory6," which in turn is contained in "Directory1." Accordingly, the BFS database 220 may be queried to determine the address path "C:\Directory1\Directory6\File2." Further, the BFS database 220 may be updated to store the complete address paths determined for each data file. FIGS. 3 and 4A-4C - Example procedures for collecting file system operating data

[0025] Fig. shows an example process 300 for collecting file system operating data in accordance with some implementations. In some examples, the process 300 may be implemented using the file system operating system (FSO) 130 (shown in Fig. which may be separate from the block-level storage device 120. The process 300 may be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by one or more processors). The machine-readable instructions may be stored in a non-transitory, computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc. For illustrative purposes, the details of the method 300 are described below with reference to Fig. which show some example implementations. However, other implementations are also possible.

[0026] Block 310 may include the block-level verification of an I / O request to be executed by a storage device. For example, the BFS filter 140 (see Fig. a block-level I / O request transmitted from the source system 110 to the block-level storage device 120. In some implementations, the BFS filter 140 reads a single string at a specific location (e.g., offset and length) within the block-level I / O request (e.g., a prefix of the block-level I / O request, a destination address of the block-level I / O request, etc.).

[0027] At decision block 320, it may be determined whether the block-level I / O request contains a file system operation (FSO). If not ("NO"), the process 300 may return to block 310 (i.e., check for another block-level I / O request). Otherwise, if at decision block 320 it is determined that the block-level I / O request contains an I / O operation ("YES"), the process 300 may proceed to block 330, including inserting the block-level I / O request into an I / O queue that is outside of any execution path of the block-level I / O request. For example, see Fig. , the BFS filter 140 reads a prefix of a block-level I / O request 410 and compares the prefix with the "FILE" command flag used for BFS. Accordingly, the BFS filter 140 determines that the block-level I / O request 410 contains a BFS and then loads the block-level I / O request 410 into the BFS queue 150. In another example, relating to the Fig. , the BFS filter 140 reads a destination address (e.g., with a specific offset and length) of the block-level I / O request 410 and compares the destination address with a predefined metadata address range (e.g., the one defined in Fig. metadata area 122 shown). Accordingly, the BFS filter 140 determines that the block-level I / O request 410 contains a BFS and then loads the block-level I / O request 410 into the BFS queue 150.

[0028] In block 340, the block-level I / O request may be removed from the BFS queue asynchronously to an execution of the block-level I / O request. For example, see Fig. BFS parser 160 dequeues block I / O request 410 from BFS queue 150 in response to a trigger event (e.g., upon determining that a controller of BFS system 130 has a relatively light workload). In some implementations, the trigger event may be asynchronous to the execution of the block-level I / O request by block storage device 120. Accordingly, BFS parser 160 (which is separate from block storage device 120) may parse an I / O request copy as operation(s) separate from, and in addition to, the execution of the block-level I / O request by block storage device 120.

[0029] Block 350 may include parsing the block-level I / O request to extract a set of block-level I / O request attributes. Block 360 may include creating a new entry in a BFS database using the extracted attribute set. After block 360, the process 300 may return to block 310 (i.e., to examine another block-level I / O request). For example, with respect to Fig. , the BFS parser 160 reads part or all of the block-level I / O request 410 to locate multiple delimiters and may use the multiple delimiters to extract a set of data fields 430 from the copy of the I / O request. The extracted set of data fields 430 is inserted into an entry of the BFS database 170 representing the BFS embedded in the block-level I / O request 410. FIG. 5 - Example of a data processing system

[0030] Fig. shows a schematic diagram of an example computing device 500. In some examples, the computing device 500 may generally correspond to a portion or all of the file system operating system (FSO) 130 (illustrated in Fig. which may be separate from block storage device 120. As illustrated, computing device 500 may include a hardware processor 502 and a machine-readable memory 505 with instructions 510-550. Machine-readable memory 505 may be a non-transferable medium. Instructions 510-550 may be executed by hardware processor 502 or by a processing engine included in hardware processor 502.

[0031] Instruction 510 may be executed to examine a block-level I / O request to be executed by a block-based storage device. Instruction 520 may be executed to determine whether the block-level I / O request contains at least one file system operation. For example, BFS filter 140 examines a block-level I / O request transmitted from source system 110 to block-based storage device 120 (see Fig. In some implementations, the BFS filter 140 reads a single string at a specific location (e.g., offset and length) within the block-level I / O request.

[0032] Instruction 530 may be executed to create a block-level copy of the I / O request in response to determining that the block-level I / O request contains a file system operation. For example, see Fig. , the BFS filter 140 reads a prefix of a block-level I / O request 410 and compares the prefix with the command flag "FILE" used for BFS. Accordingly, the BFS filter 140 determines that the block-level I / O request 410 contains a BFS and then loads the block-level I / O request 410 into the BFS queue 150. In another example, relating to the Fig. , the BFS filter 140 reads a destination address (e.g., with a specific offset and length) of the block-level I / O request 410 and compares the destination address with a predefined metadata address range (e.g., the one defined in Fig. metadata area 122 shown). Accordingly, the BFS filter 140 determines that the block-level I / O request 410 contains a BFS and then loads the block-level I / O request 410 into the BFS queue 150.

[0033] Instruction 540 may be executed to analyze the block-level copy of the I / O request to extract a variety of attributes of the file system operation, wherein analyzing the block-level copy of the I / O request is performed separately from and asynchronously with an execution of the block-level I / O request by the block-based storage device. For example, with respect to Fig. , the BFS parser 160 dequeues the block-level I / O request 410 from the BFS queue 150 in response to a trigger event and analyzes a relatively large portion (e.g., more than 50%) of the dequeued I / O request copy to extract details of the embedded file system operation. For example, the BFS parser 160 may read part or all of the copy of the I / O request to locate multiple delimiters and use the multiple delimiters to extract multiple data fields from the copy of the I / O request.

[0034] Instruction 550 may be executed to store the extracted plurality of attributes of the file system operation in an entry of a file system operation database, wherein each entry of the file system operation database is associated with a different file system operation in a file system stored on the block-based storage device. For example, referring to the Fig. , the BFS parser 160 uses the data fields (extracted from the copy of the I / O request) to populate a BFS database 170 entry representing the file system operation. FIG. 6 - Process example

[0035] Fig. shows an example process 600 for collecting file system operating data in accordance with some implementations. In some examples, the process 600 may be executed using the file system operating system (FSO) 130 (shown in Fig. that may be separate from block-level storage device 120. Process 600 may be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by one or more processors). The machine-readable instructions may be stored in a non-transitory, computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0036] Block 610 may involve a storage system controller examining a block-level input / output (I / O) request to be executed by a block-based storage device. Block 620 may involve the controller determining whether the block-level I / O request includes at least one file system operation. Block 630 may include, in response to determining that the block-level I / O request includes a file system operation, the controller creating a copy of the block-level I / O request.

[0037] Block 640 may include the controller parsing the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein the parsing of the copy of the block-level I / O request occurs separately from and asynchronously with an execution of the block-level I / O request by the block-based storage device. Block 650 may include the controller storing the extracted plurality of attributes of the file system operation in an entry of a file system operations database, wherein each entry of the file system operations database is associated with a different file system operation in a file system stored on the block-based storage device. FIG. 7 - Example of a machine-readable medium

[0038] Fig. shows a machine-readable medium 700 on which instructions 710-750 are stored, in accordance with some implementations. The instructions 710-750 may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc., which may be separated from a block-level storage device to perform block-level I / O requests as described herein. The machine-readable medium 700 may be a non-transitory storage medium, such as an optical, semiconductor, or magnetic storage medium.

[0039] Instruction 710 may be executed to examine a block-level I / O request to be executed by a block-based storage device. Instruction 720 may be executed to determine whether the block-level I / O request contains at least one file system operation. Instruction 730 may be executed to create a copy of the block-level I / O request in response to determining that the block-level I / O request contains a file system operation.

[0040] Instruction 740 may be executed to analyze the block-level copy of the I / O request to extract a plurality of attributes of the file system operation, wherein analyzing the block-level copy of the I / O request occurs asynchronously with an execution of the block-level I / O request by the block-based storage device. Instruction 750 may be executed to store the extracted plurality of attributes of the file system operation in an entry of a file system operations database, wherein each entry of the file system operations database is associated with a different file system operation in a file system stored on the block-based storage device.

[0041] In accordance with some implementations described herein, a controller may examine a block-level I / O request sent to a block-based storage device and determine whether the block-level I / O request contains a file system operation. If the block-level I / O request is determined to contain a file system operation, the block-level I / O request is copied to a queue. The controller may remove the copy of the block-level I / O request from the queue asynchronously with the execution of the block-level I / O request. In addition, the control unit may analyze the copy of the block-level I / O request to extract details of the contained file system operation. The controller may then incorporate the extracted information into a file system change database. The database may then be queried to identify specific changes to the file system.This allows the database to make changes in the file system visible without having to repeatedly program and analyze the entire file system, which can improve the performance of block-based storage.

[0042] Please note that the Fig. As various examples show, implementations are not limited in this respect. For example, the system 100 as shown in Fig. illustrated, may include additional devices and / or components, fewer components, different components, different arrangements, etc. Another example is that the functionality of the FSO system 130 described above may be included in another machine or software of the system 100. Other combinations and / or variations are also possible.

[0043] Data and instructions are stored in corresponding storage devices embodied as one or more computer-readable or machine-readable storage media. Storage media includes various forms of non-transitory memory, including semiconductor memory such as dynamic or static random-access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs), and flash memory; magnetic disks such as fixed, floppy, and removable disks; other magnetic media including tapes; optical media such as compact discs (CDs) or digital video discs (DVDs), or other types of storage devices.

[0044] It should be noted that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed throughout a large system, possibly with multiple nodes. Such computer-readable or machine-readable storage medium or media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to each individual component manufactured, or to multiple components. The storage medium or media may be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions may be downloaded over a network for execution.

[0045] In the foregoing description, numerous details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details described above. The appended claims are intended to cover such modifications and variations.

Claims

[1] Computer system comprising: a processor; and a machine-readable memory that stores instructions, the instructions being executable by the processor to: verify a block-level input / output (I / O) request to be performed by a block-based storage device; determine whether the block-level I / O request contains at least one file system operation; in response to determining that the block-level I / O request contains a file system operation, create a copy of the block-level I / O request; Analyzing the block-level copy of the I / O request to extract a plurality of attributes of the file system operation, wherein analyzing the block-level copy of the I / O request is asynchronous to an execution of the block-level I / O request by the block-based storage device; and Storing the extracted plurality of attributes of the file system operation in an entry of a file system operation database, wherein each entry of the file system operation database is associated with a different file system operation in a file system stored on the block-based storage device. [2] A computer system according to claim 1, including instructions executable by the processor to: determine whether a block-level I / O request prefix matches a first text string associated with the file system operation; and in response to determining that the prefix of the block-level I / O request matches the first text string, determine that the block-level I / O request contains the file system operation. [3] A computer system according to claim 1, including instructions executable by the processor to: Determining a first memory location specified in the block-level I / O request; and in response to determining that the first memory location overlaps with a metadata address range of the block-based storage device, determine that the block-level I / O request contains the file system operation. [4] A computer system according to claim 1, including instructions executable by the processor to, prior to parsing the block-level I / O request: store the block-level copy of the I / O request in a queue; and dequeue the block-level I / O request in response to detecting a trigger event, where the trigger event is asynchronous to the execution of the block-level I / O request. [5] The computer system of claim 4, wherein the triggering event is a determination that an available processing bandwidth of the computing device exceeds a threshold. [6] The computer system of claim 4, wherein the trigger event is a determination that the queue is filled to a predefined level. [7] The computer system of claim 1, wherein the file system operation is an operation selected from a file creation operation, a file modification operation, and a file deletion operation. [8] The computer system of claim 1, wherein the plurality of attributes comprise an item identifier, a file system operation type, and a file system operation timestamp. [9] Non-transitory machine-readable medium that stores instructions that, when executed, cause a processor to: verify a block-level input / output (I / O) request to be performed by a block-based storage device; determine whether the block-level I / O request contains at least one file system operation; in response to determining that the block-level I / O request contains a file system operation, create a copy of the block-level I / O request; Analyzing the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein analyzing the copy of the block-level I / O request is performed asynchronously to an execution of the block-level I / O request by the block-based storage device; and Storing the extracted plurality of attributes of the file system operation in an entry of a file system operation database, wherein each entry of the file system operation database is associated with a different file system operation in a file system stored on the block-based storage device. [10] The non-transitory machine-readable medium of claim 9, including instructions that, when executed, cause the processor to: determine whether a block-level I / O request prefix matches a first text string associated with the file system operation; and in response to determining that the prefix of the block-level I / O request matches the first text string, determine that the block-level I / O request contains the file system operation. [11] The non-transitory machine-readable medium of claim 9, including instructions that, when executed, cause the processor to: Determining a first memory location specified in the block-level I / O request; and in response to determining that the first memory location overlaps with a metadata address range of the block-based storage device, determine that the block-level I / O request contains the file system operation. [12] The non-transitory machine-readable medium of claim 9, including instructions that, when executed, cause the processor, prior to parsing the block-level I / O request: store the block-level copy of the I / O request in a queue; and dequeue the block-level I / O request in response to detecting a trigger event, where the trigger event is asynchronous to the execution of the block-level I / O request. [13] The non-transitory machine-readable medium of claim 12, wherein the triggering event is a determination that an available processing bandwidth of the computing device exceeds a threshold. [14] The non-transitory machine-readable medium of claim 9, wherein the file system operation is one selected from a file creation operation, a file modification operation, and a file deletion operation. [15] Procedure comprising: Verification of a block-level input / output (I / O) request to be performed by a block-based storage device by a storage system controller; Determination by the controller whether the block-level I / O request contains at least one file system operation; in response to determining that the block-level I / O request contains a file system operation, the controller creating a copy of the block-level I / O request; analyzing the copy of the block-level I / O request by the controller to extract a plurality of attributes of the file system operation, wherein analyzing the copy of the block-level I / O request is asynchronous to an execution of the block-level I / O request by the block-based storage device; and Storing, by the controller, the extracted plurality of attributes of the file system operation in an entry of a file system operation database, wherein each entry of the file system operation database is associated with a different file system operation in a file system stored on the block-based storage device. [16] A method according to claim 15, comprising: Determining whether a prefix of the block-level I / O request matches a first text string associated with the file system operation; and in response to determining that the prefix of the block-level I / O request matches the first text string, determining that the block-level I / O request contains the file system operation. [17] A method according to claim 15, comprising: Determining a first memory location specified in the block-level I / O request; and in response to determining that the first memory location overlaps with a metadata address range of the block-based storage device, determining that the block-level I / O request contains the file system operation. [18] The method of claim 15, comprising, prior to parsing the block-level I / O request: Storing the block-level copy of the I / O request in a queue; and Dequeue the block-level I / O request in response to detecting a trigger event, where the trigger event is asynchronous to the execution of the block-level I / O request. [19] The method of claim 18, wherein the triggering event is a determination that an available processing bandwidth of the computing device exceeds a threshold. [20] The method of claim 15, wherein the file system operation is an operation selected from an operation for creating a file, an operation for modifying a file, and an operation for deleting a file.

Images