A method, system, and media for monitoring Linux file system metadata.

Abstract

This invention discloses a method, system, and medium for monitoring Linux file system metadata. The method includes: a user-space program responding to an execution request from a user carrying one or more specified block devices; the user-space program parsing and obtaining the WWID of the actual backend storage device corresponding to the given block device, as well as the location and file system type of the metadata to be monitored on the actual backend storage device; the user-space program passing the obtained information to a kernel-space program; the kernel-space program obtaining the WWID of the actual backend storage device corresponding to the target block device, the location of the written range on the actual backend storage device, the call stack, and the write time, matching it with the information passed from the user-space program, filtering out suspicious events and passing them to the user-space program, and recording the received suspicious event information to a designated location. This invention can promptly detect and record suspicious events, facilitating the investigation of the causes of file system metadata corruption.

Description

Technical Field

[0001] This invention relates to the technical field of file system metadata monitoring methods, specifically to a Linux file system metadata monitoring method, system, and medium. Background Technology

[0002] In Linux-based server environments, to improve storage reliability and flexibility, iSCSI and MULTIPATH technologies are typically combined to remotely share block devices over a network. Ideally, iSCSI creates multiple block devices corresponding to the same backend storage, while MULTIPATH creates a device mapping for these block devices, and finally, a file system is created and used on this device mapping. However, the combination of these two technologies is not an atomic operation. An application might use a block device created by iSCSI before MULTIPATH has created device mappings for it. The application itself cannot distinguish whether the multiple block devices it uses correspond to the same backend storage, which could lead to multiple users accessing the same backend storage simultaneously, ultimately compromising data consistency on the backend storage.

[0003] Because Linux systems have file system metadata caching, and traditional file systems (such as EXT4 and XFS) are designed for single-user scenarios, they typically don't check the consistency between the cached data and the data on physical storage. This means that when data on the backend storage is corrupted, the file system may not immediately detect it, and it might even appear to still function normally, but at this point, the file system is no longer reliable. It's only when the file system is remounted and data needs to be read from the backend storage that it will most likely report an error indicating that the file system data on the backend storage has been corrupted. By this time, some time has passed since the failure occurred, which may result in data loss or corruption during this period, and the faulty environment no longer exists, greatly complicating troubleshooting.

[0004] The aforementioned issues typically require operational and maintenance measures to mitigate, such as proactively disabling applications from directly using block devices created with iSCSI, or delaying application startup by an estimated time to allow the MULTIPATH device mapping to complete. However, this relies on the initiative of the operations and maintenance personnel; if configuration errors occur, the problem will still arise and its source cannot be traced.

[0005] The XFS and EXT4 file systems offer different mitigation solutions at the file system level for the aforementioned issues. XFS prevents mounting XFS file systems with the same UUID on the same machine. EXT4 uses MMP (Multiple Mount Protection), which sets a periodic refresh flag on the block device. During mounting, it waits two refresh cycles; if the flag is refreshed, it indicates the file system is in use and will be refused mounting again. These two solutions can resolve most reuse issues at the file system level, but they are ineffective when applications use the device at the block level (e.g., processes bypass the file system to write data directly to the block device).

[0006] With the gradual improvement of kernel tracing technologies such as ftrace, EBPF, kprobe, and tracepoint on Linux systems, obtaining kernel data and monitoring process access to target block devices based on the obtained kernel data has become a reality. For example, Chinese patent document CN201310512066.4 discloses a disk access request monitoring system and method in a virtualization environment, which uses tracepoint technology to monitor disk access by a specific virtual machine, can determine the virtual machine to which the process belongs, and record the I / O operations of the virtual machine process on a specific disk. Chinese patent document CN202111344516.4 discloses a Linux system protection method based on ftrace technology, which can judge the I / O of a specific sector of a specified disk and reconstruct the request to protect the target sector. However, neither of the above two methods can be used in iSCSI scenarios to determine whether the target block device operated by a process corresponds to the same back-end storage device, cannot identify whether the metadata of the file system on the disk is stored at the write location of the process to the back-end storage, and cannot determine whether the process's write call is legal. When the file system is damaged, it is difficult to trace the source to find the cause of the damage. Summary of the Invention

[0007] The technical problem to be solved by this invention is as follows: In view of the above-mentioned problems of the prior art, this invention provides a Linux file system metadata monitoring method, system and medium. This invention aims to solve the problems that existing methods for monitoring process access to target block devices cannot determine whether the block device operated by the process corresponds to the same backend storage device as the monitored block device, cannot determine whether the location written by the process to the backend storage device contains the file system metadata on the disk, and cannot determine whether the process's write call is legal. This invention can monitor file system metadata corruption behavior in iSCSI scenarios, can detect file system corruption in a timely manner, and record the scene for easy tracing.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0009] A method for monitoring Linux file system metadata includes using a combination of user-space and kernel-space programs to monitor write operations to a specific range of the target backend storage under an iSCSI environment.

[0010] S1, The user-space program responds to the user's execution request carrying one or more specified block devices;

[0011] S2, the user space program parses and obtains the actual back-end storage device WWID corresponding to the user-given block device, the location of the metadata to be monitored on the actual back-end storage device, and the file system type corresponding to these locations;

[0012] S3, the user-space program loads the kernel-space program and passes the acquired information to the kernel-space program;

[0013] S4, the kernel space program obtains the actual back-end storage device WWID corresponding to the target block device, the location of the written range on the actual back-end storage device, the call stack and the write time from the process context, matches it with the information passed by the user space program, filters out suspicious events, records the suspicious event information and passes it to the user space program;

[0014] S5, the user space program records the received suspicious event information to the designated location.

[0015] Optionally, step S2 includes: obtaining the path of a user-given block device, and performing the following steps for each given block device path:

[0016] S2.1, attempt to obtain the device number of the given block device, and determine whether the device number was successfully obtained. If it is unsuccessful, ignore the block device and end; otherwise, jump to step S2.2.

[0017] S2.2, Loop through the list of supported file systems to determine whether the given block device contains a supported file system. If it does not contain a supported file system, ignore the block device and end; otherwise, jump to step S2.3.

[0018] S2.3, determine the location of the superblock on the given block device according to the type of file system contained in the given block device, read its superblock to parse the location information of the specified key metadata of the file system on the given block device, and represent it as a metadata interval. The data structure of the metadata interval includes the file system type, start position and end position. Integrate all the intervals represented by the metadata intervals into a metadata interval set, and merge the intervals of the same type that are adjacent at the beginning and end in the metadata interval set. Use the device number of the given block device as the key and the set of metadata intervals on the given block device as the value, and save them as key-value pairs. Read the start address and occupied space size of the file system module enumerated in this loop traversal from the / proc / modules file or parse it from the / proc / kallsyms file to obtain the address interval pair of the file system module in memory. The fields of the address interval pair include the start position and end position, and save it to the file system type address interval mapping map with the file system type enumeration as the key and the address interval pair as the value.

[0019] S2.4, for the set of metadata intervals on a given block device in the key-value pair, perform user space device identification, convert the set of metadata intervals representing the location of metadata on the given user device into a set of metadata intervals representing the corresponding location of metadata on the actual backend storage device, and save it as a new key-value pair.

[0020] Optionally, step S2.4 includes: A directory named after the device number (using the key-value pair as the key) can be found in the / sys / dev / block / directory; if a partition file exists in this directory, it indicates that the device corresponding to the device number is a partition; the sector offset, sector size, and device number of the actual device relative to the partition are read from the files in this directory; the start and end positions of all metadata intervals in the original metadata interval set on the device corresponding to the device number are increased by the sector offset multiplied by the sector size to obtain a new metadata interval set; the device number of the actual device is used as the key, and the new metadata interval set is used as the value, and these are saved as a new key-value pair; if a dm directory exists in this directory, it indicates that the device corresponding to the device number is a mapped device; the actual device number and mapping relationship of the mapped actual device are obtained through the mapping relationship table saved by the system; the interval set corresponding to the metadata interval set on the device corresponding to the device number is calculated on the actual device based on the mapping relationship; the actual device number of the actual device is used as the key, and the metadata interval set on the actual device is used as the value, and these are saved as a new key-value pair. If a file named `device / wwid` exists in the directory and is readable, it indicates that the device corresponding to the device number is a standard SCSI device. The `device / wwid` file is read to obtain the SCSI disk number (WWID) of the corresponding standard SCSI device. The WWID is used as the key, and the metadata range set on the device corresponding to the device number is used as the value, and these are saved as a new key-value pair. If the file in the directory indicates that the device corresponding to the device number is another supported device, the supported device is obtained. The actual device number of that device is used as the key, and the original data of the metadata range set on the device corresponding to the device number, or the data after a specified format conversion, is used as the value, and these are saved as a new key-value pair. If the actual device in the above conversion process is a partition, a mapped device, or one of other supported devices, the directory named after the device number used as the key in the new key-value pair is found again in the ` / sys / dev / block / ` directory, and the conversion is repeated according to the above rules to obtain new key-value pairs until the actual device is a standard SCSI device. If the device corresponding to the device number is an unsupported device, the device is ignored.

[0021] Optionally, in step S3, the user space program loads the kernel space program and passes the acquired information to the kernel space program, which includes: mounting the kernel space program to the entry point of the submit_bio function through the BPF system call provided by the Linux kernel, and passing the new key-value pairs and file system type address range mapping map to the kernel space program in the form of BPF mapping. The kernel space program is a verified EBPF program that is mounted to the entry point of the submit_bio function in the kernel space.

[0022] Optionally, step S4 includes:

[0023] S4.1 After any process calls the submit_bio function, it obtains the parameters of the submit_bio function through the PT_REGS_PARM1_CORE macro;

[0024] S4.2, convert the parameters of the function submit_bio into a bio structure, and use the bi_opf node in the bio structure, which is used to store the operation flag and request type, to determine whether the current IO event is a write operation. If it is not a write operation, ignore the current event; otherwise, jump to step S4.3.

[0025] S4.3 Obtain the target block device information of this IO event through the block device node bi_bdev of the bio structure, parse the WWID of the IO event to be written to the corresponding actual backend storage device, and calculate the interval to be written to the corresponding actual backend storage device; if parsing the WWID fails or calculating the interval to the corresponding actual backend storage device fails, then ignore this event.

[0026] S4.4 Determine whether the actual back-end storage device WWID corresponding to the target block device of this IO event exists in the BPF mapping of the kernel space program. If it does not exist in the BPF mapping of the kernel space program, ignore the IO event; otherwise, jump to step S4.5.

[0027] S4.5, confirm whether this IO event involves the metadata area, including: using the actual backend storage device WWID corresponding to the target block device as the key to obtain the corresponding metadata range set from the BPF mapping, traversing all elements in the obtained metadata range set, and comparing each element with the range written to the corresponding actual backend storage device in this IO event. If there is no overlap, then this IO event does not involve the metadata area and this IO event is ignored; otherwise, proceed to step S4.6.

[0028] S4.6, Analyze whether the call stack of this IO event is valid, including: obtaining the file system type with overlapping metadata ranges, and obtaining the memory address range of the corresponding module of the file system type from the BPF mapping; obtaining the call stack of this call through the bpf_get_stack function and storing it in the array arr; traversing the function pointers in the array arr and comparing them one by one with the memory address range of the corresponding module of the file system type obtained from the BPF mapping. If a function pointer is within the address range, the call stack of this IO event is considered valid and this event is ignored; otherwise, this IO event is determined to be a risky and suspicious event, and the process jumps to step S4.7.

[0029] S4.7 collects information related to this IO event and passes it to the user-space program.

[0030] Optionally, in step S4.3, the method for parsing the WWID of the current IO event written to the corresponding actual backend storage device and calculating the interval written to the corresponding actual backend storage device by the current IO event is as follows: First, calculate the writing interval [(starting sector number + offset) * sector size, (starting sector number + offset) * sector size + interval size)] using the starting sector number and offset value recorded by bi_bdev. Then, determine the device type of the target block device by using the address of gd->fops->open recorded by bi_bdev. If the target block device is a mapped device, update the actual device and the interval written to the actual device by the mapping table saved by the kernel; otherwise... For standard SCSI devices, the WWID of the actual back-end storage device is obtained by parsing according to the SCSI standard, and the write range is identified as the range where the current IO event is written to the actual back-end storage device. For other supported device types, the range where the current IO event is written to the actual device is obtained by parsing according to its device characteristics. If the actual device in the above conversion is a mapped device or one of the other supported device types, the range where the current IO event is written to the actual device is converted again according to the above rules until the WWID of the actual back-end storage device and the range where the current IO event is written to the actual back-end storage device are obtained. If the target block device or the actual device is an unsupported device, the parsing fails.

[0031] Optionally, in step S4.7, when collecting information related to the current I / O event and passing it to the user space program, the kernel space program and the user space program exchange data through a ring buffer. The passage to the user space program means that the kernel space program organizes the information related to the current I / O event into a structure and submits it to the ring buffer.

[0032] In addition, the present invention provides a Linux file system metadata monitoring system, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the Linux file system metadata monitoring method.

[0033] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the Linux file system metadata monitoring method via a processor.

[0034] In addition, the present invention also provides a computer program product, including a computer program or instructions that are programmed or configured to execute the Linux file system metadata monitoring method via a processor.

[0035] Compared with the prior art, the present invention has the following main advantages:

[0036] The present invention includes the following steps: S1, a user-space program responds to an execution request from a user carrying one or more specified block devices; S2, the user-space program parses and obtains the actual back-end storage device WWID corresponding to the given block device, the location of the metadata to be monitored on the actual back-end storage device, and the file system type corresponding to these locations; S3, the user-space program loads the kernel-space program and passes the obtained information to the kernel-space program; S4, the kernel-space program obtains the actual back-end storage device WWID and IO event information corresponding to the target block device from the process context. The IO event information includes the IO event type, such as a write operation. The IO event information also includes the location information of the write range on the actual back-end storage device, the call stack, and the write time. It compares this information with the information passed by the user-space program, filters out suspicious events, records the suspicious event information, and passes it to the user-space program; S5, the user-space program records the received suspicious event information to a specified location. This invention can solve the problems of existing methods for monitoring process access to target block devices, which cannot determine whether the block device operated by the process corresponds to the same backend storage device as the monitored block device, whether the location where the process writes to the backend storage device stores the metadata of the disk file system, and whether the process's write call is legal. It can monitor file system metadata corruption behavior in iSCSI scenarios, can promptly detect and record suspicious events, and facilitate the investigation of the cause of file system metadata corruption. Attached Figure Description

[0037] Figure 1 This is a timing diagram of the Linux file system metadata monitoring method according to an embodiment of the present invention.

[0038] Figure 2This is a flowchart illustrating step S2 of an embodiment of the present invention.

[0039] Figure 3 This is a schematic diagram illustrating the data contained in the metadata set of an embodiment of the present invention.

[0040] Figure 4 This is a flowchart illustrating step S2.4 of an embodiment of the present invention. Detailed Implementation

[0041] The technical solution of the present invention will now be described in further detail with reference to the accompanying drawings.

[0042] like Figure 1 As shown, the Linux file system metadata monitoring method in this embodiment includes using a combination of user-space and kernel-space programs to monitor write operations to a specific range of the target backend storage under an iSCSI environment:

[0043] S1, The user-space program responds to the user's execution request carrying one or more specified block devices;

[0044] S2, the user space program parses and obtains the WWID of the actual back-end storage device corresponding to the user-given block device, the location of the metadata to be monitored on the actual back-end storage device, and the file system type corresponding to these locations;

[0045] S3, the user-space program loads the kernel-space program and passes the acquired information to the kernel-space program;

[0046] S4, the kernel space program obtains the actual back-end storage device WWID corresponding to the target block device, the location of the written range on the actual back-end storage device, the call stack and the write time from the process context, matches it with the information passed by the user space program, filters out suspicious events, records the suspicious event information and passes it to the user space program;

[0047] S5, the user space program records the received suspicious event information to the designated location.

[0048] The method in this embodiment can solve the problems that existing methods for monitoring process access to target block devices cannot determine whether the block device operated by the process corresponds to the same backend storage device as the monitored block device, cannot determine whether the location where the process writes to the backend storage device stores the metadata of the file system on the disk, and cannot determine whether the process's write call is legal. It can monitor file system metadata corruption behavior in iSCSI scenarios, can promptly detect and record suspicious events, and facilitate the investigation of the cause of file system metadata corruption.

[0049] like Figure 2As shown, to facilitate the storage and retrieval of the acquired data, step S2 in this embodiment includes: obtaining the path of the block device given by the user, and performing the following steps for each given block device path:

[0050] S2.1, attempt to obtain the device number of the given block device, and determine whether the device number was successfully obtained. If it is unsuccessful, ignore the block device and end; otherwise, jump to step S2.2.

[0051] S2.2, Loop through the list of supported file systems to determine whether the given block device contains a supported file system. If it does not contain a supported file system, ignore the block device and end; otherwise, jump to step S2.3.

[0052] S2.3, determine the location of the superblock on the given block device according to the file system type of the given block device, read its superblock to parse the location information of the specified key metadata of the file system on the given block device, and represent it as a metadata range. The data structure of the metadata range includes the file system type, start position, and end position (see...). Figure 3 This process integrates all metadata ranges into a single metadata range set, merging adjacent ranges of the same type within the set. It uses the device number of the given block device as the key and the set of metadata ranges on the given block device as the value, storing them as key-value pairs. If the file system is compiled and used as a module, it reads the starting address and size of the file system module enumerated in this loop from the ` / proc / modules` file. If the file system is directly compiled into the kernel, it parses the address range pair of the file system module in memory from the ` / proc / kallsyms` file. The address range pair includes the starting and ending positions and is stored in a file system type address range mapping map, where the file system type enumeration is the key and the address range pair is the value.

[0053] S2.4, For the set of metadata intervals on a given block device in the key-value pair, perform user space device identification, convert the set of metadata intervals representing the location of metadata on the given user device into the set of metadata intervals representing the corresponding location of metadata on the corresponding actual backend storage device, and save it as a new key-value pair.

[0054] It should be noted that in step S2.4, specifying critical metadata refers to metadata that has a significant impact on the operation of the file system after corruption. The specific metadata to be specified is selected as needed. For example, for the ext4 file system, the specified critical metadata includes the superblock, block group descriptor, and block bitmap, iNode bitmap, and iNode list for each block group. For the xfs file system, the specified critical metadata includes the superblock, agf, agi, agfl, ABTB, ABTC, and IATB for each AG.

[0055] like Figure 4As shown, to ensure the accuracy of the metadata set conversion, step S2.4 of this embodiment includes: A directory named after the device number (using the key-value pair as the key) can be found in the / sys / dev / block / directory; if a partition file exists in this directory, it indicates that the device corresponding to the device number is a partition. The sector offset, sector size, and device number of the actual device relative to the partition are read from the files in this directory. The start and end positions of all metadata intervals in the original metadata interval set on the device corresponding to the device number are increased by the sector offset multiplied by the sector size to obtain a new metadata interval set. The device number of the actual device is used as the key, and the new metadata interval set is used as the value, and these are saved as a new key-value pair. If a dm directory exists in the directory, it indicates that the device corresponding to the device number is a mapped device. The actual device number and mapping relationship of the mapped actual device are obtained through the mapping relationship table saved by the system. The interval set corresponding to the metadata interval set on the device corresponding to the device number is calculated on the actual device based on the mapping relationship. The actual device number of the actual device is used as the key, and the metadata interval set on the actual device is used as the value, and these are saved as a new key-value pair. If the `device / wwid` file exists in the directory and is readable, it indicates that the device corresponding to the device number is a standard SCSI device. The `device / wwid` file is read to obtain the SCSI disk number (WWID) of the corresponding standard SCSI device. The WWID is used as the key, and the metadata range set on the device corresponding to the device number is used as the value, and these are saved as a new key-value pair. If the file in the directory indicates that the device corresponding to the device number is another supported device, the supported device is obtained. The actual device number of that device is used as the key, and the original data of the metadata range set on the device corresponding to the device number, or the data after a specified format conversion, is used as the value, and these are saved as a new key-value pair. If the actual device in the above conversion process is a partition, a mapped device, or one of other supported devices, the directory named after the device number used as the key in the new key-value pair is found again in the ` / sys / dev / block / ` directory, and the conversion is performed cyclically according to the above rules to obtain new key-value pairs until the actual device is a standard SCSI device. If the device corresponding to the device number is an unsupported device, the device is ignored.It should be noted that in this embodiment, the process first determines whether the device corresponding to the device number is a partition. If it is not a partition, the process then determines whether the device corresponding to the device number is a mapped device. If it is not a mapped device, the process then determines whether the device corresponding to the device number is a standard SCSI device. Only if it is not a standard SCSI device is the process then determined whether the device corresponding to the device number is another supported device. However, in other embodiments, the order in which the device type of the device corresponding to the device number is determined can be shuffled without affecting the accuracy of the metadata set conversion.

[0056] To reduce the security risks introduced by the kernel-internal and external interaction interfaces, in step S3 of this embodiment, the user space program loads the kernel space program and passes the acquired information to the kernel space program, which includes: mounting the kernel space program to the entry point of the submit_bio function through the BPF system call provided by the Linux kernel, and passing the new key-value pairs and file system type address range mapping map to the kernel space program through BPF mapping. The kernel space program is a verified EBPF program that is mounted to the entry point of the submit_bio function in the kernel space.

[0057] To ensure efficient monitoring of write behavior to the file system metadata area on a given block and reduce the difficulty of troubleshooting, step S4 in this embodiment includes:

[0058] S4.1 After any process calls the submit_bio function, it obtains the parameters of the submit_bio function through the PT_REGS_PARM1_CORE macro;

[0059] S4.2, convert the parameters of the function submit_bio into a bio structure, and use the bi_opf node in the bio structure, which is used to store the operation flag and request type, to determine whether the current IO event is a write operation. If it is not a write operation, ignore the current event; otherwise, jump to step S4.3.

[0060] S4.3 Obtain the target device information of this IO event through the block device node bi_bdev of the bio structure, parse the WWID of the IO event to be written to the corresponding actual backend storage device, and calculate the interval to be written to the corresponding actual backend storage device; if parsing the WWID fails or calculating the interval to the corresponding actual backend storage device fails, then ignore this event.

[0061] S4.4 Determine whether the actual back-end storage device WWID corresponding to the target block device of this IO event exists in the BPF mapping of the kernel space program. If it does not exist in the BPF mapping of the kernel space program, ignore the IO event; otherwise, jump to step S4.5.

[0062] S4.5, confirm whether this IO event involves the metadata area, including: using the actual backend storage device WWID corresponding to the target block device as the key to obtain the corresponding metadata range set from the BPF mapping, traversing all elements in the obtained metadata range set, and comparing each element with the range written to the actual device in this IO event. If there is no overlap, then this IO event does not involve the metadata area and this IO event is ignored; otherwise, proceed to step S4.6.

[0063] S4.6, Analyze whether the call stack of this IO event is valid, including: obtaining the file system type with overlapping metadata ranges, and obtaining the memory address range of the corresponding module of the file system type from the BPF mapping; obtaining the call stack of this call through the bpf_get_stack function and storing it in the array arr; traversing the function pointers in the array arr and comparing them one by one with the memory address range of the corresponding module of the file system type obtained from the BPF mapping. If a function pointer is within the address range, the call stack of this IO event is considered valid, the event is ignored, and the process ends and exits; otherwise, this IO event is determined to be a risky and suspicious event, and the process jumps to step S4.7.

[0064] S4.7 collects information related to this IO event and passes it to the user-space program.

[0065] As an optional implementation, in step S4.3 of this embodiment, the method for parsing the WWID of the current IO event written to the corresponding actual backend storage device and calculating the interval to be written to the corresponding actual backend storage device by the current IO event is as follows: First, the write interval [(starting sector number + offset) * sector size, (starting sector number + offset) * sector size + interval size)] is calculated using the starting sector number and offset value recorded by bi_bdev. Then, the device type of the target block device is determined by the address of gd->fops->open recorded by bi_bdev. If the target block device is a mapped device, the actual device and the actual device to which the current IO event is written are updated by the mapping table saved by the kernel. The interval is determined as follows: If it is a standard SCSI device, the WWID of the actual back-end storage device is obtained according to the SCSI standard, and the written interval is identified as the interval where the current IO event is written to the actual back-end storage device; if it is another supported device type, the interval where the current IO event is written to the actual device is obtained according to its device characteristics; if the actual device in the above conversion is a mapped device or one of the other supported device types, the interval where the current IO event is written to the actual device is converted again according to the above rules until the WWID of the actual back-end storage device and the interval where the current IO event is written to the actual back-end storage device are obtained; if the target block device or the actual device is an unsupported device, the parsing fails.

[0066] To ensure that the order of suspicious events is correctly recorded, in step S4.7, when collecting information related to the current IO event and passing it to the user space program, the kernel space program and the user space program transfer data through the ring buffer. Passing the information to the user space program means that the kernel space program organizes the information related to the current IO event into a structure and submits it to the ring buffer.

[0067] In addition, this embodiment also provides a Linux file system metadata monitoring system, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute a Linux file system metadata monitoring method.

[0068] In addition, this embodiment also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute a Linux file system metadata monitoring method via a processor.

[0069] In addition, this embodiment also provides a computer program product, including a computer program or instructions that are programmed or configured to execute a Linux file system metadata monitoring method via a processor.

[0070] Those skilled in the art will understand that the technical solutions provided by the embodiments of this application may take the form of a method, system, or computer program product. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create an implementation for the process. Figure 1 One or more processes and / or boxes Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0071] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for monitoring Linux file system metadata, characterized in that, This includes using a combination of user-space and kernel-space programs to monitor write operations to specific ranges of the target backend storage under an iSCSI environment: S1, The user-space program responds to the user's execution request carrying one or more specified block devices; S2, the user space program parses and obtains the actual back-end storage device WWID corresponding to the user-given block device, the location of the metadata to be monitored on the actual back-end storage device, and the file system type corresponding to these locations; S3, the user-space program loads the kernel-space program and passes the acquired information to the kernel-space program; S4, the kernel space program obtains the actual back-end storage device WWID corresponding to the target block device, the location of the written range on the actual back-end storage device, the call stack and the write time from the process context, matches it with the information passed by the user space program, filters out suspicious events, records the suspicious event information and passes it to the user space program; S5, the user space program records the received suspicious event information to a designated location.

2. The Linux file system metadata monitoring method according to claim 1, characterized in that, Step S2 includes: obtaining the path of a user-given block device, and performing the following steps for each given block device path: S2.1, attempt to obtain the device number of the given block device, and determine whether the device number was successfully obtained. If it is unsuccessful, ignore the block device and end; otherwise, jump to step S2.

2. S2.2, Loop through the list of supported file systems to determine whether the given block device contains a supported file system. If it does not contain a supported file system, ignore the block device and end; otherwise, jump to step S2.

3. S2.3, determine the location of the superblock on the given block device according to the type of file system contained in the given block device, read its superblock to parse the location information of the specified key metadata of the file system on the given block device, and represent it as a metadata interval. The data structure of the metadata interval includes the file system type, start position and end position. Integrate all the intervals represented by the metadata intervals into a metadata interval set, and merge the intervals of the same type that are adjacent at the beginning and end in the metadata interval set. Use the device number of the given block device as the key and the set of metadata intervals on the given block device as the value, and save them as key-value pairs. Read the start address and occupied space size of the file system module enumerated in this loop traversal from the / proc / modules file or parse it from the / proc / kallsyms file to obtain the address interval pair of the file system module in memory. The fields of the address interval pair include the start position and end position, and save it to the file system type address interval mapping map with the file system type enumeration as the key and the address interval pair as the value. S2.4, for the set of metadata intervals on a given block device in the key-value pair, perform user space device identification, convert the set of metadata intervals representing the location of metadata on the given user device into a set of metadata intervals representing the corresponding location of metadata on the actual backend storage device, and save it as a new key-value pair.

3. The Linux file system metadata monitoring method according to claim 2, characterized in that, Step S2.4 includes: A directory named after the device number (using the key-value pair as the key) can be found under the ` / sys / dev / block / ` directory; if a `partition` file exists in this directory, it indicates that the device corresponding to the device number is a partition. The sector offset, sector size, and device number of the actual device relative to the partition are read from the files in this directory. The start and end positions of all metadata intervals in the original metadata interval set on the device corresponding to the device number are increased by the sector offset multiplied by the sector size to obtain a new metadata interval set. The device number of the actual device is used as the key, and the new metadata interval set is used as the value, and these are saved as a new key-value pair; if a `dm` directory exists in the directory, it indicates that the device corresponding to the device number is a mapped device. The actual device number and mapping relationship of the mapped actual device are obtained through the mapping relationship table saved by the system. Based on the mapping relationship, the interval set corresponding to the metadata interval set on the device corresponding to the device number is calculated on the actual device. The actual device number of the actual device is used as the key, and the metadata interval set on the actual device is used as the value, and these are saved as a new key-value pair; if If the `device / wwid` file exists and is readable in the directory, it indicates that the device corresponding to the device number is a standard SCSI device. The `device / wwid` file is read to obtain the SCSI disk number (WWID) of the corresponding standard SCSI device. The WWID is used as the key, and the metadata range set on the device corresponding to the device number is used as the value, and these are saved as a new key-value pair. If the file in the directory indicates that the device corresponding to the device number is another supported device, the supported device is obtained. The actual device number of that device is used as the key, and the original data of the metadata range set on the device corresponding to the device number, or the data after a specified format conversion, is used as the value, and these are saved as a new key-value pair. If the actual device in the above conversion process is a partition, a mapped device, or one of other supported devices, the directory named after the device number used as the key in the new key-value pair is found again in the ` / sys / dev / block / ` directory, and the conversion is repeated according to the above rules to obtain new key-value pairs until the actual device is a standard SCSI device. If the device corresponding to the device number is an unsupported device, the device is ignored.

4. The Linux file system metadata monitoring method according to claim 2, characterized in that, Step S3, in which the user-space program loads the kernel-space program and passes the acquired information to the kernel-space program, includes: mounting the kernel-space program to the entry point of the submit_bio function through the BPF system call provided by the Linux kernel, and passing the new key-value pairs and file system type address range mapping map to the kernel-space program through BPF mapping. The kernel-space program is a verified EBPF program that is mounted to the entry point of the submit_bio function in the kernel space.

5. The Linux file system metadata monitoring method according to claim 4, characterized in that, Step S4 includes: S4.1 After any process calls the submit_bio function, it obtains the parameters of the submit_bio function through the PT_REGS_PARM1_CORE macro; S4.2, convert the parameters of the function submit_bio into a bio structure, and use the bi_opf node in the bio structure, which is used to store the operation flag and request type, to determine whether the current IO event is a write operation. If it is not a write operation, ignore the current event; otherwise, jump to step S4.

3. S4.3 Obtain the target block device information of this IO event through the block device node bi_bdev of the bio structure, parse the WWID of the IO event to be written to the corresponding actual backend storage device, and calculate the interval to be written to the corresponding actual backend storage device; if parsing the WWID fails or calculating the interval to the corresponding actual backend storage device fails, then ignore this event. S4.4 Determine whether the actual back-end storage device WWID corresponding to the target block device of this IO event exists in the BPF mapping of the kernel space program. If it does not exist in the BPF mapping of the kernel space program, ignore the IO event; otherwise, jump to step S4.

5. S4.5, confirm whether this IO event involves the metadata area, including: using the actual backend storage device WWID corresponding to the target block device as the key to obtain the corresponding metadata range set from the BPF mapping, traversing all elements in the obtained metadata range set, and comparing each element with the range written to the corresponding actual backend storage device in this IO event. If there is no overlap, then this IO event does not involve the metadata area and this IO event is ignored; otherwise, proceed to step S4.

6. S4.6, Analyze whether the call stack of this IO event is valid, including: obtaining the file system type with overlapping metadata ranges, and obtaining the memory address range of the corresponding module of the file system type from the BPF mapping; obtaining the call stack of this call through the bpf_get_stack function and storing it in the array arr; traversing the function pointers in the array arr and comparing them one by one with the memory address range of the corresponding module of the file system type obtained from the BPF mapping. If a function pointer is within the address range, the call stack of this IO event is considered valid and this event is ignored; otherwise, this IO event is determined to be a risky and suspicious event, and the process jumps to step S4.

7. S4.7 collects information related to this IO event and passes it to the user-space program.

6. The Linux file system metadata monitoring method according to claim 5, characterized in that, In step S4.3, the WWID of the IO event written to the corresponding actual backend storage device is parsed, and the interval to be written to the corresponding actual backend storage device is calculated as follows: First, the starting sector number and offset value recorded by bi_bdev are used to calculate the writing interval [(starting sector number + offset) * sector size, (starting sector number + offset) * sector size + interval size)]. Then, the device type of the target block device is determined by the address of gd->fops->open recorded by bi_bdev. If the target block device is a mapped device, the actual device and the interval to be written to the actual device by the mapping table saved by the kernel are updated. If it is a standard SCSI device, the WWID of the actual back-end storage device is obtained according to the SCSI standard, and the write range is identified as the range in which the current IO event is written to the actual back-end storage device; If it is another supported device type, the range where the current IO event is written to the actual device is obtained by parsing its device characteristics; if the actual device in the above conversion is a mapped device or one of other supported device types, the range where the current IO event is written to the actual device is converted again according to the above rules until the WWID of the actual backend storage device and the range where the current IO event is written to the actual backend storage device are obtained. If the target block device or the actual device is an unsupported device, the resolution will fail.

7. The Linux file system metadata monitoring method according to claim 5, characterized in that, In step S4.7, when collecting information related to the current I / O event and passing it to the user space program, the kernel space program and the user space program exchange data through a ring buffer. The passage to the user space program means that the kernel space program organizes the information related to the current I / O event into a structure and submits it to the ring buffer.

8. A Linux file system metadata monitoring system, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to execute the Linux file system metadata monitoring method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Linux file system metadata monitoring method of any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Linux file system metadata monitoring method of any one of claims 1 to 7 via a processor.

Images