File system processing method, system, server, storage medium and program product

Abstract

The application provides a file system processing method, system, server, storage medium and program product. The method is suitable for a container migration scene. In a container saving stage, a source end reads original device numbers of mounting points of original tmpfs and original inode numbers of files in a source container, and transmits the original device numbers and the original inode numbers to a target end through a container management end. In a container recovery stage, the target end explicitly allocates corresponding original device numbers to created mounting points when the mounting points are created, so that consistency of the device numbers of the tmpfs before and after saving and recovery can be ensured. When files are created in the mounting points, corresponding original inode numbers are explicitly allocated to the created files, so that consistency of inode numbers of the files before and after saving and recovery can be ensured, abnormality / failure caused by inconsistency of the device numbers and the inode numbers of the tmpfs before and after migration can be avoided, and safety and stability of a system are improved.

Description

Technical Field

[0001] This application relates to data processing technology, and more particularly to a file system processing method, system, server, storage medium, and program product. Background Technology

[0002] With the widespread application of container technology in cloud computing, AI (artificial intelligence) training, microservices, and other fields, container migration has become a key technology for achieving elastic scaling, fault recovery, and load balancing. The core objective of container migration is to maintain the consistency of the container's runtime state, including memory, file system, and network connectivity.

[0003] However, for memory-based temporary file systems (tmpfs), due to their volatility (data resides only in memory) and dynamic metadata allocation (device and inode numbers are dynamically assigned by the kernel), the consistency of device and inode numbers cannot be guaranteed during migration. Many applications (such as AI training tasks, database caching, and file search tools) rely on these metadata for file verification and access control, potentially leading to anomalies or even crashes after migration. Summary of the Invention

[0004] This application provides a file system processing method, system, server, storage medium, and program product to solve the problem that container migration solutions cannot guarantee the consistency of device number and inode number in the tmpfs file system.

[0005] Firstly, this application provides a file system processing method applied to the target end of container migration, the method comprising:

[0006] Obtain the file metadata and mount metadata of the original temporary file system tmpfs in the source container. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source. The file metadata includes the original inode number of the file.

[0007] When the mount point is created in the target container, the corresponding source device number is explicitly assigned to the created mount point based on the mount metadata.

[0008] When the file is created at the mount point, the corresponding original inode number is explicitly assigned to the created file based on the file metadata.

[0009] Secondly, this application provides a file system processing method applied to the source end of container migration, the method comprising:

[0010] Read the file metadata and mount metadata of the original tmpfs in the source container. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source. The file metadata includes the original inode number of the file.

[0011] Write the original tmpfs file metadata and mount metadata into the configuration file;

[0012] The configuration file is sent to the container management terminal so that the container management terminal sends the original tmpfs file metadata and mount metadata to the target terminal.

[0013] Thirdly, this application provides a file system processing method applied to a container management terminal, the method comprising:

[0014] Receive the configuration file sent by the source.

[0015] Parse the configuration file to obtain the original tmpfs file metadata and mount metadata. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source. The file metadata includes the original inode number of the file.

[0016] The original tmpfs file metadata and mount metadata are transferred to the target end.

[0017] Fourthly, this application provides a file system processing system, including: a source end, a target end, and a container management end for container migration, wherein the source end runs a source container mounted with the original tmpfs;

[0018] The source end is used to: read the original tmpfs file metadata and mount metadata, and send the original tmpfs file metadata and mount metadata to the container management end. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source, and the file metadata includes the original inode number of the file.

[0019] The container management terminal is used to: send the original tmpfs file metadata and mount metadata to the target terminal;

[0020] The target end is used for:

[0021] When the mount point is created in the target container, the corresponding source device number is explicitly assigned to the created mount point based on the mount metadata.

[0022] When the file is created at the mount point, the corresponding original inode number is explicitly assigned to the created file based on the file metadata.

[0023] Fifthly, this application provides a server, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the server to perform the methods provided in any of the foregoing aspects.

[0024] Sixthly, this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the method provided in any of the foregoing aspects.

[0025] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in any of the foregoing aspects.

[0026] This application provides a file system processing method, system, server, storage medium, and program product. During container migration, in the container saving phase, the source end reads the original device number of the original TMPFS mount point and the original inode number of the files in the source container, and transmits these information to the target end through the container management end. In the container recovery phase, when the target end creates a mount point in the target container, it explicitly assigns the corresponding original device number to the created mount point based on the mount metadata, ensuring the consistency of the device number between the recovered target TMPFS and the original TMPFS. When creating a file in the mount point, it explicitly assigns the corresponding original inode number to the created file, ensuring the consistency of the file inode number between the recovered target TMPFS and the original TMPFS. This application's solution ensures the consistency of the device number and inode number of TMPFS before and after migration, avoiding anomalies / failures caused by inconsistencies in the device number and inode number before and after migration, thus improving system security and stability. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0028] Figure 1 An architecture diagram of a file system processing system provided as an exemplary embodiment of this application;

[0029] Figure 2 A schematic diagram of the framework of the TMPFS device number consistency guarantee mechanism provided for an exemplary embodiment of this application;

[0030] Figure 3A schematic diagram illustrating the framework of the tmpfs file inode number consistency guarantee mechanism provided in this application embodiment;

[0031] Figure 4 A flowchart illustrating a file system processing method provided in an exemplary embodiment of this application;

[0032] Figure 5 A schematic diagram illustrating the principle of the TMPFS device number consistency guarantee mechanism provided in this application embodiment;

[0033] Figure 6 A schematic diagram of the TMPFS device number namespace mechanism provided in the embodiments of this application;

[0034] Figure 7 A schematic diagram illustrating the principle of the tmpfs file inode number consistency guarantee mechanism provided in this application embodiment;

[0035] Figure 8 Example diagram of the tmpfs file inode number consistency guarantee mechanism provided in the embodiments of this application;

[0036] Figure 9 A flowchart of a file system processing method provided as another exemplary embodiment of this application;

[0037] Figure 10 A flowchart of a file system processing method provided as another exemplary embodiment of this application;

[0038] Figure 11 A flowchart of a file system processing method provided as another exemplary embodiment of this application;

[0039] Figure 12 This is a schematic diagram of the structure of a server provided in an embodiment of this application.

[0040] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0041] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0042] It should be noted that the user information (including but not limited to user device information, user attribute information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0043] First, let me explain the terms used in this application:

[0044] RunC containers: containers that achieve runtime isolation, characterized by the container sharing the kernel with the host machine.

[0045] RunD containers introduce a virtualization layer on top of ordinary containers to isolate the container kernel from the host kernel (i.e., the kernel of the host operating system). Their key features are performance isolation, security isolation, and fault isolation.

[0046] Container migration: Migrating a running container instance from one host to another while maintaining consistency in its state, memory, file system, and other information.

[0047] Temporary File System (tmpfs): Also known as the tmpfs file system, it is a memory-based temporary file system used to provide high-speed, volatile storage space at runtime, and is often used in scenarios that require temporary files or cache.

[0048] Device number: The identifier of the device to which the document belongs.

[0049] Inode number: A unique identifier for a file or directory in a file system.

[0050] Guest OS: The operating system installed inside a virtual machine.

[0051] Mount point: refers to the location of the tmpfs file system in the container directory tree, that is, the mount directory of the tmpfs file system.

[0052] In AI training / inference tasks, the underlying mechanism's support capabilities are crucial for achieving system resilience. To improve resource utilization and reduce GPU (Graphics Processing Unit) idle time, the system needs to have capabilities such as automatic scaling, fast startup, and warm / hot migration, thereby providing efficient serverless resilience.

[0053] AI training scenarios require save-and-restore and migration capabilities—specifically, the ability to save and restore task states. AI inference scenarios require elasticity, necessitating the ability to quickly resume services (i.e., restore from an image). However, regardless of the scenario, maintaining consistency of task states before and after save-and-restore and migration is crucial for stable system operation and a positive user experience. This is especially true during AI training, where users often use the tmpfs file system to cache intermediate data and accelerate execution.

[0054] With the widespread adoption of stateful containers in container orchestration platforms such as Kubernetes, support for container saving and recovery has been gradually enhanced through the integration of container migration tools.

[0055] Due to the temporary and memory-resident nature of TMPFS, during container migration, the source TMPFS needs to be packaged and stored during the save phase, and then decompressed and restored at the corresponding path on the target device during the restore phase, and the TMPFS is remounted. However, this method cannot guarantee the consistency between the TMPFS device number and the inode number before and after save and restore.

[0056] Many applications (such as AI training tasks, database caching, and file search tools) rely on these two metadata entries for file verification and access control. Containers often contain user processes that depend on the consistency of file system node information; failure to verify these two metadata entries will lead to anomalies. Inconsistencies between the tmpfs device number and the inode number can cause some basic tools (such as the find command and certain library functions) to fail when verifying files, resulting in unpredictable abnormal behavior and becoming a significant risk factor affecting system stability.

[0057] Therefore, a method is needed to solve the consistency problem of TMPFS during the save and restore process to ensure the correctness and reliability of AI training / inference tasks during elastic scheduling and migration.

[0058] This application provides a file system processing method. During container migration, in the saving phase, when the source end packages and stores the original TMPFS, it reads the original device number of the mount point of the original TMPFS in the source container and the original inode number of the file. This original device number and the original inode number of the file are then transmitted to the target end through the container management terminal. In the recovery phase, when the target end creates a mount point in the target container, it explicitly assigns the corresponding original device number to the created mount point based on the mount metadata, ensuring the consistency of the device number between the recovered target TMPFS and the original TMPFS. When creating a file in the mount point, it explicitly assigns the corresponding original inode number to the created file based on the file metadata, ensuring the consistency of the file inode number between the recovered target TMPFS and the original TMPFS. The solution proposed in this application can ensure the consistency of the device number and inode number of tmpfs before and after container migration, thereby avoiding anomalies / failures caused by the inconsistency between the device number and inode number of tmpfs before and after migration, and improving the security and stability of the system.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0060] Figure 1 This is an architecture diagram of a file system processing system provided as an exemplary embodiment of this application. This system architecture enables the saving and restoration of the tmpfs file system during container migration.

[0061] like Figure 1 As shown, the system architecture includes: the source end, the target end, and the container management end for container migration.

[0062] In this context, the source device refers to the device where the source container to be migrated resides. The source device runs the source container to be migrated, and the source container mounts the original tmpfs. The source container can be a container with an independent guest operating system, such as the RunD container, or a container that shares the operating system kernel with the host machine, such as the RunC container.

[0063] The target device refers to the device where the source container is migrated. The target container can be a container with an independent guest operating system, such as the RunD container, or a container that shares the operating system kernel with the host machine, such as the RunC container.

[0064] RunD containers run on the guest operating system of the source / target machine and have their own kernel space. RunC containers run on the host operating system of the source / target machine and share the kernel space with the host machine. Figure 1 Taking RunD containers with independent guest operating systems as an example, this paper illustrates the architecture of the tmpfs file system processing system in container migration scenarios.

[0065] When both the source and target ends have container runtimes, they provide a runtime environment for the running containers.

[0066] A container management platform, also known as a container control console, is an integrated set of tools and systems used to automate the deployment, management, scaling, and operation of containerized applications. The container management platform runs in user space.

[0067] In addition, to achieve container migration, both the source and target endpoints can run container migration tools, which run in user space. Taking RunD containers with independent guest operating systems (OS) as an example, the container migration tools on both the source and target endpoints, the kernels of the guest OSes of the source and target containers, and the container management interface work together to complete the container migration task. Container migration tools are a type of software specifically designed to quickly and reliably migrate applications and their runtime environments (including code, runtime, system tools, system libraries, and settings) from one computing environment to another. Examples include migration from physical machines to virtual machines, from virtual machines to physical machines, from one virtual machine to another, from one physical machine to another, from on-premises data centers to cloud platforms, from one cloud platform to another, and within the same cloud platform, migrating from an older version of a cluster or service to a newer version, etc.

[0068] For the tmpfs in the source container, since tmpfs is a memory file system dynamically managed by the kernel, its device number is assigned by the kernel during mounting, and its inode number is assigned by the kernel during file creation. User-space container migration tools cannot interfere with the allocation of tmpfs device numbers and inode numbers. Therefore, this embodiment starts from the kernel level and introduces a consistency guarantee mechanism for tmpfs metadata (including device numbers and inode numbers). Through the joint cooperation of the kernel, user-space container migration tools, and container management platform, the integrity and consistency of the tmpfs file system are achieved during the saving, recovery, and migration processes.

[0069] In this embodiment, a tmpfs device number consistency guarantee mechanism is introduced to ensure the consistency of tmpfs device numbers; a tmpfs file inode number consistency guarantee mechanism is also introduced to ensure the consistency of tmpfs file inode numbers.

[0070] For example, Figure 2 This is a schematic diagram illustrating the framework of the TMPFS device number consistency guarantee mechanism provided in this embodiment. Figure 2 As shown, the overall process of the TmpFS device number consistency guarantee mechanism is as follows:

[0071] Step 1: Read and report the original device number of the original TMPFS in the source container. During the container saving phase, the container migration tool on the source side reads and reports the original device number of the mount point in the original TMPFS in the source container. The original device number in the original TMPFS is read during container runtime. The original device number of the mount point in the original TMPFS is saved in a configuration file and sent to the container control end.

[0072] Step 2: Record the original device number of the original tmpfs. Before the container is restored, the container controller records the original device number of the mount point in the original tmpfs. Specifically, the container controller parses the configuration file and extracts the original device number from the original tmpfs.

[0073] Step 3: Pass the source device number from the original tmpfs. When starting the guest operating system, the container controller passes the source device number of the mount point in the original tmpfs to the target end by setting kernel boot parameters. The set kernel boot parameters include the source device number.

[0074] Step 4: Set kernel boot parameters to reserve the original device number from the original tmpfs. The target kernel creates a reserved device number pool based on the kernel boot parameters, reserving the original device number from the original tmpfs.

[0075] Step 5: Specify the original device number when mounting tmpfs. When performing the tmpfs mount operation, the container migration tool explicitly specifies the reserved original device number as the mount parameter.

[0076] The core of the TmpFS device number consistency guarantee mechanism lies in two key aspects: 1. The kernel must support the TmpFS device number reservation and allocation mechanism; 2. User-space container migration tools must support TmpFS device number saving and recovery strategies. These two core functionalities complement each other. The former ensures a controllable and predictable device number allocation mechanism from the underlying layer, while the latter is responsible for collecting and restoring device numbers in user space, together constructing a complete TmpFS device number consistency guarantee system.

[0077] The effectiveness of the kernel's support for the reservation and allocation mechanism of source device numbers depends on the user space's ability to accurately pass the required reserved source device number to the kernel. This requires the container migration tool to capture and record the source device number of the original tmpfs already mounted in the source container during the container saving phase, and to mount it by explicitly specifying the source device number during the container recovery phase.

[0078] Specifically, during the container preservation phase, the container migration tool iterates through the mount points in the source container, selects mount points with the tmpfs file system type, and writes their corresponding original device numbers to a configuration file. For example, when obtaining the original device number, the system kernel (such as the Linux kernel) can provide mount information interfaces to obtain precise mount metadata (such as the original device number, mount point path, mount source, etc.). During the container recovery phase, when the guest operating system (such as a guest OS) is started on the target end, the container management console sets kernel startup parameters via command line (cmdline) and passes the required original device number to the kernel of the target guest operating system. When restoring the container, the container migration tool on the target end adds a tmpfs mount option that explicitly specifies the device number and issues a tmpfs mount request with the explicitly specified device number. The kernel explicitly specifies the original device number of the mount point when performing the mount operation.

[0079] By combining the above kernel and user-space strategies, the consistency of the tmpfs device number before and after saving and restoring can be guaranteed.

[0080] For example, Figure 3 This is a schematic diagram illustrating the framework of the tmpfs file inode number consistency guarantee mechanism provided in this application embodiment. For example... Figure 3 As shown, the overall process of the tmpfs file inode number consistency guarantee mechanism is as follows:

[0081] Step 1: Package the mount point and save the original inode number corresponding to the files within the mount point.

[0082] During the container preservation phase, the source-side container migration tool can save the original inode numbers corresponding to each file in the original TMPFS. When reading the original inode numbers of files in the original TMPFS, this is done through the container runtime. The original inode numbers of the files in the original TMPFS are then saved in a configuration file and sent to the container control end.

[0083] For example, the container migration tool can record the mapping relationship between the filenames and inode numbers of each file in the original TMPFS, store this mapping relationship in a configuration file, and send it to the container control end. For instance, based on the mapping relationship between the filenames and inode numbers in the original TMPFS, a mapping image file can be built, recording the mapping relationship between the filenames and inode numbers in the original TMPFS. This mapping relationship between the filenames and inode numbers in the original TMPFS will serve as key reference data during the container recovery process.

[0084] Step 2: Restore the tmpfs mount point.

[0085] Step 3: Create the file and specify the original inode number.

[0086] During the container recovery phase, the data at the tmpfs mount point is decompressed and restored to recover the mount point. When creating files in the mount point, the original inode number of the file is explicitly specified by calling the kernel interface based on the mapping relationship between the file name and the original inode number in the original tmpfs, thereby ensuring the consistency of the file inode number in tmpfs before and after saving and restoring.

[0087] The core of the Tmpfs file inode number consistency guarantee mechanism lies in two key aspects:

[0088] 1. The kernel supports a tmpfs file creation interface that specifies the inode number to provide an underlying mechanism for explicitly specifying the file inode number.

[0089] 2. The user-space container migration tool supports TMPFS inode number mapping management, and completes the collection and restoration of the original TMPFS inode numbers.

[0090] These two core functionalities complement each other, together constructing a complete system for ensuring the consistency of TMPFS file inode numbers.

[0091] To ensure the consistency of file inode numbers in the tmpfs file system before and after container saving and restoration, a kernel-level mechanism is needed to support explicitly specifying inode numbers in tmpfs file creation. This mechanism, combined with user-space container migration tools, is required to collect and restore the original inode numbers of tmpfs files. This mechanism relies on the collaborative work of the kernel and user space to form a complete control loop, ensuring the consistency of file metadata from the container's perspective.

[0092] The tmpfs file inode number consistency guarantee mechanism takes effect when a file is created by calling a system call interface, therefore it is applicable to all types of containers (such as RunD and RunC containers). This kernel + user-space joint control architecture effectively solves the problem of inode number inconsistency caused by uncontrollable inode number allocation during the recovery process of traditional user-space container migration tools like tmpfs.

[0093] It's worth noting that in some example scenarios, only the tmpfs device number consistency guarantee mechanism needs to be introduced to ensure the consistency of tmpfs device numbers before and after container migration. In such scenarios, during the container saving phase, the source end does not need to save the original inode numbers of the files in tmpfs. During the container recovery phase, the relevant processing steps to ensure tmpfs device number consistency can be executed.

[0094] In some example scenarios, only the tmpfs file inode number consistency guarantee mechanism can be introduced to ensure the consistency of the tmpfs file inode number before and after container migration. In this scenario, during the container saving phase, the source end does not need to save the original tmpfs device number. During the container recovery phase, the relevant processing steps to ensure the consistency of the tmpfs file inode number can be performed.

[0095] In some example scenarios, both the TmpFS device number consistency guarantee mechanism and the TmpFS file inode number consistency guarantee mechanism can be introduced simultaneously to ensure the consistency of the TmpFS device number and file inode number before and after container migration. In this scenario, during the container saving phase, the source needs to save both the original TmpFS device number and the original inode number of the files in TmpFS. During the container recovery phase, it is necessary to perform relevant processing steps to ensure the consistency of both the TmpFS device number and the TmpFS file inode number.

[0096] The following section details the implementation process of introducing the TMPFS device number consistency guarantee mechanism and the TMPFS file inode number consistency guarantee mechanism.

[0097] Figure 4 A flowchart illustrating a file system processing method provided for an exemplary embodiment of this application. Figure 4 As shown, during container migration, to ensure the consistency between the device number and inode number in TMPFS, the following processing is required:

[0098] Step S400: The source end reads the original tmpfs file metadata and mount metadata.

[0099] Step S401: The source end sends the original tmpfs file metadata and mount metadata to the container management end.

[0100] In this embodiment, before container migration, the tmpfs in the source container is called the original tmpfs, the device number of the original tmpfs is called the original device number, and the inode number of the files in the original tmpfs is called the original inode number. After container migration, the tmpfs in the target container is called the target tmpfs. The scheme of this embodiment aims to ensure that the device number of the target tmpfs is consistent with the original device number of the original tmpfs before and after container migration, and that the inode number of the files in the target tmpfs is consistent with the original inode number of the same files in the original tmpfs.

[0101] The container migration tool plays a crucial role in the container save and restore process. During the container save phase, it is responsible for collecting the original device number and / or original inode number of the tmpfs mount point during container runtime, and during the container restore phase, it explicitly specifies the original device number when mounting the tmpfs and explicitly specifies the original inode number of the file when creating the file.

[0102] During the container preservation phase, the source container migration tool can traverse the original tmpfs mount points in the source container, read the metadata and file content of each mount point, and package and store the original tmpfs.

[0103] In this embodiment, the metadata read from the source includes mount metadata and file metadata. The mount metadata includes the original device number of the mount point, the mount point path, and the mount source; the file metadata includes the original inode number of the file.

[0104] Additionally, mount metadata can include mount point options for setting permissions, owner, and group for the mount point's root directory. File metadata can also include a file's unique identifier, name, type, size, permissions, timestamp, and extended attributes (such as optional, key-value pairs for storing security tags, capability sets, or other application-defined information).

[0105] In this embodiment, during the container saving phase, the source reads the original TMPFS file content and metadata (including file metadata and mount metadata). Based on existing solutions, the device number of the mount point and the inode number of the file are added. What other data besides the device number and inode number needs to be obtained can be set according to actual application requirements and the selected container migration algorithm; no specific limitations are made here.

[0106] Step S402: The container management terminal transmits the original tmpfs file metadata and mount metadata to the target terminal.

[0107] In this step, the container management end receives the original TMPFS file content and metadata sent by the source end. The original TMPFS metadata includes file metadata and mount metadata. The container management end then transfers the original TMPFS file content and metadata to the target end.

[0108] In one optional embodiment, the source end can write the original TMPFS file metadata and mount metadata into a configuration file. The configuration file is then sent to the container management end.

[0109] The container management endpoint receives the configuration file sent by the source endpoint, parses the configuration file, and obtains the original TMPFS file metadata and mount metadata. The container management endpoint then sends the original TMPFS file metadata and mount metadata to the target endpoint.

[0110] The target receives file metadata and mount metadata from the original temporary file system tmpfs in the source container.

[0111] Step S403: When the target end creates a mount point in the target container, it explicitly assigns the corresponding source device number to the created mount point based on the mount metadata.

[0112] When the target end creates a mount point in the target container, for any first mount point that needs to retain its original device number (such as any mount point in the target tmpfs of this migration), the target container runtime initiates a tmpfs mount request that explicitly specifies the device number. This tmpfs mount request includes the original device number of the first mount point, the mount point path, and the mount source. For example, the target container migration tool, by calling the tmpfs mount interface that explicitly specifies the device number, and using the original device number, mount point path, and mount source of the first mount point as input references, initiates a tmpfs mount request with the explicitly specified device number to the kernel.

[0113] Currently, the mainstream container technologies mainly include RunC containers and RunD containers. RunC containers achieve runtime isolation based on Linux kernel control groups (cgroups) and namespaces, and their characteristic is that they share the same kernel with the host machine. RunD containers introduce a virtualization layer on top of RunC, encapsulating the container with a lightweight virtual machine, thereby achieving isolation between the container kernel and the host kernel. This approach not only retains good performance but also further improves system security, stability, and fault isolation capabilities.

[0114] RunD containers and RunC containers differ in isolation mechanisms, performance, and security features. Unlike RunD containers, which are based on a virtualization layer, RunC containers do not have an independent kernel space; instead, they share the same kernel with the host machine.

[0115] In one example scenario, for the target container with a corresponding independent guest operating system, the TmpFS device number consistency guarantee mechanism includes the TmpFS device number reservation mechanism and the device number assignment mechanism.

[0116] In system kernels (such as the Linux kernel), the device number allocation mechanism of tmpfs relies on the IDA (Identifier Allocator), which dynamically manages globally unique identifier resources. To ensure that a specified device number can be exclusively used by an explicitly mounted tmpfs filesystem, the device number must be reserved before the tmpfs filesystem is initialized. Considering that other modules or kernel components may already be using tmpfs device numbers during system initialization, the device number reservation operation needs to be implemented through kernel boot parameters.

[0117] In this embodiment, based on the tmpfs device number reservation mechanism, the target end reserves the original device number based on the kernel boot parameters when starting the guest operating system of the target container.

[0118] For example, the container management endpoint sends kernel command lines to the target endpoint based on the mount metadata. These kernel command lines are used to set the kernel boot parameters for the guest operating system. The kernel boot parameters include the source device number.

[0119] The target end receives the kernel command line sent by the container management end and determines the kernel startup parameters set in the kernel command line (including the original device number to be reserved). The target end starts the guest operating system, and the kernel of the guest operating system creates a reserved device number pool according to the original device number to be reserved in the kernel startup parameters, adds the original device number to the reserved device number pool, and sets the status of the original device number in the reserved device number pool to reserved but not used.

[0120] In addition, to prevent the reserved native device numbers from being occupied by other tmpfs, after adding the native device numbers to the reserved device number pool, the status of these native device numbers in the global device number pool is set to used.

[0121] In a traditional TMPFS architecture, only one global device number pool is maintained to manage all device numbers. Device numbers are categorized into two states: "unused (or idle)" and "used." This embodiment adds a reserved device number pool, where device numbers have two states: "reserved but not used" and "reserved and used." "Reserved but not used" means the device number has been reserved in the pool but not yet mounted. "Reserved and used" means the device number has been reserved in the pool and is being used by an explicitly mounted TMPFS instance. In this embodiment, the original global device number pool is retained, and device numbers in the global pool still have the two states: "unused (or idle)" and "used." "Used" indicates the device has been mounted or reserved in the pool. "Unused (or idle)" indicates the device has neither been mounted nor reserved in the pool.

[0122] In this embodiment, during the system initialization phase on the target end, the container management end transmits a set of source device numbers to be reserved via kernel startup parameters in user space. The target end's guest operating system kernel then requests source device numbers to be reserved from the global device number pool and adds these source device numbers to the reserved device number pool for management. In the global device number pool, the status of these reserved source device numbers is set to "used" to prevent tmpfs mount requests that do not explicitly specify device numbers from misusing these reserved device numbers.

[0123] For a tmpfs mount request that explicitly specifies a device number, the guest operating system kernel of the target container performs the following atomic operation:

[0124] Based on the mount point path and mount source of the first mount point, create the first mount point in the target container; based on the original device number of the first mount point, assign the corresponding original device number to the created first mount point in the reserved device number pool, and update the status of the original device number of the first mount point in the reserved device number pool to reserved and used.

[0125] For example, when assigning a corresponding original device number to the created first mount point from the reserved device number pool, the status of the original device number of the first mount point is queried from the reserved device number pool. If the status of the original device number of the first mount point is reserved but not used, the original device number of the first mount point is assigned to the created first mount point, and the status of the original device number of the first mount point is updated to reserved and used.

[0126] If the original device number for the first mount point does not exist in the reserved device number pool, it means that the original device number for the first mount point has not been reserved, and the mount will fail, returning a first mount failure message. The first mount failure message is used to indicate that the mount failed, and the reason for the failure is that the original device number for the first mount point has not been reserved.

[0127] If the original device number for the first mount point exists in the reserved device number pool, and the status of the original device number for the first mount point is "reserved and in use," it means that although the original device number for the first mount point was reserved, it has already been occupied. Therefore, the mount fails, and a second mount failure message is returned. The second mount failure message is used to indicate that the mount failed, and the reason for the failure is that although the corresponding original device number was reserved, it has already been occupied by another mount point.

[0128] In this embodiment, to ensure consistency between device number allocation and mounting operations, the operations of specifying the device number and mounting the tmpfs are designed as atomic operations in a concurrent environment. Otherwise, the expected device number may differ from the actual allocation result. Therefore, this solution introduces a tmpfs mounting option that supports explicitly specifying the device number, ensuring that tmpfs mounting requests with explicitly specified device numbers can safely and orderly obtain device numbers from the reserved device number pool.

[0129] When a tmpfs mount request without a specified device number is received, the kernel only allocates an idle device number from the global device number pool and does not access the reserved device number pool.

[0130] For example, for any second mount point on the target end that does not need to retain the original device number (such as a mount point of a tmpfs other than the target tmpfs), a tmpfs mount request without a specified device number is initiated through the container runtime. This tmpfs mount request without a specified device number includes the mount point path and mount source of the second mount point, but does not include the device number specified for the second mount point. For instance, the container migration tool on the target end initiates a tmpfs mount request without a specified device number to the guest operating system kernel of the target container by calling the tmpfs mount interface without a specified device number.

[0131] For a tmpfs mount request without a specified device number, the guest operating system kernel of the target container performs the following atomic operation:

[0132] Based on the mount point path and mount source of the second mount point, create a second mount point in the target container; in the global device number pool, assign an unused device number to the created second mount point, and update the status of the assigned device number to used.

[0133] In this embodiment, for each independent guest operating system target container, a TMPFS device number consistency guarantee mechanism based on device number reservation is introduced. The core of this mechanism is: during the system initialization phase, the original TMPFS device numbers that need to be reserved are allocated from the global device number pool to the reserved device number pool, and the reserved device numbers are marked with a status in the global device number pool to distinguish between ordinary device numbers and reserved device numbers.

[0134] For example, Figure 5 This is a schematic diagram illustrating the TMPFS device number consistency guarantee mechanism provided in this embodiment. Figure 5 As shown, device numbers in the reserved device number pool have two states: "Reserved but not used" and "Reserved and used". "Reserved but not used" means the device number has been reserved in the reserved device number pool but has not yet been mounted and used. "Reserved and used" means the device number has been reserved in the reserved device number pool and has been used by an explicitly mounted tmpfs. Device numbers in the global device number pool also have two states: "Unused" and "Used". "Used" indicates that the device number has been mounted and used or reserved in the reserved device number pool. "Unused" indicates that the device number has not been mounted and used and has not been reserved in the reserved device number pool.

[0135] like Figure 5As shown, during the container recovery phase, when performing a tmpfs mount operation, for tmpfs mount requests without a specified device number, the kernel allocates an idle device number from the global device number pool and cannot access the reserved device number pool. For tmpfs mount requests with an explicitly specified device number, the kernel allocates the explicitly specified device number from the reserved device number pool (its status is reserved but not used). Only when a target device number is explicitly specified during mount will the kernel attempt to allocate from the reserved device number pool. This mechanism is characterized by its simplicity and clear control. By introducing a reserved device number pool and device number status classification, it effectively achieves fine-grained control over tmpfs device number resources, ensuring the consistency of device numbers in the tmpfs file system during container saving and recovery.

[0136] In one example scenario, for an architecture where multiple containers share the same host kernel, the tmpfs device number reservation mechanism faces the following risks: multiple containers sharing the same host kernel means that multiple containers share a single reserved device number pool. Different containers may be assigned the same reserved device number when mounting tmpfs, resulting in non-unique device number identifiers and disrupting the consistency of file system semantics.

[0137] In one optional embodiment, for target containers (such as RunC containers) that share the operating system kernel with the host machine, the tmpfs device number consistency guarantee mechanism includes a tmpfs device number namespace mechanism and a device number assignment mechanism. By introducing the tmpfs device number namespace mechanism, this mechanism creates independent tmpfs device number namespaces for each container, isolating the device number allocation logic within different containers and ensuring that containers do not interfere with each other. Within their respective tmpfs device number namespaces, device numbers can be freely allocated, reclaimed, and managed without worrying about conflicts with other containers. The mapping relationship between device numbers within the tmpfs device number namespace and the actual device numbers existing in the host machine kernel is maintained by the host machine kernel.

[0138] Based on the aforementioned embodiments, in this embodiment, an independent tmpfs device number namespace is created for the target container during the container runtime, and a system call is invoked (causing the kernel) to establish a mapping relationship between the tmpfs device number namespace and the real device number.

[0139] For example, Figure 6 This is a schematic diagram of the TMPFS device number namespace mechanism provided in this embodiment. Figure 6 As shown, containers A and B each have their own independent tmpfs device number namespaces. Within their respective tmpfs device number namespaces, devices can be freely allocated, reclaimed, and managed without worrying about conflicts with other containers. For example, as... Figure 6 As shown, both container A and container B have the following device numbers in their tmpfs device namespaces: 1, 2, 3, and 4. The host kernel maintains the device numbers within each tmpfs device namespace, and the mapping between these device numbers and the actual device numbers in the global device pool (device numbers 1-12 as shown in the figure) is also maintained by the host kernel. The device numbers in the figure are for illustrative purposes only and may not represent the actual device numbers used in real-world applications.

[0140] In this embodiment, for any first mount point that needs to retain the original device number, the target container runtime initiates a tmpfs mount request with an explicitly specified device number to request the host operating system kernel to perform the following atomic operation:

[0141] Based on the mount point path and mount source of the first mount point, create the first mount point in the target container; assign the corresponding source device number to the created first mount point in the tmpfs device number namespace of the target container. The tmpfs mount request includes the source device number, mount point path, and mount source of the first mount point.

[0142] Step S404: When the target end creates a file in the mount point, it explicitly assigns the corresponding original inode number to the created file based on the file metadata.

[0143] In practical applications, the tmpfs implementation in the system kernel (such as the Linux kernel) already ensures that the file inode number is consistent with the file creation order. However, user-space container migration tools use a "packaging-decompression" method to save and restore tmpfs. During the decompression and restoration process, the order in which files are created is often different from the original actual creation order of the files. This results in the inode number after restoration being inconsistent with the original inode number of the file before saving.

[0144] The inode number, as a unique metadata identifier for a file in the file system, is assigned by the kernel and cannot be directly interfered with by user-space programs (such as container migration tools). Furthermore, modifying the inode number of an already created file is a high-risk operation that could lead to file system structural anomalies or data corruption, making it impractical.

[0145] To address the aforementioned issues, this embodiment introduces a tmpfs file inode number consistency guarantee mechanism. It introduces a tmpfs file creation interface in the kernel that supports explicitly specifying the inode number, thereby achieving strong consistency between the file creation and its expected inode number.

[0146] When creating a mount point, the kernel creates an explicit inode number pool for tmpfs mount points that require metadata consistency, which is used to store the original inode numbers of the files in the mount point.

[0147] Optionally, when creating a mount point in the target container, after explicitly assigning the corresponding source device number to the created mount point based on the mount metadata, the kernel creates an explicit inode number pool for the mount point; the source inode number of the file in the mount point is added to the explicit inode number pool of the mount point, and the status of the source inode number is set to unused.

[0148] For any third mount point that needs to maintain file metadata consistency (such as any mount point in the target tmpfs for this migration), when creating the target file in the third mount point, the container migration tool on the target end initiates a tmpfs file creation request with an explicitly specified inode number through the target container's runtime. This tmpfs file creation request includes the specified original inode number. For example, the container migration tool initiates a tmpfs file creation request with an explicitly specified inode number by calling the tmpfs file creation interface with the explicitly specified inode number and specifying the original inode number as an input parameter.

[0149] For a tmpfs file creation request that explicitly specifies the inode number, the operating system kernel corresponding to the target container (such as a standalone guest operating system kernel or an operating system kernel shared with the host machine) performs the following atomic operation:

[0150] Create the target file at the third mount point; based on the original inode number of the target file in the file metadata, assign the original inode number of the target file to the created target file in the explicit inode number pool.

[0151] For example, based on the file metadata, the original inode number corresponding to the target file is assigned to the created target file from the explicit inode number pool. This can be implemented in the following way:

[0152] Based on the original inode number corresponding to the target file in the file metadata, query the status of the original inode number corresponding to the target file in the explicit inode number pool. If the status of the original inode number corresponding to the target file is unused, then the original inode number corresponding to the target file is assigned to the target file, and the status of the assigned original inode number is updated to used.

[0153] If the original inode number corresponding to the target file does not exist in the explicit inode number pool, or if the original inode number corresponding to the target file in the explicit inode number pool is in use, the mount will fail, and a third mount failure message will be returned. This third mount failure message indicates that the mount failed and that the reason for the failure is that the explicitly specified inode number allocation failed.

[0154] In this embodiment, when a tmpfs file creation request with an explicitly specified inode number is received, the kernel allocates the specified inode number from the explicit inode number pool. By designing the file creation and inode number allocation operations as atomic operations, that is, the file creation and inode number allocation are executed as a whole, inode number conflicts or race conditions of duplicate inode number allocation in concurrent scenarios can be prevented.

[0155] Additionally, for any fourth mount point where maintaining file metadata consistency is not required, when creating a target file in that fourth mount point, the container migration tool on the target end initiates a tmpfs file creation request without specifying an inode number through the target container's runtime. This tmpfs file creation request does not include the specified original inode number. For example, the container migration tool initiates a tmpfs file creation request without specifying an inode number by calling the tmpfs file creation interface without specifying an inode number.

[0156] For a tmpfs file creation request that does not specify an inode number, the kernel allocates an inode number to the file from the explicit inode number pool of the mount point according to preset rules. For example, it allocates the smallest inode number among the inode numbers that are in a free state.

[0157] For example, Figure 7 This is a schematic diagram illustrating the tmpfs file inode number consistency guarantee mechanism provided in this embodiment. Figure 7 As shown, the inode numbers in the explicit inode number pool have two states: "used" and "idle". During the container recovery phase, when performing file creation operations on mount points that require maintaining file metadata consistency, for tmpfs file creation requests that explicitly specify inode numbers, the kernel allocates the explicitly specified inode number from the mount point's explicit inode number pool (in an idle state).

[0158] like Figure 7 As shown, when performing file creation operations on mount points that do not require maintaining file metadata consistency, for tmpfs file creation requests that do not specify an inode number, the kernel allocates the smallest available inode number from the explicit inode number pool of the mount point.

[0159] For example, Figure 8 This is an example diagram illustrating the tmpfs file inode number consistency guarantee mechanism provided in this embodiment. Figure 8 As shown, the process of introducing the tmpfs file inode number consistency guarantee mechanism is as follows:

[0160] Step 1: Save the mapping relationship between filenames and inode numbers to the mount point image.

[0161] During the container preservation phase, the source-side container migration tool saves the mapping relationship between filenames and inode numbers of each file in the original TMPFS to the mount point image when saving the mount point image. The mount point image stores the file content and file metadata of the mount point. The file metadata includes the mapping relationship between filenames and inode numbers. For example... Figure 8 As shown, taking the mount point " / tmp / targetdlr" as an example, there are three files under this mount point: a.txt, b.txt, and c.txt. The inode numbers of these three files are 127, 256, and 511, respectively.

[0162] Step 2: Recover the files.

[0163] During the container recovery phase, the target container migration tool restores the files in the mount point by unpacking the mount point image.

[0164] Step 3: Call the tmpfs file creation interface that explicitly specifies the inode number.

[0165] The target container migration tool initiates a tmpfs file creation request by calling the tmpfs file creation interface that explicitly specifies the inode number, and specifying the original inode number as an input parameter. The kernel creates the corresponding file and assigns the file the original inode number.

[0166] In the tmpfs file inode number consistency guarantee mechanism, the container migration tool is responsible for collecting the tmpfs mount point and its file metadata (including the original inode number) during the container saving phase, and restoring the files one by one and explicitly specifying the original inode number of the files during the container recovery phase.

[0167] In this embodiment, the container migration tool has the following capabilities: during the container saving phase, it collects and persists the mapping relationship between filenames and inode numbers in the tmpfs file system; during the container recovery phase, it reconstructs the file structure according to the specified inode numbers by calling the interface provided by the kernel. The container migration tool uses a "packaging-decompression" mechanism when saving and restoring the tmpfs file system. The decompression process is actually the process of creating files. In this embodiment, during this process, it directly calls the tmpfs file creation interface provided by the kernel that explicitly specifies the inode number, thereby ensuring that the inode number of the file is consistent with the original inode number before saving.

[0168] The solution in this embodiment implements a TmpFS device number reservation and allocation mechanism, a TmpFS device number namespace mechanism and device number allocation mechanism, and a TmpFS inode number allocation mechanism in the kernel. Specifically, for the target container corresponding to an independent guest operating system, a TmpFS device number reservation and allocation mechanism is introduced. Device numbers requiring reservation are allocated to a reserved device number pool based on kernel boot parameters. Furthermore, the TmpFS mount interface for explicitly specifying device numbers is extended to support TmpFS mount requests with explicitly specified device numbers.

[0169] For target containers that share the operating system kernel with the host machine, a tmpfs device number namespace mechanism and a device number assignment mechanism are introduced to extend the kernel namespace mechanism and create a separate tmpfs device number namespace for each container. This ensures that containers do not interfere with each other and effectively avoids device number conflicts that may be caused by sharing the reserved device number pool in scenarios where multiple containers share the same host machine kernel (such as RunC container).

[0170] The TMPFS inode number assignment mechanism implements a TMPFS file creation interface that supports explicit specification of inode numbers, thereby achieving strong consistency between the file creation and its expected inode number (i.e., the original inode number).

[0171] Combining the above mechanisms, a solution is provided to coordinate the preservation and restoration of TMPFS metadata across the kernel, container management platform, and user-space container migration tools. During the container preservation phase, the container migration tool, in addition to preserving the regular data of the TMPFS file system, also saves the device number and file inode number of the TMPFS mount point. During the container recovery phase, the container migration tool mounts TMPFS by explicitly specifying the original device number and explicitly specifies the original inode number of the file through the kernel interface when rebuilding the file content, thereby ensuring that the metadata of the restored TMPFS, including the device number and file inode number, remains consistent with the original state.

[0172] Figure 9 This is a flowchart illustrating a file system processing method provided as another exemplary embodiment of this application. The execution entity in this embodiment is the target device for container migration. Figure 9 As shown, the processing flow on the target side during container migration is as follows:

[0173] Step S901: Obtain the file metadata and mount metadata of the original temporary file system tmpfs in the source container. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source. The file metadata includes the original inode number of the file.

[0174] Step S902: When creating a mount point in the target container, explicitly assign the corresponding source device number to the created mount point based on the mount metadata.

[0175] Step S903: When creating a file in the mount point, explicitly assign the corresponding original inode number to the created file based on the file metadata.

[0176] In this embodiment, the implementation principle and technical effects of the target device during container migration are detailed in the foregoing embodiments and will not be repeated here.

[0177] Figure 10 This is a flowchart illustrating a file system processing method provided as another exemplary embodiment of this application. The execution entity in this embodiment is the source device for container migration. Figure 10 As shown, the processing flow of the source device during container migration is as follows:

[0178] Step S1001: Read the file metadata and mount metadata of the original tmpfs in the source container. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source. The file metadata includes the original inode number of the file.

[0179] Step S1002: Write the original tmpfs file metadata and mount metadata into the configuration file.

[0180] Step S1003: Send the configuration file to the container management terminal so that the container management terminal can send the original tmpfs file metadata and mount metadata to the target terminal.

[0181] In this embodiment, the implementation principle and technical effects of the source device during container migration are detailed in the foregoing embodiments and will not be repeated here.

[0182] Figure 11 A flowchart illustrating a file system processing method provided as another exemplary embodiment of this application. The execution entity in this embodiment is a container management platform. Figure 11 As shown, the container management platform's processing flow during container migration is as follows:

[0183] Step S1101: Receive the configuration file sent by the source.

[0184] Step S1102: Parse the configuration file to obtain the original tmpfs file metadata and mount metadata. The mount metadata includes: the original device number of the mount point, the mount point path and the mount source. The file metadata includes the original inode number of the file.

[0185] Step S1103: Transfer the original tmpfs file metadata and mount metadata to the target end.

[0186] In one optional embodiment, the container management platform sends a kernel command line to the target based on the mount metadata. The kernel command line is used to set the kernel boot parameters of the guest operating system of the target container. The kernel boot parameters include the source device number.

[0187] In this embodiment, the implementation principle and technical effects of the container management platform during container migration are detailed in the aforementioned embodiments and will not be repeated here.

[0188] Figure 12 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Figure 12 As shown, the server includes a memory 1201 and a processor 1202. The memory 1201 stores computer-executable instructions and can be configured to store various other data to support operations on the server. The processor 1202 is communicatively connected to the memory 1201 and executes the computer-executable instructions stored in the memory 1201 to implement the technical solutions provided by the source device, target device, or container management terminal in any of the above method embodiments. Their specific functions and the technical effects they can achieve are similar and will not be repeated here.

[0189] Optional, such as Figure 12 As shown, the server also includes other components such as a firewall 1203, a load balancer 1204, a communication component 1205, and a power supply component 1206. Figure 12 The diagram only shows some components and does not mean that the server only includes... Figure 12 The components shown. Figure 12 This example uses a cloud server deployed in the cloud as an example, but the server can also be deployed locally. This embodiment does not make any specific limitations here.

[0190] This application also provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the method of any of the foregoing embodiments. The specific functions and technical effects to be achieved are not described here.

[0191] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments. The computer program is stored in a readable storage medium, and at least one processor of the server can read the computer program from the readable storage medium. The execution of the computer program by the at least one processor causes the server to perform the technical solutions provided by the source device, target device, or container management terminal in any of the above method embodiments. The specific functions and the technical effects that can be achieved are not described here.

[0192] This application provides a chip, including a processing module and a communication interface. The processing module is capable of executing the technical solutions of the source device, target device, or container management terminal in the aforementioned method embodiments. Optionally, the chip further includes a storage module (e.g., a memory), which stores instructions. The processing module executes the instructions stored in the storage module, and the execution of the instructions stored in the storage module causes the processing module to execute the technical solutions provided in any of the aforementioned method embodiments.

[0193] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0194] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), a graphics processing unit (GPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules in at least one processor.

[0195] The memory may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0196] The aforementioned storage device can be object storage service (OSS).

[0197] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0198] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as mobile hotspots (WiFi), second-generation (2G), third-generation (3G), fourth-generation (4G) / Long Term Evolution (LTE), fifth-generation (5G), or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), infrared, Ultra Wide Band (UWB), Bluetooth, and other technologies.

[0199] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0200] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0201] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside within an application-specific integrated circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components within an electronic device or host device.

[0202] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0203] The order of the embodiments described above is merely for illustrative purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The sequence numbers are merely used to distinguish different operations, and the sequence numbers themselves do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types. "Multiple" means two or more, unless otherwise explicitly specified.

[0204] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0205] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0206] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A file system processing method characterized by, The method applied to a target end of container migration comprises: obtaining file metadata and mounting metadata of an original tmpfs in a source container, wherein the mounting metadata comprises an original device number of a mounting point, and the file metadata comprises an original inode number of a file; when the mounting point is created in a target container, allocating a specified original device number to the created mounting point according to the mounting metadata; when the file is created in the mounting point, allocating a specified original inode number to the created file according to the file metadata.

2. The method of claim 1, wherein, The target container corresponds to an independent client operating system, and the method further comprises: when the client operating system of the target container is started, reserving the original device number based on kernel startup parameters.

3. The method of claim 2, wherein, The step of reserving the original device number based on kernel startup parameters when the client operating system of the target container is started comprises: receiving a kernel command line sent by a container management end; determining kernel startup parameters set by the kernel command line, wherein the kernel startup parameters contain the original device number; starting the client operating system, and creating a reserved device number pool through the kernel of the started client operating system according to the kernel startup parameters, adding the original device number to the reserved device number pool, and setting a state of the original device number in the reserved device number pool as reserved and unused.

4. The method of claim 3, wherein, The mounting metadata further comprises a mounting point path and a mounting source of the mounting point, and the step of allocating a specified original device number to the created mounting point according to the mounting metadata when the mounting point is created in the target container comprises: for any first mounting point that needs to reserve an original device number, initiating an explicit device number specified tmpfs mounting request through a container runtime of the target container, to request the kernel to perform the following atomic operations: creating the first mounting point in the target container according to the mounting point path and the mounting source of the first mounting point; allocating a corresponding original device number to the created first mounting point in the reserved device number pool, and updating a state of the allocated original device number as reserved and used; wherein the tmpfs mounting request contains the original device number, the mounting point path and the mounting source of the first mounting point.

5. The method of claim 4, wherein, The step of allocating a corresponding original device number to the created first mounting point in the reserved device number pool comprises: inquiring a state of the original device number of the first mounting point in the reserved device number pool; if the state of the original device number of the first mounting point is reserved and unused, allocating the original device number of the first mounting point to the created first mounting point.

6. The method of claim 3, wherein, The method further comprises: after adding the original device number to the reserved device number pool, setting a state of the original device number in a global device number pool as used; for any second mounting point that does not need to reserve an original device number, initiating a device number unspecified tmpfs mounting request through the container runtime, to request the kernel to perform the following atomic operations: creating the second mount point in the target container according to the mount point path and the mount source of the second mount point; allocating an unused device number to the created second mount point in the global device number pool, and updating the status of the allocated device number to used.

7. The method of claim 1, wherein, The target container shares an operating system kernel with a host machine, and the method further comprises: creating an independent tmpfs device number namespace for the target container through a container runtime of the target container, and invoking a system call to establish a mapping relationship between device numbers in the tmpfs device number namespace and real device numbers existing in the operating system kernel.

8. The method of claim 7, wherein, When creating the mount point in the target container, the specified original device number is allocated to the created mount point according to the mount metadata, including: For any first mount point that needs to retain the original device number, an explicit device number specified tmpfs mount request is initiated through the container runtime of the target container to request the operating system kernel of the host machine to perform the following atomic operation: creating the first mount point in the target container according to the mount point path and the mount source of the first mount point; allocating a corresponding original device number to the created first mount point in the tmpfs device number namespace of the target container; The tmpfs mount request contains the original device number, mount point path and mount source of the first mount point.

9. The method according to any one of claims 1-8, characterized in that, After the step of allocating the specified original device number to the created mount point according to the mount metadata in the manner of specifying the original device number when creating the mount point in the target container, the method further comprises: creating an explicit index node number pool for the mount point; adding the original index node number of the file in the mount point to the explicit index node number pool of the mount point, and setting the status of the original index node number to unused.

10. The method of claim 9, wherein, When creating the file in the mount point, the specified original index node number is allocated to the created file according to the file metadata in the manner of specifying the original index node number, including: For any third mount point that needs to maintain file metadata consistency, when creating a target file in the third mount point, an explicit index node number specified tmpfs file creation request is initiated through the container runtime of the target container to request the operating system kernel corresponding to the target container to perform the following atomic operation: creating the target file in the third mount point; allocating the original index node number corresponding to the created target file to the target file according to the file metadata in the explicit index node number pool.

11. The method of claim 10, wherein, The step of allocating the original index node number corresponding to the created target file to the target file according to the file metadata in the explicit index node number pool, includes: According to the file metadata, querying the status of the original index node number corresponding to the target file in the explicit index node number pool; If a state of an original inode number corresponding to the target file is unused, the original inode number corresponding to the target file is allocated to the target file, and a state of the allocated original inode number is updated to used.

12. A file system processing method characterized by comprising: The method applied to a source end of container migration comprises: reading file metadata and mounting metadata of an original tmpfs in a source container, wherein the mounting metadata comprises an original device number of a mounting point, a mounting point path and a mounting source, and the file metadata comprises an original inode number of a file; writing the file metadata and the mounting metadata of the original tmpfs into a configuration file; sending the configuration file to a container management end, so that the container management end sends the file metadata and the mounting metadata of the original tmpfs to a target end.

13. A file system processing method characterized by comprising: The method applied to a container management end comprises: receiving a configuration file sent by a source end; parsing the configuration file to obtain file metadata and mounting metadata of an original tmpfs, wherein the mounting metadata comprises an original device number of a mounting point, a mounting point path and a mounting source, and the file metadata comprises an original inode number of a file; transmitting the file metadata and the mounting metadata of the original tmpfs to a target end.

14. The method of claim 13, wherein, Further comprising: sending a kernel command line to the target end according to the mounting metadata, wherein the kernel command line is used to set a kernel start parameter of a guest operating system of a target container, and the kernel start parameter contains the original device number.

15. A file system processing system characterized by Comprise: a source end, a target end and a container management end of container migration, wherein the source end runs a source container with an original tmpfs mounted thereon; the source end is configured to read file metadata and mounting metadata of the original tmpfs, and send the file metadata and the mounting metadata of the original tmpfs to a container management end, wherein the mounting metadata comprises an original device number of a mounting point, and the file metadata comprises an original inode number of a file; the container management end is configured to send the file metadata and the mounting metadata of the original tmpfs to the target end; the target end is configured to: when creating the mounting point in a target container, allocate a specified original device number to the created mounting point in a manner of specifying the original device number according to the mounting metadata; when creating the file in the mounting point, allocate a specified original inode number to the created file in a manner of specifying the original inode number according to the file metadata.

16. The system of claim 15, wherein: the container management end is further configured to send a kernel command line to the target end according to the mounting metadata, wherein the kernel command line is used to set a kernel start parameter of a guest operating system, and the kernel start parameter contains the original device number.

17. The system of claim 16, wherein: the target end is further configured to: receive the kernel command line sent by the container management end; determine a kernel start parameter set by the kernel command line, wherein the kernel start parameter contains the original device number. The client operating system is started, a reserved device number pool is created according to the kernel start parameters through the kernel of the client operating system, the original device number is added into the reserved device number pool, and the state of the original device number in the reserved device number pool is set as reserved and unused.

18. A server, characterized by The method comprises: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to cause the server to perform the method of any one of claims 1-14.

19. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and when the processor executes the computer execution instructions, the method of any one of claims 1-14 is implemented.

20. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-14.

Images