Metadata sharing method and system for deletion marker in a union file system

Abstract

The application relates to a metadata sharing method and system for a deletion marker in a union file system, and belongs to the technical field of computers. The method solves the problem of inode resource consumption and inode resource exhaustion risk in the prior art. The method comprises the following steps: initiating a file deletion operation, checking whether a deletion marker file template exists, returning a directory entry of the deletion marker file template if the deletion marker file template exists, creating a temporary deletion marker file, pointing an inode pointer field in a directory entry of the temporary deletion marker file to an inode pointer of the deletion marker file template, establishing a temporary hard link of the temporary deletion marker file to the deletion marker file template, making the temporary deletion marker file inherit the inode of the deletion marker file template, and atomically renaming the temporary deletion marker file to a file name to be deleted and storing the file name to an upper directory of the union file system. The application reduces inode consumption and avoids inode resource exhaustion risk.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for sharing metadata by deleting tags in a union file system. Background Technology

[0002] A union filesystem is a file system technology that combines multiple directories (called "layers") into a single directory structure. The most representative examples are OverlayFS in the Linux kernel and the Overlay2 storage driver widely used in Docker container runtime.

[0003] The core architecture of OverlayFS includes the following directory layers: 1) Lower layer: Read-only layer, which may contain one or more directories and typically stores the base image data; 2) Upper layer: Writable layer, storing modifications (additions, modifications, deletions) made by the container at runtime; 3) Working directory (workdir): A temporary directory used internally by OverlayFS to ensure the atomicity of file operations. It must be located on the same file system as the upper directory. 4) Merged directories: Combines the lower and upper directories to present a unified view to the user.

[0004] When a user reads a file in the merged directory, OverlayFS prioritizes reading from the upper directory; if the file does not exist in the upper directory, it reads from the lower directory. When a user modifies a file, OverlayFS copies the file from the lower directory to the upper directory (this process is called a "copy-up" operation), and then makes the modifications in the upper directory.

[0005] Since the lowerdir is read-only and files within it cannot be directly deleted, OverlayFS uses whiteout entries in the upperdir to indicate that a file has been deleted. The whiteout entry is implemented as follows: a character device file (0 / 0 char dev) with a major device number of 0 and a minor device number of 0 is created in the upperdir, with the same filename as the file in the lowerdir being deleted. When OverlayFS finds a whiteout entry with the same name in the upperdir as the file in the lowerdir in the merged view, it automatically hides the entry, making it invisible in the merged view. In other words, the lowerdir file to be deleted has been deleted in the merged view.

[0006] like Figure 1 As shown, the creation process for the whiteout marker is as follows: 1) The user initiates a deletion operation in the merged directory; 2) The kernel space enters the deletion marker creation function; 3) Randomly generate temporary files in the working directory (workdir); 4) Generate a character device file in the working directory (workdir) using a temporary filename and allocate an exclusive inode (to store metadata). 5) The kernel space returns the whiteout directory entry it created to the caller; 6) Atomically rename the temporary whiteout file in the working directory (workdir) to the parent directory (upperdir).

[0007] The existing technology has the following drawbacks: Disadvantage 1: Deleting files consumes a lot of inode resources. Because each whiteout instance creates a completely new character device file by calling the `mknod()` function, each whiteout instance occupies its own inode. When a user deletes N lower-level files, N whiteout instances need to be created in the upper-level file system, consuming N inodes. This leads to a counterintuitive phenomenon: after deleting files, the number of inodes used in the file system actually increases.

[0008] Table 1 shows the measured data (ext4 file system): Table 1

[0009] Disadvantage 2: Deleting files may lead to inode resource exhaustion. This problem is particularly severe in container scenarios, as shown in Table 2: Table 2

[0010] The XFS file system has a default inode count of approximately 5 million. When Docker frequently creates and deletes containers, a large number of whiteouts can lead to inode resource exhaustion, affecting the normal operation of the entire host machine.

[0011] Disadvantage 3: High disk metadata write overhead Each time the `mknod()` function is called to create a whiteout, the underlying file system needs to: allocate a new inode for the whiteout file (modifying the inode bitmap); insert a new directory entry into the directory data block; and update the file system's superblock and log. These metadata operations involve multiple disk I / Os, resulting in significant performance overhead in large-scale deletion scenarios. Summary of the Invention

[0012] Based on the above analysis, the embodiments of the present invention aim to provide a method and system for sharing metadata by deleting tags in a union file system, in order to solve the problems in the prior art.

[0013] On one hand, embodiments of the present invention provide a method for deleting tags in metadata sharing within a union file system, including: When a file deletion operation is initiated, check if a deletion marker file template exists. If it exists, return the directory entry of the deletion marker file template. Create a temporary deletion marker file, and point the inode pointer field in the directory entry of the temporary deletion marker file to the inode pointer of the deletion marker file template, so as to establish a temporary hard link between the temporary deletion marker file and the deletion marker file template, so that the temporary deletion marker file inherits the inode of the deletion marker file template; The temporary deletion marker file is atomically renamed to the upper-level directory of the union file system, wherein the renamed file name is the file name to be deleted.

[0014] Further, checking for the existence of deletion marker file templates includes: The existence of a deletion marker file template can be determined by checking the filename of the deletion marker file template.

[0015] Furthermore, the deletion marker file template is stored in the working directory of the union file system.

[0016] Furthermore, it also includes: If it does not exist, a deletion marker file template is created, and an inode is assigned to the deletion marker file template.

[0017] Furthermore, the inode contains a hard link count field; Also includes: Once a temporary hard link is established between the temporary deletion marker file and the deletion marker file template, the hard link count is incremented by 1.

[0018] Furthermore, it also includes: If the hard link count exceeds the preset value, then fall back to using the mknod() method to create a deletion marker.

[0019] Furthermore, it also includes: If the temporary deletion marker file fails to be renamed atomically, the temporary hard link will be cleared. Decrement the hard link count by 1.

[0020] On the other hand, embodiments of the present invention provide a metadata sharing system for deleting tags in a union file system, comprising: The deletion marker file template lookup module is used to check whether a deletion marker file template exists when a file deletion operation is initiated. If it exists, the module returns the directory entry of the deletion marker file template. The temporary deletion marker file creation and hard link module is used to create a temporary deletion marker file, and to point the inode pointer field in the directory entry of the temporary deletion marker file to the inode pointer of the deletion marker file template, so as to establish a temporary hard link between the temporary deletion marker file and the deletion marker file template, and make the temporary deletion marker file inherit the inode of the deletion marker file template; The atomic renaming module is used to atomically rename the temporary deletion marker file to the upper-level directory of the union file system, wherein the renamed file name of the temporary deletion marker file is the file name to be deleted.

[0021] On the other hand, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the metadata sharing method for deleting tags in the union file system described above.

[0022] On the other hand, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the metadata sharing method for deleting tags in the union file system described above.

[0023] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1. Reduce whiteout inode consumption: By hard linking different deletion marker files to the same inode, the inode consumption for deleting N files is reduced from O(N) to O(1), solving the problem that deleting files consumes a lot of inode resources.

[0024] 2. Avoid the risk of inode resource exhaustion: By hard linking different deletion marker files to the same inode, in container batch deletion scenarios, the host file system is prevented from being unable to create new files due to excessive inode consumption caused by whiteout.

[0025] 3. Reduce disk metadata write overhead: By hard-linking different deletion marker files to the same inode, the inode allocation and bitmap update operations during whiteout creation are reduced, thus improving batch deletion performance.

[0026] 4. Maintain full compatibility with existing systems: Do not change the existing whiteout disk format and recognition logic, ensuring that the old and new systems can read each other, and existing applications and tools do not need to be modified.

[0027] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0028] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 Create a whiteout process for existing technologies; Figure 2 This is a flowchart of a method for deleting tags in a union file system according to an embodiment of the present invention. Figure 1 ; Figure 3 This is a flowchart of a method for deleting tags in a union file system according to an embodiment of the present invention. Figure 2 . Detailed Implementation

[0029] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0030] In a union file system, the lower level (lowerdir) is read-only, and files within it cannot be directly deleted. Deletion markers (whiteouts) need to be created in the upper level (upperdir) to indicate that files in the lower level (lowerdir) have been deleted. In existing technology, each whiteout is created independently by calling `mknod()`, creating a completely new 0 / 0 character device file each time, and each whiteout has its own independent inode. However, all whiteouts have identical attributes (all 0 / 0 character devices with permissions 0000), and the only difference between them is the filename (i.e., different directory entries). This practice of "repeatedly allocating inodes for identical metadata" is a waste of resources. Therefore, this invention proposes implementing multiple whiteouts as hard links to the same 0 / 0 character device file, rather than as separate character device files. Since hard links share the same inode, N whiteouts consume only 1 inode (i.e., the inode of the shared template file), thus reducing inode consumption from O(N) to O(1).

[0031] Based on this, a specific embodiment of the present invention discloses a method for sharing metadata by deleting tags in a union file system, such as... Figure 2 As shown, it includes: S110: When a file deletion operation is initiated, check if a deletion marker file template exists. If it exists, return the directory entry of the deletion marker file template.

[0032] In practice, a deletion marker file template (or whitening file template) with a fixed filename is created in the OverlayFS working directory (workdir). The filename is .overlay-whiteout-template, and the attribute is 0 / 0 character device file. Its directory entries include the filename and the inode pointer (d_inode), where the inode pointer (d_inode) points to an inode, such as inode 137 (0 / 0 char dev).

[0033] When a user initiates the deletion of files in the lowerdir of a merged directory, the system first searches for a whiteout template file using the lookup_one_len() function in the working directory of the union file system, based on the filename .overlay-whiteout-template. If the search result is negative (i.e., the filename does not exist and the dentry (directory entry) status is negative), then ovl_do_whiteout() (i.e., vfs_whiteout() → mknod(0,0)) is called to create the whiteout template and allocate an inode. If the search result is positive (i.e., the filename already exists), the dentry is directly returned as a template reference. The dentry reference of the whiteout template is then returned to the whiteout creation function.

[0034] The deletion marker file templates are stored in the file system of the working directory (workdir) (rather than in the kernel memory structure) and are located by fixed filenames. The advantages of this design include: 1) Persistence: The template file still exists in the working directory (workdir) after being unmounted from the file system, and can be reused directly when remounted without being recreated; 2) Version compatibility: The file template is found or created in the working directory by using a fixed filename (e.g., .overlay-whiteout-template) without modifying the core data structure of OverlayFS (e.g., struct ovl_fs), ensuring compatibility with different kernel versions and unaffected by differences in kernel data structure layout; 3) Isolation: Each OverlayFS mount instance has an independent working directory (workdir), naturally isolating templates and avoiding cross-instance conflicts; 4) Create the template file only when the deletion flag is first needed to avoid additional overhead from mounting without deletion operations.

[0035] S120: Create a temporary deletion marker file, and point the inode pointer field in the directory entry of the temporary deletion marker file to the inode pointer of the deletion marker file template, so as to establish a temporary hard link between the temporary deletion marker file and the deletion marker file template, so that the temporary deletion marker file inherits the inode of the deletion marker file template.

[0036] In practice, a temporary deletion marker file is first created in the working directory (workdir) using the ovl_lookup_temp() function. This temporary deletion marker file is a character device file with a major device number of 0 and a minor device number of 0 (i.e., 0 / 0 char dev). The filename of this temporary deletion marker file is a temporary filename (e.g., #123) to avoid name conflicts. The directory entry of the temporary deletion marker file includes the filename (e.g., #123) and an inode pointer (d_inode). At this time, the inode pointer (d_inode) does not point to any inode. The generation of this temporary deletion marker file is the same as in existing technologies and will not be described in detail.

[0037] Then, create a hard link to the deletion marker file template (without allocating a new inode): point the inode pointer (d_inode) of the temporary deletion marker file to the inode pointer of the deletion marker file template, thus establishing a temporary hard link between the temporary deletion marker file and the deletion marker file template.

[0038] Finally, the inode pointed to by the inode pointer (d_inode) of the deleted marker file template is inherited, such as inode137 (0 / 0 char dev).

[0039] In some embodiments, the inode includes a hard link count field; it also includes: Once a temporary hard link is established between the temporary deletion marker file and the deletion marker file template, the hard link count is incremented by 1.

[0040] If the hard link count exceeds the preset value, then fall back to using the mknod() method to create a deletion marker.

[0041] If renaming the temporary deletion marker file fails, the temporary hard link is cleared; the hard link count is decremented by 1.

[0042] In practical implementation, this invention also includes a hard link count field, where the hard link count (nlink) of the inode of the deletion marker file template file changes with the creation and deletion of the temporary deletion marker file (whiteout): When creating the deletion marker file template: nlink = 1; For each temporary whiteout file created: nlink++; Each time a temporary whiteout file is deleted (unlink): nlink--; can include deleting the hard link to the temporary whiteout file if the atomic renaming of the temporary whiteout file fails; or it can be deleted after the hard link has been created. When nlink returns to 1: the marker file template is deleted and only referenced by itself; When nlink exceeds the hard link limit of the file system (approximately 65,000 for ext4), it automatically falls back to creating a temporary deletion marker file (whiteout) using the independent mknod() method.

[0043] S130: Atomically rename the temporary deletion marker file to the upper-level directory of the union file system, wherein the renamed file name of the temporary deletion marker file is the file name to be deleted.

[0044] In practice, atomically renaming the temporary deletion marker file simply involves replacing the temporary deletion marker filename with the filename to be deleted. The renaming process is the same as existing technologies and will not be described in detail again.

[0045] The procedure described below differs from that of the prior art.

[0046] When deleting files using existing technology, such as Figure 1 The procedure corresponding to the shown process: rm merged / file.txt → ovl_whiteout(workdir) → ovl_lookup_temp(workdir) → Generates a temporary filename #xxx in workdir → ovl_do_whiteout(wdir, #xxx) → Create a separate 0 / 0 character device mknod(0,0) → Allocate a new inode A → Return to whiteout dentry → ovl_do_rename(wdir, #xxx, udir, file.txt) → Atomic rename to upperdir / file.txt → Result: upperdir / file.txt → inode A (nlink=1) upperdir directory structure: upperdir / etc / shadow→ inode 137 (0 / 0 char dev, nlink=1) upperdir / etc / hosts→ inode 138 (0 / 0 char dev, nlink=1) upperdir / etc / resolv.conf→ inode 139 (0 / 0 char dev, nlink=1) → 3 whiteouts = 3 inodes When deleting files in this invention, such as Figure 3 The procedure corresponding to the shown process: rm merged / file.txt → ovl_whiteout(workdir) → ovl_lookup_temp(workdir) → Generates a temporary filename #xxx in workdir → ovl_whiteout_template(workdir) → Find / create a deletion marker file template in workdir → lookup_one_len(".overlay-whiteout-template", workdir) → If it doesn't exist: ovl_do_whiteout() → Create a separate 0 / 0 character device mknod(0,0) → Allocate inode T (first time only) → If it already exists: directly return to the dentry template for deletion markers. → ovl_do_link(template, wdir, #xxx) → link() → Hard link to inode T (without allocating a new inode) → dput(template) → Return to whiteout dentry → ovl_do_rename(wdir, #xxx, udir, file.txt) → Atomic rename to upperdir / file.txt → Result: upperdir / file.txt → inode T (nlink++) →If rename fails, clean up temporary hard links in the workdir using ovl_cleanup(). workdir directory structure: workdir / .overlay-whiteout-template → inode 137 (0 / 0 char dev, nlink=N+1) ← Shared template upperdir directory structure: upperdir / etc / shadow → inode 137 (hard link to template) upperdir / etc / hosts → inode 137 (hard link to template) upperdir / etc / resolv.conf → inode 137 (hard link to template) → 3 whiteouts = 1 inode (shared) As can be seen from the above, in the existing technology process, each whiteout requires an independent mknod inode allocation step. In the process of this invention, mknod is only executed when the whiteout file template is created for the first time. Subsequently, ovl_do_whiteout(wdir, #xxx) is changed from creating an independent inode with mknod() to creating a hard link shared inode with ovl_do_link(template,wdir, #xxx). This allows all whiteouts to share the whiteout file template inode through hard links, greatly reducing inode consumption.

[0047] This invention fully retains the existing OverlayFS atomic operation mode of creating temporary files on the workdir and renaming them, thus ensuring that crash safety is equivalent to the existing mechanism.

[0048] When subsequent users or the system attempt to read, search, or traverse a merged directory, the following method is used to determine whether a file marked for deletion has been deleted. The Linux kernel determines whiteout in the following way: #define IS_WHITEOUT(inode) (S_ISCHR(inode->i_mode)&&(inode)->i_rdev == WHITEOUT_DEV) The i_mode and i_rdev of the deletion marker file (i.e., 0 / 0 character device) obtained through hard linking in this invention are completely identical to the i_mode and i_rdev of the deletion marker file (i.e., 0 / 0 character device) created independently by mknod. Therefore, the existing deletion marker identification logic does not need to be modified. All kernel code paths that depend on IS_WHITEOUT() (including lookup, readdir, creating new files that overwrite whiteout, etc.) do not need to be modified.

[0049] This invention performs a compatibility analysis on all code paths in OverlayFS that rely on whiteout for identification, as shown in Table 3: Table 3

[0050] For renaming operations, in the `ovl_rename()` function, when the source file to be renamed is detected in the merged directory as existing in the lower directory and the target file in the upper directory is a real file instead of a whiteout file, the existing code automatically adds the `RENAME_WHITEOUT` flag. This causes the VFS to internally call `mknod()` to create a completely new, independent whiteout file for the configuration inode while renaming (renaming the source file to the target file). This invention replaces this scenario with manually creating a hard link whiteout. First, it actively removes (clears) the `RENAME_WHITEOUT` flag, preventing the underlying VFS from automatically creating the whiteout file. Then, it calls the underlying renaming interface (`ovl_do_rename`) to promote (copy-up) the source file (old) from the lower directory to the upper directory and moves it to the target file path (new) for renaming. During this process, the original real file on the target path (new) is atomically replaced and overwritten. After confirming the renaming operation was successfully executed (without returning an error), the system calls a custom creation function (ovl_create_whiteout_at) to perform the following operations in the original location left after the source file (old) was moved from the upper directory: It retrieves the deletion marker file template, creates a new directory entry (the source file's filename + inode pointer) in the original location of the source file in the upper directory (upperdir), and makes this new directory entry directly point to the inode of the deletion marker file template. In the merged view, this hard-linked deletion marker effectively obscures the original physical entity of the source file in the lower directory, completing the maintenance of state consistency after renaming and ensuring that the renaming scenario also shares the inode.

[0051] The procedures specifically involved in the prior art and the present invention are as follows: / Existing code / if (ovl_lower_positive(old)&&!ovl_dentry_is_whiteout(new)) flags |= RENAME_WHITEOUT; / Modification of this invention / if (ovl_lower_positive(old)&&!ovl_dentry_is_whiteout(new)) { / Do not use VFS's RENAME_WHITEOUT (VFS internally calls mknod to create a separate inode) / flags&= ~RENAME_WHITEOUT; / First, complete the rename operation. / err = ovl_do_rename(olddir, old, newdir, new, flags); if (!err) { / Manually create a hard link to whiteout in the old location / err = ovl_create_whiteout_at(olddir, olddentry); } } This invention only modifies one file, dir.c, in the OverlayFS source code, without modifying other files such as overlayfs.h, ovl_entry.h, and super.c, as shown in Table 4.

[0052] Table 4

[0053] The total changes amounted to approximately 40 lines of code, with extremely low intrusiveness.

[0054] The method proposed in this invention will be verified through specific examples below.

[0055] Example 1: Deleting a single file in the lowerdir Test environment: openEuler / Vlx, kernel 4.19.90, ext4 file system.

[0056] Operating steps: Mount OverlayFS: mount -t overlay overlay -o lowerdir=A,upperdir=C,workdir=worker merged / Delete file: rm merged / a.txt Observe the changes in inode: Inodes used before deletion: 488954 After deletion, the inode usage is 488955 (+1, for the initial template creation). Viewing whiteout: stat C / a.txt → Inode: 942044, nlink: 2, Device type: 0,0 Analysis shows that: the creation of the template during the first deletion consumes 1 inode, while whiteout itself shares the template inode through hard links and does not consume additional inodes.

[0057] Example 2: Deleting multiple lowerdir files Continue deleting the second file in the environment of Example 1: Delete file: rm merged / b.txt Observe the changes in inode: Inodes used before deletion: 488955 After deletion, the inode usage is: 488955 (+0, hard link shared inode!). Checking the whiteout: stat C / b.txt → Inode: 942044, nlink: 3 (shares the same inode as C / a.txt) Analysis shows that the second deletion no longer requires the creation of a new inode. Whiteout shares the template inode through hard links, and nlink increases from 2 to 3.

[0058] Example 3: Batch deletion of 1000 files Operating steps: Create 1000 lowerdir files: `for i in $(seq 1 1000); do echo "test">A / bigdir / file_$i.txt; done` Mount and delete: rm -f merged / bigdir /

[0059] Observe the changes in inode: The results are compared (only the inode consumption of whiteout is compared; directory copy-up is an inherent overhead of overlay2, which both schemes incur, and is not included in the comparison), as shown in Table 5: Table 5

[0060] Analysis shows that the original overlay consumes 1 independent whiteout inode for each file deleted (1000 in total). In this invention, all whiteouts share a template inode through hard links (the template has been created in previous operations and persisted in the workdir), resulting in zero inode consumption for the whiteout portion, saving 100%.

[0061] Example 4: Template Persistence Verification Unmount OverlayFS: unmount merged / Remount: `mount -t overlay overlay -o lowerdir=A,upperdir=C,workdir=worker merged / ` Delete new file: rm merged / newfile.txt Observation: The template file .overlay-whiteout-template was found directly by lookup_one_len() after remounting, without needing to be recreated.

[0062] Analysis: Template persistence in the workdir file system allows for reuse across mount cycles, further reducing overhead.

[0063] 1) Significantly reduced inode resource consumption: By hard linking different deletion marker files to the same inode, the inode consumption for deleting N files is reduced from O(N) to O(1), solving the problem that deleting files consumes a lot of inode resources.

[0064] The data in Table 6 below only compares the inode consumption of whiteout (deletion marker). The 1 inode consumption generated by directory copy-up is an inherent overhead of overlay2 and is unrelated to whiteout optimization. Both schemes bear this overhead, so it is not included in the comparison.

[0065] Table 6

[0066] 2) Eliminate the risk of inode resource exhaustion: By hard linking different deletion marker files to the same inode, in container batch deletion scenarios, prevent the host file system from being unable to create new files due to excessive inode consumption caused by whiteout.

[0067] Taking a typical Docker scenario as an example, as shown in Table 7: Table 7

[0068] Scale effect: The more files you delete, the more significant the optimization effect. It works best in Docker container batch deletion scenarios (such as `rm -rf`, `yum clean all`, `apt-get clean`), which is precisely the scenario where existing technologies have the most prominent problems.

[0069] 3) Reduce disk metadata write overhead: By hard linking different deletion marker files to the same inode, the inode allocation and bitmap update operations during whiteout creation are reduced, thus improving batch deletion performance.

[0070] Table 8

[0071] 4) Maintain full compatibility with existing systems: Do not change the existing whiteout disk format and recognition logic, ensuring that the old and new systems can read each other, and existing applications and tools do not need to be modified.

[0072] The disk format remains unchanged: the hard link whiteout is still a 0 / 0 character device, completely consistent with the existing format; The old and new kernels can read each other: when the old kernel mounts an upperdir containing a hard link whiteout, `IS_WHITEOUT()` can be correctly recognized; No new mount options required: This is a behavior optimization, not a new feature, and existing applications and tools require no modification. Only one source file needs to be modified: `dir.c`, which has very low intrusion and is easy to maintain and integrate into the upstream.

[0073] One specific embodiment of the present invention discloses a metadata sharing system for deleting tags in a union file system, comprising: The deletion marker file template lookup module is used to check whether a deletion marker file template exists when a file deletion operation is initiated. If it exists, the module returns the directory entry of the deletion marker file template. The temporary deletion marker file creation and hard link module is used to create a temporary deletion marker file, and to point the inode pointer field in the directory entry of the temporary deletion marker file to the inode pointer of the deletion marker file template, so as to establish a temporary hard link between the temporary deletion marker file and the deletion marker file template, and make the temporary deletion marker file inherit the inode of the deletion marker file template; The atomic renaming module is used to atomically rename the temporary deletion marker file to the upper-level directory of the union file system, wherein the renamed file name of the temporary deletion marker file is the file name to be deleted.

[0074] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0075] Electronic device example: One specific implementation of this application discloses an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the metadata sharing method for deleting tags in a union file system as described in the method embodiment.

[0076] Examples of readable storage media: One specific implementation of this application discloses a non-transitory computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the metadata sharing method for deleting tags in a union file system as described in the method embodiment.

[0077] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0078] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for sharing metadata by deleting tags in a union file system, characterized in that, include: When a file deletion operation is initiated, check if a deletion marker file template exists. If it exists, return the directory entry of the deletion marker file template. Create a temporary deletion marker file, and point the inode pointer field in the directory entry of the temporary deletion marker file to the inode pointer of the deletion marker file template, so as to establish a temporary hard link between the temporary deletion marker file and the deletion marker file template, so that the temporary deletion marker file inherits the inode of the deletion marker file template; The temporary deletion marker file is atomically renamed to the upper-level directory of the union file system, wherein the renamed file name is the file name to be deleted.

2. The method for deleting marked metadata sharing in a union file system according to claim 1, characterized in that, Checking for the existence of a deletion marker file template includes: The existence of a deletion marker file template can be determined by checking the filename of the deletion marker file template.

3. The method for deleting marked metadata sharing in a union file system according to claim 1 or 2, characterized in that, The deletion marker file template is stored in the working directory of the union file system.

4. The method for deleting marked metadata sharing in a union file system according to claim 1, characterized in that, Also includes: If it does not exist, a deletion marker file template is created, and an inode is assigned to the deletion marker file template.

5. The method for deleting marked metadata sharing in a union file system according to claim 1, characterized in that, The inode contains a hard link count field; Also includes: Once a temporary hard link is established between the temporary deletion marker file and the deletion marker file template, the hard link count is incremented by 1.

6. The method for deleting marked metadata sharing in a union file system according to claim 5, characterized in that, Also includes: If the hard link count exceeds a preset value, then fall back to using the mknod() method to create a deletion marker.

7. The method for deleting tags in metadata sharing within a union file system according to claim 5 or 6, characterized in that, Also includes: If the temporary deletion marker file fails to be renamed atomically, the temporary hard link will be cleared. Decrease the hard link count by 1.

8. A metadata sharing system for deleting tags in a union file system, characterized in that, include: The deletion marker file template lookup module is used to check whether a deletion marker file template exists when a file deletion operation is initiated. If it exists, the module returns the directory entry of the deletion marker file template. The temporary deletion marker file creation and hard link module is used to create a temporary deletion marker file, and to point the inode pointer field in the directory entry of the temporary deletion marker file to the inode pointer of the deletion marker file template, so as to establish a temporary hard link between the temporary deletion marker file and the deletion marker file template, and make the temporary deletion marker file inherit the inode of the deletion marker file template; The atomic renaming module is used to atomically rename the temporary deletion marker file to the upper-level directory of the union file system, wherein the renamed file name of the temporary deletion marker file is the file name to be deleted.

9. An electronic device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the metadata sharing method for deleting tags in a union file system as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the steps of the metadata sharing method for deleting tags in a union file system as described in any one of claims 1 to 7.

Images