Metadata monitoring method and system for linux file system and medium

Abstract

The invention discloses a linux file system metadata monitoring method, a linux file system metadata monitoring system and a medium. The method comprises the steps that a user space program responds to an execution request which is carried by a user and specifies one or more block devices; the user space program analyzes and obtains an actual back-end storage device WWID corresponding to the given block device and the position and the file system type of the metadata to be monitored on the actual back-end storage device; the user space program transmits the acquired information to a kernel space program; the kernel space program obtains an actual rear-end storage device WWID corresponding to the target block device, the position of the write-in range on the actual rear-end storage device, the call stack and the write-in time, the WWID, the position, the call stack and the write-in time are matched with information transmitted by the user space program, and suspicious events are screened out and transmitted to the user space program; and recording the received suspicious event information to a specified position. According to the method, suspicious events can be found and recorded in time, and reasons for metadata destruction of the file system can be checked conveniently.

Description

Technical Field

[0001] The present invention relates to the technical field of file system metadata monitoring methods, and in particular to a Linux file system metadata monitoring method, system and medium. Background Art

[0002] In a server environment based on Linux system, in order to improve the reliability and flexibility of storage, ISCSI technology and MULTIPATH technology are usually used in combination to remotely share block devices through the network. Ideally, ISCSI technology will create multiple block devices corresponding to the same backend storage in the system, and MULTIPATH technology will create a device mapping based on these block devices corresponding to the same backend storage. Finally, the application creates a file system on this device mapping and uses it. However, the combination of these two technologies is not an atomic operation. The application may use the block device created by ISCSI when ISCSI has created multiple block devices but MULTIPATH has not created device mappings for these block devices in time. The application itself cannot distinguish whether the multiple block devices it uses correspond to the same backend storage, which may cause the same backend storage to be used by multiple users at the same time, ultimately destroying the data consistency on the backend storage.

[0003] Since there is a file system metadata cache on the Linux system, and traditional file systems (such as EXT4 and XFS) are designed only for single-user scenarios, these file systems usually do not check whether the cache is consistent with the data on the physical storage. This means that when the data on the backend storage is damaged, the file system cannot immediately detect it, and it may even appear to be working normally, but the file system is no longer reliable. It is not until the file system is remounted and the data is re-read from the backend storage that an error is reported indicating that the file system data on the backend storage has been damaged. At this point, it has been some time since the failure occurred. On the one hand, losses may occur during this period due to data damage or loss. On the other hand, the failure environment no longer exists, which will cause great trouble to the problem troubleshooting.

[0004] The above problems are usually avoided through operation and maintenance measures, such as actively prohibiting applications from directly using block devices created by ISCSI, or delaying the start of applications for an estimated period of time to wait for the device mapping of MULTIPATH to be created. However, this relies on the initiative of the operation and maintenance personnel. If a configuration error occurs, the problem will still occur and cannot be traced.

[0005] XFS file system and EXT4 file system have their own mitigation solutions for the above problems at the file system level. The mitigation solution for XFS file system is to prohibit mounting XFS file systems with the same UUID on the same machine; the solution for EXT4 file system is MMP (Multiple mount protection), that is, setting a flag bit that is refreshed at a certain time on the block device, waiting for 2 refresh cycles when mounting, if this flag bit is refreshed, it indicates that the file system is in use, and it will refuse to mount again. These two solutions can solve most of the reuse problems at the file system level, but when the application uses the device at the block level (for example, the process bypasses the file system and directly writes data to the block device), these solutions are powerless.

[0006] With the gradual improvement of kernel tracing technologies such as ftrace, EBPF, kprobe, and tracepoint on the Linux system, it has become a reality to obtain kernel data and monitor the process's access to the target block device based on the obtained kernel data. For example, the Chinese patent document with application number CN201310512066.4 discloses a disk access request monitoring system and method in a virtualized environment. By using tracepoint technology to monitor the access of a specific virtual machine to a disk, the virtual machine to which the process belongs can be determined, and the IO operation of the virtual machine's process on a specific disk can be recorded. The Chinese patent document with application number CN202111344516.4 discloses a Linux system protection method based on ftrace technology, which can determine the IO of a specific sector of a specified disk and reconstruct the request to protect the target sector. However, the above two methods cannot be used to determine whether the target block device operated by the process corresponds to the same back-end storage device in the ISCSI scenario, whether the process saves the metadata of the file system on the disk in the back-end storage write location, and whether the write call of the process is legal. When the file system is damaged, it is difficult to trace the source to find out the cause of the damage. Summary of the invention

[0007] Technical problem to be solved by the present invention: In view of the above-mentioned problems in the prior art, a method, system and medium for monitoring metadata of a Linux file system are provided. The present invention aims to solve the problems that the existing means of monitoring process access to a target block device cannot determine whether the block device operated by the process corresponds to the same back-end storage device as the monitored block device, cannot determine whether the location where the process writes to the back-end storage device stores the metadata of the file system on the disk, and cannot determine whether the write call of the process is legal. The present invention can realize the monitoring of file system metadata destruction behavior in an ISCSI scenario, can timely discover file system damage, and record the scene for easy tracing.

[0008] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0009] A Linux file system metadata monitoring method includes using a user space program and a kernel space program in combination to monitor write operations to a specific interval of a target backend storage in an ISCSI environment:

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

[0011] S2, the user space program parses and obtains the actual backend storage device WWID corresponding to the user-given block device and the location of the metadata to be monitored on the actual backend storage device and the file system types 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 backend storage device WWID corresponding to the target block device, the location of the written range on the actual backend storage device, the call stack and the writing time from the process context, matches them 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 a designated location.

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

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

[0017] S2.2, loop through the supported file system list 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 position of the super block on the given block device according to the type of file system contained in the given block device, read its super block to parse the location information of the specified key metadata of the file system on the given block device, and represent it with a metadata interval, the data structure of the metadata interval includes the file system type, the starting position and the ending position, integrate the intervals represented by all metadata intervals into a metadata interval set, and merge the first adjacent intervals of the same type in the metadata interval set, use the device number of the given block device as the key key, the metadata interval set on the given block device as the value value and save them as a key-value pair key-value; read from the / proc / modules file or parse from the / proc / kallsyms file the starting address and occupied space size of the file system module enumerated in this loop traversal, obtain the address interval pair of the file system module in the memory, the fields of the address interval pair include the starting position and the ending position, and save them to the file system type address interval mapping map with the file system type enumeration as the key key and the address interval pair as the value value;

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

[0020] Optionally, step S2.4 includes: a directory named with the device number as the key key in the key-value pair key-value can be found in the / sys / dev / block / directory; if a partition file exists in the directory, it indicates that the device corresponding to the device number is a partition, and the sector offset, sector size and device number of the partition relative to the actual device are read from the files in the directory respectively, and the starting position and end position 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, and the device number of the actual device is used as the key key and the new metadata interval set as the value value and saved as a new key-value pair key-value; if a dm directory exists in the directory, indicating that the device corresponding to the device number is a mapped device, then the actual device number and mapping relationship of the mapped actual device are obtained through the mapping relationship table saved by the system, and the interval set corresponding to the metadata interval set on the device corresponding to the device number on the actual device is calculated according to the mapping relationship, and the actual device number of the actual device is used as the key key and the metadata interval set on the actual device is used as the value value and saved as a new key-value pair key-value; If the device / wwid file exists in the directory and can be read, it indicates that the device corresponding to the device number is a standard SCSI device. Then, the device / wwid file is read to obtain the SCSI disk number WWID of the corresponding standard SCSI device, and the WWID is used as the key key, and the metadata interval set on the device corresponding to the device number is used as the value value and saved as a new key-value pair key-value; if the file in the directory indicates that the device corresponding to the device number is other supported devices, then the supported device is obtained, the actual device number of the device is used as the key key, and the original data of the metadata interval set on the device corresponding to the device number or the data converted to a specified format is used as the value value and saved as a new key-value pair key-value; if the actual device in the above conversion process is a partition, a mapped device, or one of the other supported devices, then the directory named with the device number of the new key-value pair key-value as the key is found again in the / sys / dev / block / directory, and a new key-value pair key-value is obtained by cyclic conversion according to the above rules 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, including: mounting the kernel space program to the entry of the submit_bio function through the BPF system call provided by the Linux kernel, and passing the new key-value pair key-value and the file system type address interval mapping map to the kernel space program in the form of BPF mapping, wherein the kernel space program is a verified EBPF program mounted in the kernel space to the function entry of the submit_bio function.

[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 determine whether this IO event is a write operation through the node bi_opf in the bio structure that is used to store the operation flag and request type. If it is not a write operation, ignore this 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 actual backend storage device written by this IO event, and calculate the interval written by this IO event on the corresponding actual backend storage device; if the WWID parsing fails or the interval calculation on the corresponding actual backend storage device fails, ignore this event;

[0026] S4.4, determine whether the actual backend 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 key to obtain the corresponding metadata interval set from the BPF map, traversing all elements in the obtained metadata interval set, and comparing them one by one with the intervals written to the corresponding actual backend storage device by this IO event. If there is no overlap, then this IO event write does not involve the metadata area, and ignore this IO event, otherwise jump to step S4.6;

[0028] S4.6, analyzing whether the call stack of this IO event is legal, including: obtaining the file system type of the metadata interval with the overlapping part, and obtaining the address interval of the module corresponding to the file system type in the memory from the BPF map; obtaining the call stack of this call through the bpf_get_stack function, and saving it in the array arr; traversing the function pointers in the array arr and comparing them one by one with the address interval of the module corresponding to the file system type in the memory obtained from the BPF map. If a function pointer is within the address interval, the call stack of this IO event is considered to be legal and the event is ignored. Otherwise, the IO event is determined to be a risky suspicious event and jump to step S4.7;

[0029] S4.7, collect information related to this IO event and pass it to the user space program.

[0030] Optionally, in step S4.3, the WWID of the actual back-end storage device corresponding to the current IO event is parsed, and the interval of the current IO event written to the corresponding actual back-end storage device is calculated as follows: first, the write interval [(starting sector number + offset) * sector size, (starting sector number + offset) * sector size + interval size)] is calculated through the starting sector number and offset value recorded by bi_bdev, and then the device type of the target block device is determined through 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 written to the actual device by this IO event are updated through the mapping table saved by the kernel; if For standard SCSI devices, the WWID of the actual backend storage device is obtained according to the SCSI standard, and the write interval is identified as the interval where this IO event is written to the actual backend storage device; if it is other supported device types, the interval where this 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 mapping device or one of other supported device types, the interval where this 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 interval where this 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, this parsing fails.

[0031] Optionally, when collecting relevant information about the current IO event and passing it to the user space program in step S4.7, data is transferred between the kernel space program and the user space program through the ring buffer, and the transfer to the user space program means that the kernel space program organizes the relevant information about the current IO event into a structure and submits it to the buffer ring buffer.

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

[0033] In addition, the present invention also provides a computer-readable storage medium, in which a computer program or instruction is stored. The computer program or instruction is programmed or configured to execute the Linux file system metadata monitoring method through a processor.

[0034] In addition, the present invention also provides a computer program product, including a computer program or an instruction, wherein the computer program or the instruction is programmed or configured to execute the Linux file system metadata monitoring method through a processor.

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

[0036] The present invention comprises the following steps: S1, a user space program responds to an execution request of a user carrying one or more designated block devices; S2, the user space program parses and obtains the actual back-end storage device WWID corresponding to the block device given by the user and 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 transmits 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, if the IO event is 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, compares with the information transmitted by the user space program, filters out suspicious events, records the suspicious event information and transmits it to the user space program; S5, the user space program records the received suspicious event information to the designated location. The present invention can solve the problems that the existing means of monitoring the access of a process to a target block device cannot determine whether the block device operated by the process corresponds to the same back-end storage device as the monitored block device, cannot determine whether the location written by the process to the back-end storage device stores the metadata of the file system on the disk, and cannot determine whether the write call of the process is legal. The present invention can realize the monitoring of the destruction behavior of the file system metadata in the ISCSI scenario, can timely discover and record suspicious events, and is convenient for troubleshooting the cause of the destruction of the file system metadata. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 2Schematic diagram of the process of step S2 of the embodiment of the present invention.

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

[0040] Figure 4 4 is a flow chart of step S2.4 of an embodiment of the present invention. DETAILED DESCRIPTION

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

[0042] like Figure 1 As shown, the Linux file system metadata monitoring method of this embodiment includes using a user space program and a kernel space program to monitor the write operation to a specific interval of the target backend storage in the ISCSI environment:

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

[0044] S2, the user space program parses and obtains the WWID of the actual backend storage device corresponding to the block device given by the user, the location of the metadata to be monitored on the actual backend storage device, and the file system types 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 backend storage device WWID corresponding to the target block device, the location of the written range on the actual backend storage device, the call stack and the writing time from the process context, matches them 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 a designated location.

[0048] The method of this embodiment can solve the problems that the existing means of monitoring the access of the process to the target block device cannot determine whether the block device operated by the process corresponds to the same back-end storage device as the monitored block device, cannot determine whether the location written by the process to the back-end storage device stores the metadata of the file system on the disk, and cannot determine whether the write call of the process is legal. It can realize the monitoring of the destruction behavior of the file system metadata in the ISCSI scenario, can timely discover and record suspicious events, and facilitate the investigation of the cause of the destruction of the file system metadata.

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

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

[0051] S2.2, loop through the supported file system list 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, according to the type of the file system of the given block device, determine the location of the super block on the given block device, read its super block to parse the location information of the specified key metadata of the file system on the given block device, and express it in a metadata interval. The data structure of the metadata interval includes the file system type, the starting position and the ending position (see Figure 3 ), integrate the intervals represented by all metadata intervals into a metadata interval set, and merge the first adjacent intervals of the same type in the metadata interval set, use the device number of the given block device as the key key, the metadata interval set on the given block device as the value value and save them as a key-value pair key-value; if the file system is compiled and used in module mode, read the starting address and occupied space size of the file system module enumerated in this loop traversal from the / proc / modules file; if the file system is directly compiled into the kernel, parse the address interval pair of the file system module in the memory from the / proc / kallsyms file, the fields of the address interval pair include the starting position and the ending position, and save them to the file system type enumeration as the key key and the address interval pair as the value value in the file system type address interval mapping map;

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

[0054] It should be noted that in step S2.4, the designated key metadata refers to the metadata that has a greater impact on the operation of the file system after being damaged. The specific metadata is selected according to the needs. For example, for the ext4 file system, the designated key metadata includes the super block, block group descriptor, and the block bitmap, iNode bitmap and iNode list of each block group. For the xfs file system, the designated key metadata includes the super block, agf, agi, agfl, ABTB, ABTC, IABT of each AG.

[0055] like Figure 4As shown, in order to ensure the accuracy of metadata set conversion, step S2.4 of this embodiment includes: a directory named with the device number as the key key of the key-value pair key-value can be found in the / sys / dev / block / directory; if a partition file exists in the directory, it indicates that the device corresponding to the device number is a partition, and the sector offset, sector size and device number of the partition relative to the actual device are read from the files in the directory respectively, and the starting position and the ending position 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, and the device number of the actual device is used as the key key and the new metadata interval set is used as the value value and saved as a new key-value pair key-value; if a dm directory exists in the directory, it indicates that the device corresponding to the device number is a mapped device, then the actual device number and the mapping relationship of the mapped actual device are obtained through the mapping relationship table saved by the system, and the interval set corresponding to the metadata interval set on the device corresponding to the device number on the actual device is calculated according to the mapping relationship, and the actual device number of the actual device is used as the key key and the metadata interval set on the actual device is used as the value value and saved as a new key-value pair k. ey-value; if the device / wwid file exists in the directory and can be read, indicating that the device corresponding to the device number is a standard SCSI device, then read the device / wwid file to obtain the SCSI disk number WWID of the corresponding standard SCSI device, and use the WWID as the key key and the metadata interval set on the device corresponding to the device number as the value value and save them as a new key-value pair key-value; if the file in the directory indicates that the device corresponding to the device number is other supported devices, then obtain the supported device, use the actual device number of the device as the key key, use the original data of the metadata interval set on the device corresponding to the device number or the data converted to the specified format as the value value and save them as a new key-value pair key-value; if the actual device in the above conversion process is a partition, a mapped device, or one of the other supported devices, then find the directory named with the device number of the new key-value pair key-value as the key in the / sys / dev / block / directory again, and perform cyclic conversion according to the above rules to obtain a new key-value pair key-value until the actual device is a standard SCSI device; if the device corresponding to the device number is an unsupported device, ignore the device.It should be noted that, in this embodiment, it is first determined whether the device corresponding to the device number is a partition. After determining that it is not a partition, it is then determined whether the device corresponding to the device number is a mapped device. After determining that it is not a mapped device, it is then determined whether the device corresponding to the device number is a standard SCSI device. After determining that it is not a standard SCSI device, it is determined whether the device corresponding to the device number is other supported devices. However, in other embodiments, the order of determining the device type of the device corresponding to the device number can be disrupted without affecting the accuracy of the metadata set conversion.

[0056] In order to reduce the security risks introduced by the intra-kernel and extra-kernel 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, including: mounting the kernel space program to the entry of the submit_bio function through the BPF system call provided by the Linux kernel, and passing the new key-value pair key-value and the file system type address interval mapping map to the kernel space program in the form of BPF mapping. The kernel space program is a verified EBPF program mounted in the kernel space to the function entry of the submit_bio function.

[0057] To ensure efficient monitoring of the write behavior of the file system metadata area on a given block and reduce the difficulty of troubleshooting, step S4 of 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 determine whether this IO event is a write operation through the node bi_opf in the bio structure that is used to store the operation flag and request type. If it is not a write operation, ignore this 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 actual backend storage device written by this IO event, and calculate the interval written by this IO event on the corresponding actual backend storage device; if the WWID parsing fails or the interval calculation on the corresponding actual backend storage device fails, ignore this event;

[0061] S4.4, determine whether the actual backend 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 key to obtain the corresponding metadata interval set from the BPF map, traversing all elements in the obtained metadata interval set, and comparing them one by one with the intervals written to the actual device by this IO event. If there is no overlap, then this IO event write does not involve the metadata area, and ignore this IO event, otherwise jump to step S4.6;

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

[0064] S4.7, collect information related to this IO event and pass it to the user space program.

[0065] As an optional implementation, in step S4.3 of this embodiment, the WWID of the actual back-end storage device corresponding to the current IO event is parsed, and the interval of the current IO event written to the corresponding actual back-end storage device is calculated as follows: first, the write interval [(starting sector number + offset) * sector size, (starting sector number + offset) * sector size + interval size)] is calculated through the starting sector number and offset value recorded by bi_bdev, and then the device type of the target block device is determined through the address of gd->fops->open recorded by bi_bdev. If the target block device is a mapped device, the actual device is updated through the mapping table saved by the kernel and the current IO event is written to the actual device. interval; 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 interval is identified as the interval where this IO event is written to the actual back-end storage device; if it is other supported device types, the interval where this 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 mapping device or one of other supported device types, the interval where this 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 this 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, this parsing fails.

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

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

[0068] In addition, this embodiment also provides a computer-readable storage medium, in which a computer program or instruction is stored. The computer program or instruction is programmed or configured to execute the Linux file system metadata monitoring method through a processor.

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

[0070] Those skilled in the art will appreciate that the technical solutions provided by the embodiments of the present application may be in the form of methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the process. Figure 1 A process or multiple processes and / or boxes Figure 1These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0071] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A Linux file system metadata monitoring method, characterized in that: This includes using a combination of user space programs and kernel space programs to monitor write operations to specific intervals of target backend storage in an ISCSI environment: S1, the user space program responds to the user's execution request with one or more specified block devices; S2, the user space program parses and obtains the actual backend storage device WWID corresponding to the user-given block device and the location of the metadata to be monitored on the actual backend storage device and the file system types 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 backend storage device WWID corresponding to the target block device, the location of the written range on the actual backend storage device, the call stack and the writing time from the process context, matches them 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 the block device given by the user, and performing the following steps for each path of the given block device: S2.1, try to obtain the device number of a given block device, and determine whether the device number is obtained successfully. If it is unsuccessful, ignore the block device and end; otherwise, jump to step S2.2; S2.2, loop through the supported file system list 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 position of the super block on the given block device according to the type of file system contained in the given block device, read its super block to parse the location information of the specified key metadata of the file system on the given block device, and represent it with a metadata interval, the data structure of the metadata interval includes the file system type, the starting position and the ending position, integrate the intervals represented by all metadata intervals into a metadata interval set, and merge the first adjacent intervals of the same type in the metadata interval set, use the device number of the given block device as the key key, the metadata interval set on the given block device as the value value and save them as a key-value pair key-value; read from the / proc / modules file or parse from the / proc / kallsyms file the starting address and occupied space size of the file system module enumerated in this loop traversal, obtain the address interval pair of the file system module in the memory, the fields of the address interval pair include the starting position and the ending position, and save them to the file system type address interval mapping map with the file system type enumeration as the key key and the address interval pair as the value value; S2.4, perform user space device identification on the metadata interval set on the given block device in the key-value pair key-value, convert the metadata interval set representing the location of the metadata on the user-given device into the metadata interval set representing the corresponding location of the metadata on the actual backend storage device and save it as a new key-value pair key-value.

3. The Linux file system metadata monitoring method according to claim 2, characterized in that: Step S2.4 includes: a directory named with the device number as the key key in the key-value pair key-value can be found in the / sys / dev / block / directory; if a partition file exists in the directory, it indicates that the device corresponding to the device number is a partition, and the sector offset, sector size and device number of the partition relative to the actual device are read from the files in the directory respectively, and the starting position and the ending position 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, and the device number of the actual device is used as the key key and the new metadata interval set as the value value and saved as a new key-value pair key-value; if a dm directory exists in the directory, indicating that the device corresponding to the device number is a mapped device, the actual device number and the mapping relationship of the mapped actual device are obtained through the mapping relationship table saved by the system, and the interval set corresponding to the metadata interval set on the device corresponding to the device number on the actual device is calculated according to the mapping relationship, and the actual device number of the actual device is used as the key key and the metadata interval set on the actual device is used as the value value and saved as a new key-value pair key-value; if If the device / wwid file exists in the directory and can be read, it indicates that the device corresponding to the device number is a standard SCSI device. Then, the device / wwid file is read to obtain the SCSI disk number WWID of the corresponding standard SCSI device, and the WWID is used as the key key, and the metadata interval set on the device corresponding to the device number is used as the value value and saved as a new key-value pair key-value; if the file in the directory indicates that the device corresponding to the device number is other supported devices, then the supported device is obtained, the actual device number of the device is used as the key key, and the original data of the metadata interval set on the device corresponding to the device number or the data converted to a specified format is used as the value value and saved as a new key-value pair key-value; if the actual device in the above conversion process is a partition, a mapped device, or one of the other supported devices, the directory named with the device number of the new key-value pair key-value as the key is found again in the / sys / dev / block / directory, and a new key-value pair key-value is obtained by cyclic conversion according to the above rules 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: In step S3, the user space program loads the kernel space program and passes the acquired information to the kernel space program, including: mounting the kernel space program to the entry of the submit_bio function through the BPF system call provided by the Linux kernel, and passing the new key-value pair key-value and the file system type address interval mapping map to the kernel space program in the form of BPF mapping, wherein the kernel space program is a verified EBPF program mounted in the kernel space to the function entry of the submit_bio function.

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 determine whether this IO event is a write operation through the node bi_opf in the bio structure that is used to store the operation flag and request type. If it is not a write operation, ignore this 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 actual backend storage device written by this IO event, and calculate the interval written by this IO event on the corresponding actual backend storage device; if the WWID parsing fails or the interval calculation on the corresponding actual backend storage device fails, ignore this event; S4.4, determine whether the actual backend 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 key to obtain the corresponding metadata interval set from the BPF map, traversing all elements in the obtained metadata interval set, and comparing them one by one with the intervals written to the corresponding actual backend storage device by this IO event. If there is no overlap, then this IO event write does not involve the metadata area, and ignore this IO event, otherwise jump to step S4.6; S4.6, analyzing whether the call stack of this IO event is legal, including: obtaining the file system type of the metadata interval with the overlapping part, and obtaining the address interval of the module corresponding to the file system type in the memory from the BPF map; obtaining the call stack of this call through the bpf_get_stack function, and saving it in the array arr; traversing the function pointers in the array arr and comparing them one by one with the address interval of the module corresponding to the file system type in the memory obtained from the BPF map. If a function pointer is within the address interval, the call stack of this IO event is considered to be legal and the event is ignored. Otherwise, the IO event is determined to be a risky suspicious event and jump to step S4.7; S4.7, collect information related to this IO event and pass 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 actual backend storage device corresponding to the IO event is parsed, and the interval of the IO event written to the corresponding actual backend storage device is calculated as follows: first, the write interval [(starting sector number + offset) * sector size, (starting sector number + offset) * sector size + interval size)] is calculated through the starting sector number and offset value recorded by bi_bdev, and then the device type of the target block device is determined through the address of gd->fops->open recorded by bi_bdev. If the target block device is a mapping device, the actual device and the interval written to the actual device by this IO event are updated through the mapping table saved by the kernel; If it is a standard SCSI device, the WWID of the actual backend storage device is obtained according to the SCSI standard analysis, and the write interval is identified as the interval in which this IO event is written to the actual backend storage device; If it is another supported device type, the device characteristics are analyzed to obtain the interval where this IO event is written to the actual device; if the actual device in the above conversion is a mapped device or one of other supported device types, the interval where this 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 interval where this IO event is written to the actual backend storage device are obtained; If the target block device or actual device is an unsupported device, the parsing fails.

7. The Linux file system metadata monitoring method according to claim 5, characterized in that: When collecting the information related to the current IO event and passing it to the user space program in step S4.7, data is transferred between the kernel space program and the user space program through the ring buffer. The transfer 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 buffer ring buffer.

8. A Linux file system metadata monitoring system, comprising a microprocessor and a memory connected to each other, 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 having a computer program or instruction stored therein, characterized in that: The computer program or instruction is programmed or configured to execute the Linux file system metadata monitoring method described in any one of claims 1 to 7 through a processor.

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

Images