File system monitoring method based on file path

Abstract

The invention discloses a file path-based file system monitoring method, which comprises the following steps of: acquiring a path to be monitored, and monitoring inode in the path to be monitored through an inotify interface. According to the method, the monitoring paths serve as monitoring objects, the mapping relation between each monitoring path and the inode in the monitoring library is established, each monitoring path points to the corresponding inode, and when the file in the monitoring paths is modified due to user operation, the mapping relation and the inode in the monitoring library can be updated in time, so that the dynamic monitoring of the monitoring paths is ensured, and the user experience is improved. The problem that in the prior art, inode is deleted, renamed, replaced by a new file and the like, at the moment, a user program needs to reestablish a monitoring point, and the operation is troublesome is solved; when the mounting directory is unloaded, all the inode belonging to the mounting directory in the mapping table is automatically cleaned and released, so that the inode which is not unloaded is prevented from being mistakenly monitored, the automatic cleaning of the monitoring library is also realized, and the waste of system resources is avoided.

Description

Technical Field

[0001] The invention belongs to the technical field of file monitoring, and in particular relates to a file system monitoring method based on a file path. Background Art

[0002] File system monitoring refers to monitoring and receiving the operation inodes of specified directories or files, such as file opening, closing, writing, reading, modifying attributes, deleting, moving, etc. Effective monitoring of the file system is one of the core functions of most system management software. Currently, there are three main file system monitoring implementation solutions:

[0003] 1) Implement file system monitoring based on inotify. inotify is a standard file system monitoring interface for the Linux operating system. User programs can use this interface to specify the directory or file to be monitored and obtain its operation inode; however, inotify actually monitors the inode of the file, so when the inode is switched, the monitoring will fail (such as the monitored file is deleted, renamed, replaced by a new file, etc.). At this time, the user program needs to re-establish the monitoring point, which is troublesome.

[0004] 2) Regularly scan the file system data through the user-mode daemon process, record the historical status of the file system and obtain the operation inode of the file system by comparing it; this solution cannot read the operation inode of the file system in real time, and the scanning process will cause a certain load on the system, which may affect the work of other programs in serious cases; the types of operation inodes that can be monitored are relatively limited, and can only detect changes in file content, but cannot detect operations such as file opening, closing, and reading that do not affect the file data content.

[0005] 3) Customize the operating system kernel, record all file operations in the kernel and write them into log files. User programs retrieve log files to obtain the file system operation inode. This solution requires user programs to regularly retrieve log files to obtain the latest operation logs, so the complexity of user programs is relatively high. In addition, retrieving kernel log files involves hard disk IO operations, so the response delay is higher than inotify, and the real-time performance is relatively insufficient. Summary of the invention

[0006] The purpose of the present invention is to solve the problem raised in the background technology and to propose a file system monitoring method based on file path.

[0007] To achieve the above object, the technical solution adopted by the present invention is: The present invention proposes a file system monitoring method based on file path, comprising: Get the path to be monitored, monitor the inodes in the path to be monitored through the inotify interface, and store the monitored inodes in the monitoring library of the inotify interface; Create a one-to-one mapping relationship between the path to be monitored and the inode in the monitoring library to form a mapping table; When the path to be monitored is deleted, the corresponding mapping relationship and the corresponding inode in the monitoring library are deleted; When the inode under the path to be monitored is modified, the mapping relationship corresponding to the mapping table and the corresponding inode in the monitoring library are updated and modified.

[0008] Preferably, the inode is a file or a directory.

[0009] Preferably, when the inode under the path to be monitored is deleted, the mapping relationship corresponding to the inode in the mapping table is deleted, and the corresponding inode in the monitoring library is deleted.

[0010] Preferably, when the inode under the path to be monitored is renamed, first determine whether the inode under the monitoring path is removed, if removed, delete the mapping relationship corresponding to the inode in the mapping table, and delete the corresponding inode in the monitoring library; If it has not been removed, the mapping relationship in the mapping table and the corresponding inode in the monitoring library are updated to the renamed inode.

[0011] Preferably, when a new inode is created under the path to be monitored, a mapping relationship between the path to be monitored and the new inode is added to the mapping table, and the new inode is added to the monitoring library.

[0012] Preferably, when a symbolic link is created under the path to be monitored, the inode corresponding to the symbolic link is obtained, and a mapping relationship between the path to be monitored and the inode corresponding to the symbolic link is added to the mapping table, and the inode corresponding to the symbolic link is added to the monitoring library.

[0013] Preferably, when a hard link is created under the path to be monitored, a mapping relationship between the path to be monitored and the inode corresponding to the hard link is added to the mapping table, and the inode corresponding to the hard link is added to the monitoring library.

[0014] Preferably, when the mount directory of the path to be monitored is unmounted, the monitoring path where the mount directory is located is deleted in the mapping table, and all inodes under the mount directory are deleted in the monitoring library.

[0015] Preferably, when a path to be monitored is deleted, the monitoring path continues to remain in the mapping table.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. This file system monitoring method based on file path takes the monitoring path as the monitoring object, establishes a mapping relationship between each monitoring path and the inode in the monitoring library, and each monitoring path points to the corresponding inode. When the file in the monitoring path is modified due to user operation, the mapping relationship and the inode of the monitoring library will also be updated in time, thereby ensuring dynamic monitoring of the monitoring path, thereby solving the problem in the prior art that the inode is deleted, renamed, replaced by a new file, etc., and the user program needs to re-establish the monitoring point, which is quite troublesome; 2. When the mount directory is unmounted, all inodes belonging to the mount directory in the mapping table are automatically cleaned up and released. This not only avoids the mistaken monitoring of inodes that are not unmounted, but also realizes the automatic cleaning of the monitoring library and avoids the waste of system resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A schematic diagram of a mapping table in a file system monitoring method based on a file path of the present invention; Figure 2 A schematic diagram of deleting and switching in the file system monitoring method based on file path of the present invention; Figure 3 A flowchart of the system call operation that causes modification in the Linux system according to the present invention; Figure 4 This is a schematic diagram of unmounting a mount directory according to the present invention. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0019] like Figure 1-Figure 4 As shown, a file system monitoring method based on a file path is provided, comprising: Step 1: Get the path to be monitored, monitor the inodes in the path to be monitored through the inotify interface, and store the monitored inodes in the monitoring library of the inotify interface; It should be noted that the monitoring path that the user needs to monitor is obtained and monitored through the inotify interface; inode is the index node. In this embodiment, five monitoring paths are used as display ( / home / xxx / file1, / home / xxx / file2, / home / xxx / file3, / home / xxx / file4 and / home / xxx / file5). The file in each path (file1, file2, file3, file4 and file5) corresponds to the inode in the monitoring library (inode1, inode2, inode3, inode4 and inode5), where file is a file or a directory, that is, inode is a file or a directory. In this application, file and inode represent the same object and can be distinguished.

[0020] Step 2: Create a one-to-one mapping relationship between the path to be monitored and the inode in the monitoring library to form a mapping table; like Figure 1 As shown, in this embodiment, a mapping relationship is established between each monitoring path and the inode in the monitoring library, and each monitoring path points to the corresponding inode, that is, the mapping table links the monitored path and the actual inode. When the file in the monitoring path fails or is switched due to user operation, the mapping relationship and the inode of the monitoring library will also be updated in time, thereby ensuring dynamic monitoring of the monitoring path.

[0021] Step 3: When the path to be monitored is deleted, the corresponding mapping relationship and the corresponding inode in the monitoring library are deleted; When the monitored path is deleted, the monitoring path is invalid. The mapping relationship between the monitoring path and the monitoring library in the mapping table is deleted, and the inode corresponding to the monitoring path in the mapping table is deleted. However, the monitoring path is still retained in the mapping table. When the user creates a new file using the monitoring path later, the mapping table will automatically update and add the new inode to the monitoring library. Figure 2 As shown in the figure, if the monitoring path / home / xxx / file1 is deleted, the mapping relationship between the monitoring path and the monitoring library will be deleted, and the corresponding inode in the monitoring library will be deleted. Figure 2 The old inode1 in the monitoring path is the inode corresponding to the monitoring path / home / xxx / file1 in the monitoring library.

[0022] Step 4: When the inode under the path to be monitored is modified (including deletion, renaming and creation), the mapping relationship corresponding to the mapping table and the corresponding inode in the monitoring library are updated; When the inode under the path to be monitored is deleted, the mapping relationship corresponding to the inode in the mapping table is deleted, and the corresponding inode in the monitoring library is deleted.

[0023] When the inode under the monitored path is renamed, first determine whether the inode under the monitored path has been removed. If so, delete the mapping relationship corresponding to the inode in the mapping table, and delete the corresponding inode in the monitoring library (because the inode in the path will be moved when the Linux system file is renamed, so it is necessary to determine whether the inode has been removed); If it has not been removed, the mapping relationship in the mapping table and the corresponding inode in the monitoring library are updated to the renamed inode; Figure 2 In the example, the monitoring path / home / xxx / file2 is overwritten by the user with a new file, so the inode is switched (this switch is a structure of two operations, deletion and renaming. First, the old inode is deleted, and then another inode is moved to the current monitoring path. In other words, the inode corresponding to the monitoring path is first deleted from the mapping table, and then updated to the new inode during rename). The mapping table relationship and the monitoring library are also updated accordingly. Oldinode2 is the inode corresponding to the monitoring path / home / xxx / file2 in the monitoring library before the update.

[0024] When a new inode is created under the path to be monitored (there may be two situations. The first situation is that there is no inode under the monitoring path and a new inode is created. The second situation is that an inode already exists under the monitoring path and a new inode is created. In the second situation, there is a one-to-two mapping relationship between the monitoring path and the monitoring library), the mapping relationship between the path to be monitored and the new inode is added to the mapping table, and the new inode is added to the monitoring library.

[0025] When a symbolic link is created under the path to be monitored, the inode corresponding to the symbolic link is obtained, and the mapping relationship between the path to be monitored and the inode corresponding to the symbolic link is added to the mapping table, and the inode corresponding to the symbolic link is added to the monitoring library.

[0026] When a hard link is created under the path to be monitored, a mapping relationship between the path to be monitored and the inode corresponding to the hard link is added to the mapping table, and the inode corresponding to the hard link is added to the monitoring library.

[0027] There are several reasons why system calls that cause inode modification in Linux systems: 1) unlink: file deletion 2) rename: file rename 3) mkdir: directory creation 4) open (using O_CREAT call parameter): file creation 5) symlink: symbolic link creation 6) link: hard link creation When the above system calls occur, the system kernel will automatically match the corresponding monitoring path in the monitoring path mapping table and update the mapping relationship and monitoring library according to the operation type, as follows: Figure 3 As shown: When a system call occurs: Step (1): For any system call operation, first determine whether the operation will cause inode modification. If so, execute step (2); if not, continue to determine the next system call operation. Step (2), determine whether the modified inode is within the path range to be monitored by the user, that is, whether it exists in the mapping table. If it does, execute step (3). If it does not, determine whether the monitoring is completed. If not, return to step (1). Step (3), determine whether the unlink system call operation is performed. If so, delete the mapping relationship corresponding to the inode in the mapping table (in this case, the inode is a file), and delete the corresponding inode in the monitoring library. If not, execute step (4); Step (4), determine whether the rename system call operation is performed. If so, first determine whether the inode under the monitoring path has been removed (in this case, the inode is a file). If removed, delete the mapping relationship corresponding to the inode in the mapping table, and delete the corresponding inode in the monitoring library; If it has not been removed, the mapping relationship in the mapping table and the corresponding inode in the monitoring library are updated to the renamed inode; if it is not a rename system call operation, execute step (5); Step (5), determine whether the mkdir system call operation is performed. If so, add the mapping relationship between the path to be monitored and the new inode (inode is a directory in this case) in the mapping table, and add the new inode to the monitoring library. If not, execute step (6); Step (6), determine whether the open system call operation is performed. If so, add the mapping relationship between the path to be monitored and the new inode (inode is a file in this case) in the mapping table, and add the new inode to the monitoring library. If not, execute step (7); Step (7), determine whether the symlink system call operation is performed, if so, obtain the inode corresponding to the symbolic link, add the mapping relationship between the path to be monitored and the inode corresponding to the symbolic link in the mapping table, and add the inode corresponding to the symbolic link in the monitoring library; if not, execute step (8); Step (8), determine whether the link system call operation is performed. If so, add the mapping relationship between the path to be monitored and the inode corresponding to the hard link in the mapping table, and add the inode corresponding to the hard link in the monitoring library; if not, determine whether the monitoring is completed. If not, return to step (1) until all system call operations are determined to be completed, and then end the monitoring.

[0028] Step 5: When the mount directory of the path to be monitored is unmounted, the monitoring path where the mount directory is located is deleted in the mapping table, and all inodes under the mount directory are deleted in the monitoring library; like Figure 4 As shown in the figure, when the mount directory / home / yyy is unmounted, all inodes belonging to the mount directory in the mapping table are automatically cleaned up and released, that is, the mapping relationship between / home / yyy / file1, / home / yyy / file4 and / home / yyy / file5 and the monitoring library, and the corresponding inode1, inode4 and inode5 are deleted from the monitoring library. In this way, it can avoid the mistaken monitoring of inodes that do not belong to the unmounted inodes, and realize the automatic cleaning of the monitoring library, avoiding the waste of system resources.

[0029] The file system monitoring method based on file path takes the monitoring path as the monitoring object, establishes a mapping relationship between each monitoring path and the inode in the monitoring library, and each monitoring path points to the corresponding inode. When the file in the monitoring path is modified due to user operation, the mapping relationship and the inode of the monitoring library will also be updated in time, thereby ensuring dynamic monitoring of the monitoring path, thereby solving the problem in the prior art that the inode is deleted, renamed, replaced by a new file, etc., and the user program needs to re-establish the monitoring point, which is relatively troublesome; when the mount directory is unmounted, all inodes belonging to the mount directory in the mapping table are automatically cleaned up and released, so that it can avoid the mistaken monitoring of the inode that does not belong to the unmounted, and also realize the automatic cleaning of the monitoring library, avoiding the waste of system resources.

[0030] It should be understood that although Figure 3 The steps in the flowchart are shown in sequence according to the arrows, but these steps are not necessarily executed in the order indicated by the arrows. There is no strict order restriction for the execution of these steps, and these steps can be executed in other orders.

[0031] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A file system monitoring method based on file path, characterized in that: The file system monitoring method based on file path includes: Get the path to be monitored, monitor the inodes in the path to be monitored through the inotify interface, and store the monitored inodes in the monitoring library of the inotify interface; Create a one-to-one mapping relationship between the path to be monitored and the inode in the monitoring library to form a mapping table; When the path to be monitored is deleted, the corresponding mapping relationship and the corresponding inode in the monitoring library are deleted; When the inode under the path to be monitored is modified, the mapping relationship corresponding to the mapping table and the corresponding inode in the monitoring library are updated and modified.

2. The file system monitoring method based on file path according to claim 1, characterized in that: The inode is a file or a directory.

3. The file system monitoring method based on file path according to claim 1, characterized in that: When the inode under the path to be monitored is deleted, the mapping relationship corresponding to the inode in the mapping table is deleted, and the corresponding inode in the monitoring library is deleted.

4. The file system monitoring method based on file path according to claim 1, characterized in that: When the inode under the monitored path is renamed, first determine whether the inode under the monitored path is removed. If removed, delete the mapping relationship corresponding to the inode in the mapping table, and delete the corresponding inode in the monitoring library; If it has not been removed, the mapping relationship in the mapping table and the corresponding inode in the monitoring library are updated to the renamed inode.

5. The file system monitoring method based on file path according to claim 1, characterized in that: When a new inode is created under the path to be monitored, a mapping relationship between the path to be monitored and the new inode is added to the mapping table, and the new inode is added to the monitoring library.

6. The file system monitoring method based on file path according to claim 1, characterized in that: When a symbolic link is created under the path to be monitored, the inode corresponding to the symbolic link is obtained, and the mapping relationship between the path to be monitored and the inode corresponding to the symbolic link is added to the mapping table, and the inode corresponding to the symbolic link is added to the monitoring library.

7. The file system monitoring method based on file path according to claim 1, characterized in that: When a hard link is created under the path to be monitored, a mapping relationship between the path to be monitored and the inode corresponding to the hard link is added to the mapping table, and the inode corresponding to the hard link is added to the monitoring library.

8. The file system monitoring method based on file path according to claim 1, characterized in that: When the mount directory of the path to be monitored is unmounted, the monitoring path where the mount directory is located is deleted in the mapping table, and all inodes under the mount directory are deleted in the monitoring library.

9. The file system monitoring method based on file path according to claim 1, characterized in that: When a path to be monitored is deleted, the monitoring path continues to remain in the mapping table.

Images