File system operation in storage device

Abstract

The invention relates to file system operation in a storage device. Example implementations relate to data storage. One example includes checking a block-level input / output (I / O) request to be executed by a block-based storage device; and in response to determining that the block-level I / O request includes the file system operation, generating a copy of the block-level I / O request. The example also includes parsing a copy of the block-level I / O request to extract a plurality of attributes of the file system operation, where parsing is asynchronous with execution of the block-level I / O request by the block-based storage device. The example also includes storing the extracted plurality of attributes of the file system operations in entries of a file system operation database, where each entry of the file system operation database is associated with a different file system operation in the file system stored on the block-based storage device.

Description

Background Art

[0001] Computing devices may include components such as processors, memory, cache systems, and storage devices. Storage devices may include hard disk drives that use magnetic media to store and retrieve blocks of data. Some storage systems can transfer data between different locations or devices. For example, some systems may transfer and store copies of important data for archiving and recovery purposes. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some embodiments are described with respect to the following figures.

[0003] Figure 1A to Figure 1B is a schematic diagram of an example computing system in accordance with some implementations.

[0004] FIG. 2A to FIG. 2B is an illustration of an example data structure according to some implementations.

[0005] Figure 3 is an illustration of an example process according to some implementations.

[0006] FIG. 4A to FIG. 4C is an illustration of example operations according to some implementations.

[0007] Figure 5 is a schematic diagram of an example computing device in accordance with some implementations.

[0008] Figure 6 is an illustration of an example process according to some implementations.

[0009] Figure 7 is a diagram of an example machine-readable medium having instructions stored thereon, according to some implementations.

[0010] Throughout the drawings, the same reference numerals refer to similar, but not necessarily identical, elements. The drawings are not necessarily drawn to scale, and the dimensions of some parts may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0011] In the present disclosure, the use of the terms "a", "an" or "the" is intended to include the plural forms as well, unless the context clearly indicates otherwise. Likewise, when used in the present disclosure, the terms "includes / including / comprises / comprising" or "have / having" specify the presence of stated elements, but do not exclude the presence or addition of other elements.

[0012] In some examples, the computing system may store data persistently in one or more storage devices. For example, a server may store a data set on a local storage array, and may also store a backup copy of the data set in a remote backup device. In some examples, the backup copy may be stored in a form different from the data set. For example, the backup copy may include a deduplication representation of the data set. As used herein, a "storage system" may include a storage device or a storage device array. The storage system may also include (multiple) storage controllers that manage access to (multiple) storage devices. "Data unit" may refer to any data portion that can be individually identified in a storage system. In some cases, a data unit may refer to a block, a collection of blocks, or any other data portion. In some examples, the storage system may store data units in a persistent storage device. Persistent storage may be implemented using one or more (multiple) persistent (e.g., non-volatile) storage devices (such as (multiple) disk-based storage devices (e.g., (multiple) hard disk drives (HDDs)), (multiple) solid-state devices (SSDs) (such as (multiple) flash storage devices), etc., or a combination thereof). As used herein, a "controller" may refer to a hardware processing circuit, which may include any one or some 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 circuits. Alternatively, a "controller" may refer to a combination of a hardware processing circuit and machine-readable instructions (software and / or firmware) that may be executed on the hardware processing circuit.

[0013] In some examples, a data set can be specified according to one or more elements of a file system. As used herein, a "file system" is a system for organizing data stored in a storage device. For example, a file system may include a collection of data files stored in a directory hierarchy (e.g., including a root directory and one or more levels of subdirectories). In order to present data as a collection of data files and directories, a file system may maintain a structure of metadata. In the context of a file system, the term "metadata" refers to information describing volumes, files, and directories, but the information is not part of the stored data files. For example, the following information items describe a data file and are considered part of the file's metadata: file name, file size, creation time, last access / write time, user id, and block pointers to actual data of the file on the storage device. The information items that make up the metadata of a directory mainly include the names and references of the data files and subdirectories included in the directory. As used herein, a "file system operation" may refer to an operation that modifies an element of a file system (e.g., files and directories). For example, a file system operation may include adding a file system element, deleting a file system element, changing a file system element, and the like.

[0014] In some examples, the data set may be stored on a block-based storage device. As used herein, a "block-based" storage device may refer to a device that stores data at the block level. In the examples described herein, the term "block level" refers to a data storage level that is lower than the file and directory data storage level. In such examples, the 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), etc.) or a virtual volume, for example, may store data, and a level at which files and directories are implemented by a file system. A block-based storage device may receive the data blocks that constitute the data set as a data block stream.

[0015] In some examples, a block-based storage device may store a file system in the form of data blocks. Further, different types of data blocks (e.g., including file data and file system metadata) may be stored in different portions or locations of a block-based storage device. For example, in the case of a New Technology File System (NTFS) file system, data blocks including file system metadata may be stored in a master file table (MFT) of a block-based storage device, while data blocks including file data may be stored in different portions of the block-based storage device.

[0016] In some examples, a file system operation may 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 may execute the block-level I / O requests, but may not see 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 may receive a block-level I / O request to modify a data block including corresponding metadata (e.g., metadata recording the current location of the data file). However, in this example, the block-based storage device may not parse the file system operation embedded in the block-level I / O request, and therefore may not see the data file being moved to the new directory. In this way, identifying file system changes that occur at different points in time may require periodic processing to parse and analyze the entire file system, and thereby may have a negative impact on the performance of the block-based storage device.

[0017] According to some embodiments of the present disclosure, a controller may examine a block-level I / O request sent to a block-based storage device, and may determine whether the block-level I / O request includes a file system operation. When it is determined that the block-level I / O request includes a file system operation, the block-level I / O request is copied to a queue. The controller may dequeue a copy of the block-level I / O request asynchronously with the execution of the block-level I / O request. Further, the controller may parse the dequeued copy of the block-level I / O request to extract the details of the included file system operation. The controller may then add the extracted information to a database of file system changes. Subsequently, the database may be queried to identify specific changes to the file system. For example, the database may be queried to determine when a specific file has been changed, to quickly detect a large number of changes to multiple files (e.g., indicating a malware attack), and the like. In this way, the database may enable changes to the file system to be seen without having to repeatedly perform programming to parse and analyze the entire file system, and thereby may improve the performance of block-based storage devices. The following references Figures 1A to 7 Various aspects of the disclosed technology are further discussed.

[0018] Figure 1A to Figure 1B - Sample System

[0019] Figure 1A An example system 100 according to some embodiments is shown. As shown, the example system 100 may include a source system 110, a block-level storage device 120, and a file system operation (FSO) system 130. The source system 110 may be a physical computing device (e.g., a server, an apparatus, a desktop, etc.), a virtual computing device (e.g., a virtual machine, a container, etc.), etc. Further, the block-level storage device 120 may be all or part of a local storage device, a storage device, a storage array, a remote storage service, etc. In some embodiments, the source system 110 and the block-level storage device 120 may be implemented in different devices and / or locations. However, in other embodiments, 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.).

[0020] In some embodiments, the block-level storage device 120 may store data blocks in a deduplicated form. For example, the storage controller may perform a deduplication operation including comparing a fingerprint of an input data block with a fingerprint of a stored data block. As used herein, a "fingerprint" refers to a value obtained by applying a function to the contents of a data block (where "content" may include all or a subset of the contents of a data block). Examples of functions that may be applied include hash functions that generate hash values ​​based on the input data block. Examples of hash functions include cryptographic hash functions such as the Secure Hash Algorithm 2 (SHA-2) hash function (e.g., SHA-224, SHA-256, SHA-384, etc.). In other examples, other types of hash functions or other types of fingerprint functions may be used.

[0021] In some embodiments, the block-level storage device 120 can store the file system 125 in the form of data blocks. Further, in some embodiments, different types of data blocks of the file system 125 can be stored in different parts or areas of the block-based storage device 120. Now referring to Figure 1B , shows an example storage allocation 121. Storage allocation 121 can illustrate that file system 125 can use block-level storage device 120 (in Figure 1A In some embodiments, storage allocation 121 may include a metadata area 122 and a file data area 124. Data area 124 may store file system data (i.e., the data content of files in the file system). Metadata area 122 may include data blocks that store file system metadata (i.e., metadata about files and directories in the file system). For example, if file system 125 is a New Technology File System (NTFS), metadata area 122 may be implemented as a master file table (MFT) of a block-based storage device 120. In another example, if file system 125 is an extended file system (EXT), metadata area 122 may be implemented as an index node ("inode") table of block-based storage device 120. It should be noted that although Figure 1B An example storage allocation 121 including only one metadata area 122 and one file data area 124 is illustrated, but embodiments are not limited in this regard. For example, in some embodiments, the storage allocation 121 may include multiple metadata areas 122 and multiple file data areas 124 (e.g., at specified locations). In some embodiments, the location(s) of the metadata area(s) 122 (e.g., MFT, inode table, etc.) may be determined by an initial scan of the block-based storage device 120 and may be persistently stored in a data structure included in the block-based storage device 120.

[0022] Reference again Figure 1A, source system 110 may transmit a block-level input / output (I / O) request to block-level 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 a data block to perform a 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 transmit a particular block-level I / O request to modify a data block storing metadata recording a location of a data file. Accordingly, a particular block-level I / O request may be described herein as including a particular file system operation.

[0023] In some embodiments, 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., the FSO filter 140, the 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. Further, the FSO queue 150 and the FSO database 170 may be implemented using a non-transitory storage medium (e.g., a hard disk drive, a solid-state drive), a semiconductor memory (e.g., a random access memory), etc. In some embodiments, some or all of the components of the FSO system 130 may be implemented in a replication drive, a replication device, or a combination thereof. Further, in other embodiments, some or all of the components of the FSO system 130 may be implemented in a storage controller of the source system 110, a block-level storage device 120, or another device or system ( Figure 1A Implementation in (not shown).

[0024] In some embodiments, the FSO filter 140 can read or "snoop" block-level I / O requests transmitted from the source system 110 to the block-level storage device 120. The FSO filter 140 can 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 includes a file system operation. In some embodiments, the portion (evaluated by the FSO filter 140) can 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 FSO filter 140 can 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 a command for writing or modifying file system metadata. In another example, the FSO filter 140 can read a destination address at a predefined offset and length within the block-level I / O request, and can determine whether the destination address matches an address range reserved or designated for storing file metadata (e.g., Figure 1B The metadata area 122 shown in FIG. 1 matches the metadata area 122 shown in FIG.

[0025] In some embodiments, if the FSO filter 140 indicates that the block-level I / O request includes a file system operation, a copy of the block-level I / O request (also referred to herein as an "I / O request copy") may be stored in the FSO queue 150. Further, the original block-level I / O request (i.e., not the I / O request copy added to the FSO queue 150) is transmitted to the block-level storage device 120 and then executed by the block-level storage device 120. In other words, the FSO queue 150 is separate from and external to the execution path of the block-level I / O request (i.e., through the block-level storage device 120). The FSO queue 150 may store multiple I / O request copies (i.e., copies of different block-level I / O requests identified by the FSO filter 140) for later processing by the FSO parser 160. Refer to the following for details. Figure 2A An example implementation of FSO queue 150 is described.

[0026] In some embodiments, the FSO parser 160 may dequeue one of the I / O request copies from the FSO queue 150 in response to a triggering event, and may parse the dequeued I / O request copy. The triggering event may be asynchronous with the execution of the block-level I / O request by the block-level storage device 120. For example, the triggering event of the FSO parser 160 may include determining that the available processing bandwidth of the FSO system 130 exceeds a threshold level (e.g., indicating that the processor of the FSO system 130 is currently idle or has a relatively low workload). In another example, the triggering event may include determining that the FSO queue 150 has been filled to a predefined level (e.g., the maximum number of queued I / O request copies). Other examples of triggering events of the FSO parser 160 are possible. In the examples described herein, the FSO parser 160 (which is separate from the block-level storage device 120) may parse the I / O request copy into (multiple) operations that are separate and asynchronous with the execution of the block-level I / O request by the block-level storage device 120.

[0027] In some embodiments, the FSO parser 160 may parse the dequeued I / O request copy to extract the details of the embedded file system operation. For example, the FSO 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. Further, in some examples, the FSO parser 160 may parse a relatively large portion (e.g., greater than 50%) of the dequeued I / O request copy. In some embodiments, the details of the extracted file system operation may be used to populate an entry of the FSO database 170 representing the particular file system operation. Figure 2B An example implementation of the FSO database 170 is described.

[0028] In some implementations, the FSO database 170 may be queried to obtain information about changes to the file system 125. For example, the FSO database 170 may be queried to determine the number of files that have been changed in a recent time period. If it is determined that the number of changed files exceeds a predefined threshold, an alarm may be raised to indicate that a malware attack may be affecting the file system 125 (e.g., a ransomware attack is attempting to encrypt all files). In another example, the FSO database 170 may be queried to determine the time period when a particular file was last changed. Other examples are possible. In this way, the FSO database 170 may be used to determine changes to the file system 125 without having to repeatedly perform programming to parse and analyze the entire file system 125. It should be noted that although Figure 1AAn example embodiment is shown in which the FSO database 170 is included in the FSO system 130, but other embodiments are possible. For example, it is contemplated that the FSO database 170 may be located in the source system 110, the block-level storage device 120, an external system or location ( Figure 1A not shown) or any combination thereof.

[0029] FIG. 2A to FIG. 2B - Example data structure

[0030] Figure 2A 2 shows a diagram of an example file system operation (FSO) queue 210 according to some embodiments. FSO queue 210 may generally correspond to FSO queue 150 ( Figure 1A In some embodiments, the FSO queue 210 may temporarily store copies of multiple block-level I / O requests for later resolution (e.g., by Figure 1A In response to determining that the I / O request includes a file system operation (e.g., by Figure 1A ), each I / O request may be replicated and stored in the FSO queue 210. In some implementations, the FSO queue 210 may store the I / O request replicas in the order of arrival (i.e., the order in which they were added to the FSO queue 210). Further, the I / O request replicas may be dequeued in the order in which they were added to the FSO queue 210 (e.g., by dequeuing the oldest I / O request replica in the FSO queue 210).

[0031] Figure 2B 2 shows a diagram of an example FSO database 220 according to some embodiments. The FSO database 220 may generally correspond to the FSO database 170 ( Figure 1A In some embodiments, the FSO database 220 may store information about the storage system based on the block (e.g., Figure 1A For example, the FSO database 220 may include a table consisting of a plurality of rows, wherein each row corresponds to a different FSO. Further, each row may include a plurality of columns, wherein each column represents a different attribute (i.e., parameter) of the FSO. For example, Figure 2BAs shown, each row may include an "FSO ID" column for recording a unique identifier of the FSO (i.e., an attribute) and an "Element" column for identifying a specific file system element (or multiple elements) affected by the FSO. Further, each row may include a "Type" column for recording the type of the FSO. For example, the "Type" column may record a file creation FSO, a directory creation FSO, a file / directory modification FSO (e.g., rename, move, edit, etc.), a file / directory deletion FSO, and so on. In addition, each row may include a "Time" column for recording the creation time of the row and a "Parent" column for recording the parent of the FSO element (e.g., identified by the "Element" column). It should be noted that although Figure 2A The FSO database 220 is illustrated as a row table, but other data structures are possible. For example, the FSO database 220 can be implemented as a delimited text file (e.g., key-value pairs), can be stored as an extensible markup language (XML) file, structured text, delimited text, etc., can be hard-coded as program instructions, etc.

[0032] In some implementations, the FSO database 220 may be queried to identify specific changes to the file system. For example, the FSO database 220 may be queried to determine when a specific file has been changed, to quickly detect large changes (e.g., encryption or deletion) to multiple files caused by a malware attack, etc. In this way, the FSO database 220 may enable changes to the file system to be seen without repeatedly performing programming to parse and analyze the entire file system, and may thereby improve the performance of block-based storage devices.

[0033] In some implementations, the FSO database 220 may be queried to determine the complete address path of each data file. Figure 2B As shown, "File2" is included in "Directory6", which in turn is included in "Directory1". Thus, the FSO database 220 can be used to query to determine the address path "C:\Directory1\Directory6\File2". Further, the FSO database 220 can be updated to store the determined complete address path of each data file.

[0034] Figure 3 as well as FIG. 4A to FIG. 4C - Example procedure for collecting file system operation data

[0035] Figure 3 An example process 300 for collecting file system operation data according to some embodiments is shown. In some examples, the process 300 may use a file system operation (FSO) system 130 (which may be separate from the block-level storage device 120). Figure 1AProcess 300 may be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by (multiple) processors). The machine-readable instructions may be stored in a non-transitory computer-readable medium such as an optical storage device, a semiconductor storage device, or a 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 illustration purposes, reference may be made to some example embodiments. Figure 1A to Figure 1B as well as FIG. 4A to FIG. 4C 3 to describe the details of process 300. However, other implementations are possible.

[0036] Block 310 may include checking a block-level input / output (I / O) request to be executed by a storage device. Figure 1A , the FSO filter 140 monitors or "snoops" block-level I / O requests transmitted from the source system 110 to the block-level storage device 120. In some embodiments, the FSO filter 140 reads a single string (e.g., a prefix of the block-level I / O request, a destination address of the block-level I / O request, etc.) at a specific location (e.g., offset and length) within the block-level I / O request.

[0037] Decision block 320 may include determining whether the block-level I / O request includes a file system operation (FSO). If not (“No”), process 300 may return to block 310 (i.e., check for another block-level I / O request). Otherwise, if it is determined at decision block 320 that the block-level I / O request includes an FSO (“Yes”), process 300 may continue at block 330, including inserting the block-level I / O request into an FSO queue that is outside the execution path of the block-level I / O request. For example, referring to Figure 1A and Figure 4A , the FSO filter 140 reads the prefix of the block-level I / O request 410 and matches the prefix with the command identifier "FILE" for FSO. Thus, the FSO filter 140 determines that the block-level I / O request 410 includes an FSO, and in response loads the block-level I / O request 410 into the FSO queue 150. In another example, referring to Figure 1A and Figure 4B , the FSO filter 140 reads the destination address of the block-level I / O request 410 (eg, the specified offset and length) and compares the destination address to a predefined metadata address range (eg, Figure 1B Thus, the FSO filter 140 determines that the block-level I / O request 410 includes an FSO, and in response loads the block-level I / O request 410 into the FSO queue 150.

[0038] Block 340 may include dequeuing a block-level I / O request from the FSO queue asynchronously with the execution of the block-level I / O request. Figure 1A and Figure 4C , the FSO parser 160 dequeues the block-level I / O request 410 from the FSO queue 150 in response to a triggering event (e.g., upon detecting that the controller of the FSO system 130 has a relatively low workload). In some embodiments, the triggering event may be asynchronous with the execution of the block-level I / O request by the block-level storage device 120. Thus, the FSO parser 160 (which is separate from the block-level storage device 120) may parse the I / O request copy into (multiple) operations that are separate from and in addition to the execution of the block-level I / O request by the block-level storage device 120.

[0039] Block 350 may include parsing the block-level I / O request to extract a set of attributes of the block-level I / O request. Block 360 may include using the extracted set of attributes to generate a new entry for the FSO database. After block 360, process 300 may return to block 310 (i.e., check for another block-level I / O request). For example, referring to Figure 1A and Figure 4C , the FSO parser 160 reads part or all of the dequeued block-level I / O request 410 to find multiple delimiters, and can use the multiple delimiters to extract a set of data fields 430 from the I / O request copy. The extracted set of data fields 430 is populated into the entry of the FSO database 170 that represents the FSO embedded in the block-level I / O request 410.

[0040] Figure 5 - Sample computing device

[0041] Figure 5 Schematic diagram of an example computing device 500 is illustrated. In some examples, computing device 500 may generally correspond to a file system operating (FSO) system 130 (which may be separate from block-level storage device 120). Figure 1A As shown in the figure, computing device 500 may include hardware processor 502 and machine-readable storage device 505 containing instructions 510 to 550. Machine-readable storage device 505 may be a non-transitory medium. Instructions 510-550 may be executed by hardware processor 502 or by a processing engine included in hardware processor 502.

[0042] Instructions 510 may be executed to examine a block-level input / output (I / O) request to be performed by a block-based storage device. Instructions 520 may be executed to determine whether the block-level I / O request includes at least one file system operation. For example, referring to Figure 1A, the FSO filter 140 examines the block-level I / O request transmitted from the source system 110 to the block-level storage device 120. In some implementations, the FSO filter 140 reads a single string at a specific location (eg, offset and length) within the block-level I / O request.

[0043] Instructions 530 may be executed to generate a copy of the block-level I / O request in response to determining that the block-level I / O request includes a file system operation. Figure 1A and Figure 4A , the FSO filter 140 reads the prefix of the block-level I / O request 410 and matches the prefix with the command identifier "FILE" for FSO. Thus, the FSO filter 140 determines that the block-level I / O request 410 includes an FSO, and in response loads the block-level I / O request 410 into the FSO queue 150. In another example, referring to Figure 1A and Figure 4B , the FSO filter 140 reads the destination address of the block-level I / O request 410 (eg, the specified offset and length) and compares the destination address to a predefined metadata address range (eg, Figure 1B Thus, the FSO filter 140 determines that the block-level I / O request 410 includes an FSO, and in response loads the block-level I / O request 410 into the FSO queue 150.

[0044] Instructions 540 may be executed to parse the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein parsing the copy of the block-level I / O request is separate and asynchronous from executing the block-level I / O request by the block-based storage device. Figure 1A and Figure 4C , FSO parser 160 dequeues block-level I / O request 410 from FSO queue 150 in response to a trigger event, and parses a relatively large portion (e.g., greater than 50%) of the dequeued I / O request copy to extract details of the embedded file system operation. For example, FSO parser 160 may read part or all of the I / O request copy to find multiple delimiters, and may extract multiple data fields from the I / O request copy using the multiple delimiters.

[0045] Instructions 550 may be executed to store the extracted plurality of attributes of the file system operation in entries 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 a block-based storage device. Figure 1A and Figure 4C , FSO parser 160 uses the data fields (extracted from the I / O request copy) to populate entries of FSO database 170 that represent file system operations.

[0046] Figure 6 - Example process

[0047] Figure 6 An example process 600 for collecting file system operation data according to some embodiments is shown. In some examples, the process 600 may use a file system operation (FSO) system 130 (which may be separate from the block level storage device 120). Figure 1A ) can be performed. Process 600 can be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions that can be executed by (multiple) processors). The machine-readable instructions can be stored in a non-transitory computer-readable medium such as an optical storage device, a semiconductor storage device, or a magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

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

[0049] Block 640 may include parsing, by the controller, the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein parsing the copy of the block-level I / O request is separate and asynchronous from executing the block-level I / O request by the block-based storage device. Block 650 may include storing, by the controller, the plurality of extracted attributes of the file system operation in entries 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.

[0050] Figure 7 - Example machine-readable medium

[0051] Figure 7 A machine-readable medium 700 storing instructions 710-750 according to some embodiments is shown. The instructions 710-750 may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc., which may be separate from executing block-level I / O requests by a block-level storage device as described herein. The machine-readable medium 700 may be a non-transitory storage medium, such as an optical storage medium, a semiconductor storage medium, or a magnetic storage medium.

[0052] Instructions 710 may be executed to examine a block-level input / output (I / O) request to be performed by a block-based storage device. Instructions 720 may be executed to determine whether the block-level I / O request includes at least one file system operation. Instructions 730 may be executed to generate a copy of the block-level I / O request in response to determining that the block-level I / O request includes a file system operation.

[0053] Instructions 740 may be executed to parse the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein parsing the copy of the block-level I / O request is asynchronous with the block-based storage device executing the block-level I / O request. Instructions 750 may be executed to store the extracted plurality of attributes of the file system operation in entries 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.

[0054] According to some embodiments described herein, a controller may check a block-level I / O request sent to a block-based storage device, and may determine whether the block-level I / O request includes a file system operation. When it is determined that the block-level I / O request includes a file system operation, the block-level I / O request is copied to a queue. The controller may dequeue a copy of the block-level I / O request asynchronously with the execution of the block-level I / O request. Further, the controller may parse the dequeued copy of the block-level I / O request to extract the details of the included file system operation. The controller may then add the extracted information to a database of file system changes. Subsequently, the database may be queried to identify specific changes to the file system. In this way, the database may enable changes to the file system to be seen without repeatedly performing programming to parse and analyze the entire file system, and thereby may improve the performance of the block-based storage device.

[0055] Note that although Figures 1A to 7 Various examples are shown, but the embodiments are not limited in this regard. Figure 1A It is contemplated that the system 100 may include additional devices and / or components, fewer components, different components, different arrangements, etc. In another example, it is contemplated that the functionality of the FSO system 130 described above may be included in any other engine or software of the system 100. Other combinations and / or variations are also possible.

[0056] Data and instructions are stored in corresponding storage devices implemented as one or more computer-readable or machine-readable storage media. Storage media include various forms of non-transitory memory, including: semiconductor memory devices, such as dynamic random access memory or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed floppy disks and removable disks; other magnetic media, including magnetic tape; optical media, such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices.

[0057] Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly multiple nodes. Such one or more computer-readable or machine-readable storage media are considered to be part of an article (or product). An article or product may refer to a single component or multiple components of any manufacture. One or more storage media may be located in a machine running machine-readable instructions, or at a remote site, from which machine-readable instructions may be downloaded over a network for execution.

[0058] In the foregoing description, many details are set forth to enable an understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A computing system comprising: processor; as well as A machine-readable storage device storing instructions executable by the processor to: inspecting a block-level input / output (I / O) request to be performed by a block-based storage device; determining whether the block-level I / O request includes at least one file system operation; In response to determining that the block-level I / O request includes a file system operation, generating a copy of the block-level I / O request; parsing the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein parsing the copy of the block-level I / O request is asynchronous with executing the block-level I / O request by the block-based storage device; and The extracted plurality of attributes of the file system operation are stored in entries 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. The computing system of claim 1 , comprising instructions executable by the processor to: 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, it is determined that the block-level I / O request includes the file system operation.

3. The computing system of claim 1 , comprising instructions executable by the processor to: determining a first storage location specified in the block-level I / O request; and In response to determining that the first storage location overlaps with a metadata address range of the block-based storage device, determining that the block-level I / O request includes the file system operation.

4. The computing system of claim 1 , comprising instructions executable by the processor to: prior to parsing the block-level I / O request: storing a copy of the block-level I / O request in a queue; and In response to detecting a triggering event, dequeuing the block-level I / O request from the queue, wherein: The triggering event is asynchronous with the execution of the block-level I / O request.

5. The computing system of claim 4, wherein: The triggering event is a determination that the available processing bandwidth of the computing device exceeds a threshold level.

6. The computing system of claim 4, wherein: The triggering event is a determination that the queue has been filled to a predetermined level.

7. The computing system of claim 1, wherein: The file system operation is an operation selected from a create file operation, a change file operation, and a delete file operation.

8. The computing system of claim 1, wherein: The plurality of attributes include an element identifier, a file system operation type, and a file system operation timestamp.

9. A non-transitory machine-readable medium storing instructions that, when executed, cause a processor to: inspecting a block-level input / output (I / O) request to be performed by a block-based storage device; determining whether the block-level I / O request includes at least one file system operation; In response to determining that the block-level I / O request includes a file system operation, generating a copy of the block-level I / O request; parsing the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein parsing the copy of the block-level I / O request is asynchronous with executing the block-level I / O request by the block-based storage device; and The extracted plurality of attributes of the file system operation are stored in entries 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, comprising instructions that when executed cause the processor to: 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, it is determined that the block-level I / O request includes the file system operation.

11. The non-transitory machine-readable medium of claim 9, comprising instructions that when executed cause the processor to: determining a first storage location specified in the block-level I / O request; and In response to determining that the first storage location overlaps with a metadata address range of the block-based storage device, determining that the block-level I / O request includes the file system operation.

12. The non-transitory machine-readable medium of claim 9, comprising instructions that when executed cause the processor to: prior to parsing the block-level I / O request: storing a copy of the block-level I / O request in a queue; and In response to detecting a triggering event, dequeuing the block-level I / O request from the queue, wherein: The triggering event is asynchronous with 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 the available processing bandwidth of the computing device exceeds a threshold level.

14. The non-transitory machine-readable medium of claim 9, wherein: The file system operation is an operation selected from a create file operation, a change file operation, and a delete file operation.

15. A method comprising: examining, by a controller of the storage system, a block-level input / output (I / O) request to be performed by a block-based storage device; determining, by the controller, whether the block-level I / O request includes at least one file system operation; In response to determining that the block-level I / O request includes a file system operation, generating, by the controller, a copy of the block-level I / O request; parsing, by the controller, the copy of the block-level I / O request to extract a plurality of attributes of the file system operation, wherein parsing the copy of the block-level I / O request is asynchronous with execution of the block-level I / O request by the block-based storage device; and The extracted plurality of attributes of the file system operation are stored, by the controller, in entries 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. The method of 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; as well as In response to determining that the prefix of the block-level I / O request matches the first text string, it is determined that the block-level I / O request includes the file system operation.

17. The method of claim 15, comprising: determining a first storage location specified in the block-level I / O request; as well as In response to determining that the first storage location overlaps with a metadata address range of the block-based storage device, determining that the block-level I / O request includes the file system operation.

18. The method of claim 15, comprising, before parsing the block-level I / O request: storing a copy of the block-level I / O request in a queue; and In response to detecting a triggering event, dequeuing the block-level I / O request from the queue, wherein: The triggering event is asynchronous with the execution of the block-level I / O request.

19. The method of claim 18, wherein: The triggering event is a determination that the available processing bandwidth of the computing device exceeds a threshold level.

20. The method of claim 15, wherein: The file system operation is an operation selected from a create file operation, a change file operation, and a delete file operation.

Images