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

Abstract

The invention provides a file system processing method and system, a server, a storage medium and a program product. The method is suitable for a container migration scene, in a container storage stage, a source end reads an original device number of a mounting point of original tmpfs in a source container and an original index node number of a file, and transmits the original device number and the original index node number to a target end through a container management and control end; in the container recovery stage, the target end explicitly allocates the corresponding original device number to the created mounting point when creating the mounting point, so that the consistency of the device numbers before and after the tmpfs is stored and recovered can be ensured. When the file is created in the mounting point, the corresponding original index node number is explicitly allocated to the created file, so that the consistency of the file index node numbers before and after the tmpfs is stored and recovered can be ensured, the abnormality / fault caused by the inconsistency of the device number and the index node number before and after the tmpfs is migrated can be avoided, and the security and stability of the system are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to a file system processing method and system, a server, a storage medium and a program product. BACKGROUND

[0002] With the wide application of container technology in the fields of cloud computing, AI (artificial intelligence) training, microservices, etc., container migration has become a key technology for realizing elastic scaling, fault recovery and load balancing. The core goal of container migration is to maintain the consistency of the running state of the container, including memory, file system, network connection, etc.

[0003] However, for a memory-based temporary file system (tmpfs), the tmpfs file system cannot guarantee the consistency of the device number and the inode number, which are two metadata, in the migration process due to its volatility (data only exists in memory) and dynamic metadata allocation (device number and inode number are dynamically allocated by the kernel). Many application programs (such as AI training tasks, database caches, file search tools, etc.) rely on these two metadata for file verification and access control, which may cause abnormality or even crash after migration. SUMMARY

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

[0005] In a first aspect, the present application provides a file system processing method applied to a target end of container migration, and the method comprises the following steps:

[0006] Obtaining file metadata and mounting metadata of an original temporary file system (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;

[0007] When the mounting point is created in a target container, according to the mounting metadata, an original device number corresponding to the created mounting point is explicitly allocated;

[0008] When the file is created in the mounting point, according to the file metadata, an original inode number corresponding to the created file is explicitly allocated.

[0009] In a second aspect, the present application provides a file system processing method applied to a source end of container migration, and the method comprises the following steps:

[0010] read file metadata and mounting metadata of the original tmpfs in the source container, the mounting metadata including original device number of a mounting point, mounting point path and mounting source, and the file metadata including original inode number of a file;

[0011] write the file metadata and the mounting metadata of the original tmpfs into a configuration file;

[0012] send 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.

[0013] In a third aspect, the present application provides a file system processing method applied to a container management end, and the method comprises:

[0014] receive a configuration file sent by a source end;

[0015] parse the configuration file to obtain file metadata and mounting metadata of an original tmpfs, the mounting metadata including original device number of a mounting point, mounting point path and mounting source, and the file metadata including original inode number of a file;

[0016] transmit the file metadata and the mounting metadata of the original tmpfs to a target end.

[0017] In a fourth aspect, the present application provides a file system processing system, comprising 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;

[0018] 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 includes original device number of a mounting point, mounting point path and mounting source, and the file metadata includes original inode number of a file;

[0019] the container management end is configured to send the file metadata and the mounting metadata of the original tmpfs to the target end;

[0020] the target end is configured to:

[0021] when the mounting point is created in a target container, explicitly assign a corresponding original device number to the created mounting point according to the mounting metadata;

[0022] when the file is created in the mounting point, explicitly assign a corresponding original inode number to the created file according to the file metadata.

[0023] In a fifth aspect, the present application provides a server, comprising: at least one processor; and a memory connected with 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 enable the server to perform the method provided in any one of the preceding aspects.

[0024] In a sixth aspect, the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and when a processor executes the computer execution instructions, the method provided in any one of the preceding aspects is implemented.

[0025] In a seventh aspect, the present application provides a computer program product, comprising a computer program, and when the computer program is executed by a processor, the method provided in any one of the preceding aspects is implemented.

[0026] The file system processing method, system, server, storage medium and program product provided by the present application. The method, when the container is migrated, in the container saving stage, the source container reads the original device number of the original tmpfs mounting point and the original index node number of the file, and transmits the original device number of the original tmpfs mounting point and the original index node number of the file to the target end through the container management end. In the container recovery stage, when the target end creates a mounting point in the target container, according to the mounting metadata, the corresponding original device number is allocated to the created mounting point, which can ensure the consistency of the device number of the recovered target tmpfs and the original tmpfs. When creating a file in the mounting point, the corresponding original index node number is allocated to the created file, which can ensure the consistency of the file index node number of the recovered target tmpfs and the original tmpfs. The scheme of the present application can ensure the consistency of the device number and the index node number of the tmpfs before and after migration, avoid the abnormality / failure caused by the inconsistency of the device number and the index node number of the tmpfs before and after migration, and improve the safety and stability of the system. BRIEF DESCRIPTION OF DRAWINGS

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

[0028] Figure 1 The architecture diagram of the file system processing system provided by an exemplary embodiment of the present application is shown in the following figure:

[0029] Figure 2 The framework schematic diagram of the tmpfs device number consistency guarantee mechanism provided by an exemplary embodiment of the present application is shown in the following figure:

[0030] Figure 3A framework diagram of the tmpfs file inode number consistency guarantee mechanism provided by the embodiment of the present application;

[0031] Figure 4 A flowchart of the file system processing method provided by the example embodiment of the present application;

[0032] Figure 5 A principle diagram of the tmpfs device number consistency guarantee mechanism provided by the embodiment of the present application;

[0033] Figure 6 A diagram of the tmpfs device number namespace mechanism provided by the embodiment of the present application;

[0034] Figure 7 A principle diagram of the tmpfs file inode number consistency guarantee mechanism provided by the embodiment of the present application;

[0035] Figure 8 An example diagram of the tmpfs file inode number consistency guarantee mechanism provided by the embodiment of the present application;

[0036] Figure 9 A flowchart of the file system processing method provided by another example embodiment of the present application;

[0037] Figure 10 A flowchart of the file system processing method provided by another example embodiment of the present application;

[0038] Figure 11 A flowchart of the file system processing method provided by another example embodiment of the present application;

[0039] Figure 12 A structure diagram of a server provided by the embodiment of the present application.

[0040] The specific embodiments of the present application have been shown through the above-described diagrams, and will be described in more detail hereinafter. These diagrams and written descriptions are not intended to limit the scope of the concept of the present application by any means, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0041] The example embodiments will be described in detail herein, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following example embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.

[0042] It should be noted that the user information (including but not limited to user equipment information, user attribute information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards, and provide corresponding operation portal for user to choose authorization or refusal.

[0043] First, the terms involved in the present application are explained:

[0044] RunC container: a container that implements runtime isolation, characterized by sharing the kernel between the container and the host machine.

[0045] RunD container: introduces a virtualization layer to isolate the container kernel from the host kernel (i.e., the kernel of the host operating system) based on a normal container. The feature is to achieve performance isolation, security isolation and fault isolation.

[0046] Container migration: migrating a running container instance from one host to another while maintaining the consistency of its state, memory, file system, etc.

[0047] Temporary File System (tmpfs): also known as tmpfs file system, is a temporary file system based on memory, used to provide high-speed, volatile storage space at runtime, commonly used in scenarios that require temporary files or caching.

[0048] Device number: the identification of the device to which the file belongs.

[0049] Index node number: the unique identification of a file or directory in the file system.

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

[0051] Mount point: refers to the location of the tmpfs file system in the container directory tree, i.e., the mounting directory of the tmpfs file system.

[0052] In the task scenario of AI training / inference, the support capability of the underlying mechanism is the key to realizing system elasticity. In order to improve resource utilization and reduce GPU (Graphics Processing Unit, GPU) idle time, the system needs to have the ability of automatic expansion, rapid startup and warm / hot migration, etc., so as to provide efficient Serverless (serverless architecture) elasticity.

[0053] What AI training scenarios need is the save and restore and migration capability, which is the save and restore of the task state. AI inference scenarios need flexibility, and need to have the ability to quickly start services (i.e., recover from images). However, whether it is training or inference scenarios, the consistency of the task state before and after saving and restoring and migration is the core guarantee for stable system operation and user experience. Especially in the AI training process, users often use tmpfs file system to cache intermediate data to speed up execution efficiency.

[0054] With the wide application of stateful containers in container orchestration platforms (such as Kubernetes), the support for container saving and restoring has been gradually enhanced by integrating container migration tools.

[0055] Due to the temporary and memory-resident nature of tmpfs, when performing container migration, the tmpfs on the source end needs to be packaged and stored during the save phase, and the corresponding path needs to be restored by unpacking on the target end during the restore phase, and then tmpfs needs to be remounted. However, this method cannot guarantee the consistency of the tmpfs device number and inode number before and after saving and restoring.

[0056] Many applications (such as AI training tasks, database caches, file search tools, etc.) rely on these two pieces of metadata for file verification and access control. There are often user processes in containers that rely on the consistency of file system node information, and if these two pieces of metadata fail the verification, it will cause an exception. The inconsistency of the tmpfs device number and inode number may cause some basic tools (such as the find command, some library functions) to fail when verifying files, thus triggering unpredictable abnormal behavior, which is an important risk point 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] The application provides a file system processing method. In a saving stage during container migration, the source end reads the original device number of the mounting point of the original tmpfs and the original inode number of the file in the source container when packing and storing the original tmpfs, and transmits the original device number of the mounting point of the original tmpfs and the original inode number of the file to the target end through the container management end. In a recovery stage, the target end creates a mounting point in the target container, and according to the mounting metadata, explicitly allocates the corresponding original device number to the created mounting point, so as to ensure the consistency of the device number of the recovered target tmpfs and the original tmpfs. When creating a file in the mounting point, according to the file metadata, the corresponding original inode number is explicitly allocated to the created file, so as to ensure the consistency of the file inode number of the recovered target tmpfs and the original tmpfs. The scheme of the application can ensure the consistency of the device number and the inode number of the tmpfs before and after migration during container migration, avoid abnormality / failure caused by the inconsistency of the device number and the inode number of the tmpfs before and after migration, and improve the safety and stability of the system.

[0059] The technical scheme of the application and how the technical scheme solves the above technical problems will be described in detail below with specific examples. The following specific examples can be combined with each other, and the same or similar concepts or processes can not be described again in some examples. The embodiments of the application will be described below with reference to the drawings.

[0060] Figure 1 An architecture diagram of a file system processing system provided for an exemplary embodiment of the application is shown. The system architecture can realize the saving and recovery of the tmpfs file system during container migration.

[0061] As shown in Figure 1 , the system architecture includes a source end, a target end and a container management end of container migration.

[0062] The source end refers to a device where a source container to be migrated is located. The source end 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 (Guest OS), such as a RunD container, or a container sharing an operating system kernel with a host machine, such as a RunC container.

[0063] The target end refers to a device where a target container to be migrated is located. The target container can be a container with an independent guest operating system (Guest OS), such as a RunD container, or a container sharing an operating system kernel with a host machine, such as a RunC container.

[0064] For a RunD container, it runs on a guest OS of a source / destination end, and has an independent kernel space. For a RunC container, it runs on a host OS of a source / destination end, and shares a kernel space with the host. Figure 1 The architecture of the processing system of the tmpfs file system in the container migration scenario is exemplarily described by taking the source container and the target container as RunD containers with independent guest OSs.

[0065] The source end and the target end run a container runtime, which provides a running environment for the running containers.

[0066] The container management end, that is, the container management platform, is a set of integrated tools and systems for automatically deploying, managing, extending, and operating containerized application programs. The container management platform runs in the user mode.

[0067] In addition, in order to implement container migration, the source end and the target end can run a container migration tool, which runs in the user mode. By taking the source container and the target container as RunD containers with independent guest OSs, the container migration tool of the source end and the target end, the kernel of the guest OS of the source container and the target container, and the container management end cooperate to complete the container migration task. The container migration tool is a kind of software specially used for quickly and reliably migrating an application program and its running environment (including code, runtime, system tool, system library, and setting) from one computing environment to another computing environment. For example, from a physical machine to a virtual machine, from a virtual machine to a physical machine, from a virtual machine to another virtual machine, from a physical machine to another physical machine, from a local data center to a cloud platform, from one cloud platform to another cloud platform, from an old version of a cluster or a service to a new version within the same cloud platform, and the like.

[0068] For the tmpfs in the source container, since the tmpfs is a memory file system dynamically managed by the kernel, its device number is allocated by the kernel when mounting, and the inode number is allocated by the kernel when creating a file. The user-mode container migration tool cannot intervene in the allocation of the device number and the inode number of the tmpfs. Therefore, in this embodiment, a consistency guarantee mechanism of the tmpfs metadata (including the device number and the inode number) is introduced from the kernel level. Through the joint cooperation of the kernel, the user-mode container migration tool, and the container management platform, the integrity and consistency of the tmpfs file system in the saving, restoring, and migrating processes are realized.

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

[0070] Exemplarily, Figure 2 A schematic diagram of the framework of the tmpfs device number consistency guarantee mechanism provided by the present embodiment is shown in FIG. 1. As shown in the figure, the overall flow of the tmpfs device number consistency guarantee mechanism is as follows: Figure 2

[0071] Step 1: Report the original device number of the original tmpfs in the source container. In the container saving stage, the container migration tool of the source end reads and reports the original device number of the mount point in the original tmpfs in the source container. When reading the original device number in the original tmpfs, the container runtime is read. The original device number of the mount point in the original tmpfs is saved in the 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 control end records the original device number of the mount point in the original tmpfs. Specifically, the container control end parses the configuration file to extract the original device number in the original tmpfs.

[0073] Step 3: Deliver the original device number of the original tmpfs. When starting the guest operating system, the container control end delivers the original device number of the mount point in the original tmpfs to the target end by setting the kernel start parameter. The set kernel start parameter contains the original device number.

[0074] Step 4: Set the kernel start parameter to reserve the original device number of the original tmpfs. The kernel of the target end creates a reserved device number pool according to the kernel start parameter to reserve the original device number of the original tmpfs.

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

[0076] The core of the tmpfs device number consistency guarantee mechanism lies in two key links: 1. The kernel needs to support the tmpfs device number reservation and specified allocation mechanism; 2. The user state container migration tool needs to support the saving and recovery strategy of the tmpfs device number. These two core functions complement each other, the former guarantees the controllable and predictable allocation mechanism of the device number from the bottom, and the latter is responsible for collecting and restoring the device number in the user state, which together builds a complete tmpfs device number consistency guarantee system.

[0077] Among them, the effectiveness of the kernel supporting the reservation and specified allocation mechanism of the original device number depends on the user state accurately delivering the required reserved original device number to the kernel. This requires the container migration tool to capture and record the original device number of the original tmpfs mounted in the source container in the container saving stage, and to mount by explicitly specifying the original device number in the container recovery stage.​

[0078] Specifically, in the container saving stage, the container migration tool traverses the mount points in the source container, filters out the mount points with the file system type of tmpfs, and writes the corresponding original device number into the configuration file. For example, in the operation of obtaining the original device number, the mounting information interface provided by the system kernel (such as the Linux kernel) can be combined to obtain accurate mounting metadata (such as the original device number, the mount point path, the mount source, etc.). In the container recovery stage, when the target client operating system (such as the client operating system Guest OS) is started, the container management end sets the kernel start parameter through the command line (cmdline) and delivers the original device number to be reserved to the kernel of the target client operating system. When the container is recovered, the container migration tool of the target end adds the tmpfs mounting option of explicitly specifying the device number and issues the tmpfs mounting request of explicitly specifying the device number. The kernel explicitly specifies the original device number of the mount point when performing the mounting operation.

[0079] In combination with the above kernel and user state strategy, the consistency of the tmpfs device number before and after saving and recovery can be ensured.

[0080] For example, Figure 3 The framework schematic diagram of the tmpfs file index node number consistency guarantee mechanism provided by the embodiments of the present application is shown in FIG. 1. Figure 3 As shown in FIG. 1, the overall process of the tmpfs file index node number consistency guarantee mechanism is as follows:

[0081] Step 1: Pack the mount point and save the original index node number corresponding to the file in the mount point.

[0082] In the container saving stage, the container migration tool of the source end can save the original index node number corresponding to each file in the original tmpfs. When reading the original index node number of the file in the original tmpfs, the container runtime is read. The original index node number of the file in the original tmpfs is saved in the configuration file and sent to the container control end.

[0083] For example, the container migration tool can record the mapping relationship between the file name and the original index node number of each file in the original tmpfs, save the mapping relationship between the file name and the original index node number of the file in the original tmpfs in the configuration file, and send it to the container control end. For example, according to the mapping relationship between the file name and the original index node number of the file in the original tmpfs, a mapping relationship mirror file is constructed to record the mapping relationship between the file name and the original index node number of the file in the original tmpfs. The mapping relationship between the file name and the original index node number of the file in the original tmpfs will be used as the key reference data in the container recovery process.

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

[0085] Third step: create a file and specify the original inode number.

[0086] In the container recovery phase, the data of the tmpfs mount point is decompressed and restored to recover the mount point. When creating a file in the mount point, according to the mapping relationship between the file name and the original inode number of the file in the original tmpfs, the kernel interface is called to explicitly specify the original inode number of the created file, thereby realizing the consistency of the file inode number of the tmpfs before and after saving and restoring.

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

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

[0089] 2. The user state container migration tool supports tmpfs inode number mapping management to complete the collection and restoration of the original inode number of the tmpfs.

[0090] These two core functions complement each other and together build a complete tmpfs file inode number consistency guarantee system.

[0091] To guarantee the consistency of the file inode number in the tmpfs file system before and after the container is saved and restored, the kernel needs to provide a tmpfs file creation mechanism that supports explicit specification of the inode number, and the user state container migration tool needs to complete the collection and restoration of the original inode number of the tmpfs file. This mechanism relies on the cooperation of the kernel and the user state to form a complete control loop and ensure the consistency of the file metadata from the perspective of the container.

[0092] The timing of the tmpfs file inode number consistency guarantee mechanism is when the system call interface is called to create a file, so it is suitable for all types of containers (such as RunD containers and RunC containers). Through this kernel + user state joint control architecture, the problem of inconsistent inode numbers caused by uncontrollable inode number allocation in the traditional user state container migration tool tmpfs recovery process can be effectively solved.

[0093] It should be noted that in some example scenarios, only the tmpfs device number consistency guarantee mechanism can be introduced to ensure the consistency of the tmpfs device number before and after the container migration. In this scenario, the source can not save the original inode number of the file in the tmpfs during the container saving phase. In the container recovery phase, the relevant processing steps for ensuring the consistency of the tmpfs device number are performed.

[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 key role in the container save and restore process. It is responsible for collecting the original device number and / or original inode number of the tmpfs mount point of the container runtime during the container save stage, and explicitly specifying the original device number when mounting the tmpfs and explicitly specifying the original inode number of the file when creating the file during the container restore stage.

[0102] During the container save stage, the container migration tool at the source end can traverse the original tmpfs mount point 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 by the source end 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] In addition, the mount metadata can also include the mount options of the mount point, which are used to set the permission file, owner, and group of the mount point root directory, etc. The file metadata can also include the unique identifier, name, type, size, permission, timestamp, and extended attributes (such as optional, key-value pair form attribute information, used to store security labels, capability sets, or other application custom information) of the file.

[0105] In this embodiment, during the container save stage, the source end reads the file content and metadata (including file metadata and mount metadata) of the original tmpfs. Based on the existing scheme, the device number of the mount point and the inode number of the file are added. As to which data needs to be obtained in addition to the device number and inode number, it can be set according to the actual application requirements and the selected container migration algorithm, which is not specifically limited here.

[0106] Step S402, the container management and control end transmits the file metadata and mount metadata of the original tmpfs to the target end.

[0107] In this step, the container management and control end receives the file content and metadata of the original tmpfs sent by the source end. The metadata of the original tmpfs includes file metadata and mount metadata. The container management and control end transmits the file content and metadata of the original tmpfs to the target end.

[0108] In an optional embodiment, for the metadata of the original tmpfs, the source end can write the file metadata and mount metadata of the original tmpfs into a configuration file. The configuration file is sent to the container management and control end.

[0109] The container management and control end receives the configuration file sent by the source end, parses the configuration file to obtain the file metadata and mount metadata of the original tmpfs, and sends the file metadata and mount metadata of the original tmpfs to the target end.

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

[0111] In step S403, when the target creates a mounting point in the target container, the target assigns the corresponding original device number to the created mounting point according to the mounting metadata.

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

[0113] The main technical forms of the current container mainly include RunC containers and RunD containers. The RunC container realizes runtime isolation based on the control group (Cgroup) and namespace (Namespace) technology of the Linux kernel, and its characteristic is to share the same kernel with the host machine. The RunD container introduces a virtualization layer on the basis of the RunC container, encapsulates the container through a lightweight virtual machine, thereby realizing the isolation between the container kernel and the host kernel. This way not only retains good performance, but also further improves the security, stability, and fault isolation capability of the system.

[0114] The RunD container and the RunC container differ in isolation mechanism, performance, and security characteristics. Compared with the RunD container based on the virtualization layer, the RunC container does not have an independent kernel space, but shares the same kernel with the host machine.

[0115] In an example scenario, for a target container corresponding to an independent guest operating system, the tmpfs device number consistency guarantee mechanism adopted includes a tmpfs device number reservation mechanism and a device number specified allocation mechanism.

[0116] In a system kernel (such as a Linux kernel), the device number allocation mechanism of tmpfs relies on an identifier allocator (IDA) which is used to dynamically manage globally unique identifier resources. To ensure that the specified device number is exclusively used by the tmpfs that is explicitly mounted, the device number reservation operation must be completed before the initialization of the tmpfs file system. Considering that there may be other modules or kernel components occupying the tmpfs device number during the system initialization process, the device number reservation operation needs to be implemented through a kernel startup parameter.

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

[0118] Illustratively, the container management end sends a kernel command line to the target end according to the mounting metadata. The kernel command line is used to set the kernel startup parameter of the client operating system. The kernel startup parameter includes the original device number.

[0119] The target end receives the kernel command line sent by the container management end and determines the kernel startup parameter (including the original device number to be reserved) set by the kernel command line. The target end starts the client operating system, and the kernel of the client operating system creates a reserved device number pool according to the original device number to be reserved in the kernel startup parameter, and adds the original device number to the reserved device number pool and sets the state of the original device number in the reserved device number pool as reserved and unused.

[0120] In addition, in order to avoid the reserved original device number being occupied by other tmpfs, after adding the original device number to the reserved device number pool, the state of these original device numbers in the global device number pool is set as used.

[0121] In the traditional tmpfs architecture, only one global device number pool is maintained to manage all device numbers. The state of the device number is divided into two types: unused (or idle) and used. In this embodiment, a reserved device number pool is added, and the device numbers in the reserved device number pool have the following two states: reserved and unused, and reserved and used. Among them, "reserved and unused" means that it has been reserved to the reserved device number pool, but has not been mounted for use. "Reserved and used" means that it has been reserved to the reserved device number pool and has been used by the explicitly mounted tmpfs. In this embodiment, the original global device number pool is still maintained, and the device numbers in the global device number pool still have two states: unused (or idle) and used. Among them, "used" means that it has been mounted for use or has been reserved to the reserved device number pool. "Unused (or idle)" means that it has not been mounted for use and has not been reserved to the reserved device number pool.

[0122] In the system initialization stage of the target end, the container management end passes the set of original device numbers to be reserved through the kernel start parameter in the user mode in this embodiment. The kernel of the client operating system of the target end then applies the original device numbers to be reserved from the global device number pool and adds these original device numbers to the reserved device number pool for management. In the global device number pool, the states of these reserved original device numbers are set as used to prevent the tmpfs mounting request of the non-explicitly specified device number from misusing these reserved device numbers.

[0123] For the tmpfs mounting request of the explicitly specified device number, the kernel of the client operating system of the target container performs the following atomic operation:

[0124] According to the mounting point path and the mounting source of the first mounting point, the first mounting point is created in the target container; according to the original device number of the first mounting point, the corresponding original device number is allocated to the created first mounting point in the reserved device number pool, and the state of the original device number of the first mounting point in the reserved device number pool is updated as reserved and used.

[0125] Exemplarily, when the corresponding original device number is allocated to the created first mounting point in the reserved device number pool, the state of the original device number of the first mounting point is queried in the reserved device number pool. If the state of the original device number of the first mounting point is reserved and unused, the original device number of the first mounting point is allocated to the created first mounting point, and the state of the original device number of the first mounting point is updated as reserved and used.

[0126] If the original device number of the first mounting point does not exist in the reserved device number pool, it means that the original device number of the first mounting point is not reserved, so the mounting fails, and a first mounting failure prompt information is returned. The first mounting failure prompt information is used to prompt the mounting failure, and the failure reason is that the original device number of the first mounting point is not reserved.

[0127] If the original device number of the first mounting point exists in the reserved device number pool, and the state of the original device number of the first mounting point is reserved and used, it means that although the original device number of the first mounting point is reserved, the original device number is occupied, so the mounting fails, and a second mounting failure prompt information is returned. The second mounting failure prompt information is used to prompt the mounting failure, and the failure reason is that although the corresponding original device number is reserved, it is occupied by other mounting points.

[0128] In this embodiment, in order to guarantee the consistency of the device number allocation and the mounting operation, the operations of specifying the device number and mounting the tmpfs are designed as atomic operations in the concurrent environment. Otherwise, the problem of inconsistency between the expected device number and the actual allocation result may occur. Therefore, the tmpfs mounting option supporting the explicit device number specification is introduced to ensure that the tmpfs mounting request of the explicitly specified device number can safely and orderly obtain the device number from the reserved device number pool.

[0129] When receiving the tmpfs mounting request without specifying the device number, the kernel only allocates the free device number from the global device number pool without accessing the reserved device number pool.

[0130] Exemplarily, for any second mounting point on the target end which does not need to reserve the original device number (such as the mounting point of the tmpfs other than the target tmpfs), the tmpfs mounting request without specifying the device number is initiated by the container runtime. The tmpfs mounting request without specifying the device number contains the mounting point path and the mounting source of the second mounting point, and does not contain the device number specified for the second mounting point. For example, the container migration tool of the target end initiates the tmpfs mounting request without specifying the device number to the guest operating system kernel of the target container by calling the tmpfs mounting interface without specifying the device number.

[0131] For the tmpfs mounting request without specifying the device number, the guest operating system kernel of the target container performs the following atomic operations:

[0132] According to the mounting point path and the mounting source of the second mounting point, the second mounting point is created in the target container; the device number in the state of not being used is allocated to the created second mounting point from the global device number pool, and the state of the allocated device number is updated to being used.

[0133] In this embodiment, for the corresponding independent guest operating system target container, the tmpfs device number consistency guarantee mechanism based on device number reservation is introduced. The core of the mechanism is that in the system initialization stage, the device numbers of the original tmpfs that need to be reserved are divided into the reserved device number pool from the global device number pool, and the reserved device numbers are marked in the state in the global device number pool to distinguish the ordinary device numbers from the reserved device numbers.

[0134] Exemplarily, Figure 5 The schematic diagram of the tmpfs device number consistency guarantee mechanism provided in this embodiment is shown. As shown in Figure 5 The device numbers in the reserved device number pool have the following two states: "reserved and not used" and "reserved and used". Among them, "reserved and not used" means that it has been reserved to the reserved device number pool, but has not been mounted and used. "Reserved and used" means that it has been reserved to the reserved device number pool and has been used by the explicitly mounted tmpfs. The device numbers in the global device number pool still have two states: "not used" and "used". Among them, "used" means that it has been mounted and used or has been reserved to the reserved device number pool. "Not used" means that it has not been mounted and used and has not been reserved to the reserved device number pool.

[0135] As shown in Figure 5As shown, in the container recovery phase, when performing the tmpfs mounting operation, for the tmpfs mounting request without specifying the device number, the kernel allocates the free device number from the global device number pool, and cannot access the reserved device number pool. For the tmpfs mounting request with explicitly specified device number, the kernel allocates the explicitly specified device number from the reserved device number pool (state is reserved unused). Only in the case of explicitly specifying the target device number when mounting, the kernel will try to allocate from the reserved device number pool. This mechanism has the characteristics of simple implementation and clear control. By introducing the reserved device number pool and device number state classification, the fine-grained control of the tmpfs device number resource is effectively realized, which can effectively ensure the consistency of the device number before and after the tmpfs file system in the container saving and recovery process.

[0136] In an example scenario, for the architecture that multiple containers share the same host kernel, the tmpfs device number reservation mechanism faces the following risks: multiple containers share the same host kernel, so that multiple containers share one reserved device number pool, and different containers may be allocated the same reserved device number when mounting tmpfs, thereby causing the device number identifier to be not unique, and destroying the consistency of the file system semantics.

[0137] In an optional embodiment, for the target container (such as a RunC container) sharing the operating system kernel with the host, the tmpfs device number consistency guarantee mechanism includes a tmpfs device number namespace mechanism and a device number specified allocation mechanism. By introducing the tmpfs device number namespace mechanism, this mechanism isolates the device number allocation logic inside different containers by creating independent tmpfs device number namespaces for each container, ensuring that each container does not affect each other. Within the respective tmpfs device number namespace, device numbers can be freely allocated, recycled, and managed without worrying about conflicts with other containers. The mapping relationship between the device numbers in the tmpfs device number namespace and the real device numbers existing in the host kernel is maintained by the host kernel.

[0138] On the basis of the foregoing embodiment, in this embodiment, the container runtime of the target container creates an independent tmpfs device number namespace for the target container, and calls a system call (so that the kernel) to establish the mapping relationship between the tmpfs device number namespace and the real device number.

[0139] Exemplarily, Figure 6 A schematic diagram of the tmpfs device number namespace mechanism provided in this embodiment is shown. As Figure 6 shown, different containers A and B have independent tmpfs device number namespaces. Different containers can freely allocate, recycle, and manage device numbers within their respective tmpfs device number namespaces without worrying about conflicts with other containers. For example, asFigure 6 As shown in the figure, there are the following device numbers in the tmpfs device number namespace of container A and container B: 1, 2, 3, 4. The host kernel maintains the mapping relationship between the device numbers in each tmpfs device number namespace and the real device numbers (device numbers 1-12 shown in the figure) in the global device number pool. The device numbers in the figure are only examples and are not necessarily the device numbers in actual applications.

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

[0141] According to the mount point path and mount source of the first mount point, the first mount point is created in the target container, and the corresponding original device number is allocated 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.

[0142] In step S404, when the target end creates a file in the mount point, the corresponding original inode number is explicitly allocated to the created file according to the file metadata.

[0143] In actual applications, the tmpfs implementation of the system kernel (such as the Linux kernel) has already ensured that the file inode number is consistent with the file creation order. However, the “packaging-decompression” implementation adopted by the user-mode container migration tool saves and restores the tmpfs in such a way that the order of creating files in the decompression restoration process is often different from the original actual creation order of the files, which leads to inconsistency between the inode number after restoration and the original inode number of the file before saving.

[0144] The inode number, as the unique metadata for identifying files in the file system, is controlled by the kernel, and user-mode programs (such as container migration tools) cannot directly intervene. In addition, modifying the inode number of an already created file is a high-risk operation that may cause file system structure abnormalities or data corruption, and therefore is not feasible.

[0145] To solve the above problems, this embodiment introduces a tmpfs file inode number consistency guarantee mechanism, and introduces a tmpfs file creation interface that supports explicit specification of inode numbers in the kernel to achieve strong consistency between 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 need to ensure metadata consistency, which is used to store the original inode numbers of files in the mount point.

[0147] Optionally, after assigning the created mount point with the corresponding original device number according to the mount metadata, the kernel creates an explicit inode number pool for the mount point; adds the original inode number of the file in the mount point to the explicit inode number pool of the mount point, and sets the state of the original inode number as unused.

[0148] For any third mount point (such as any mount point in the target tmpfs in this migration) that needs to keep the file metadata consistent, when creating a target file in the third mount point, the container migration tool of the target end initiates a tmpfs file creation request with an explicitly specified inode number through the container runtime of the target container. The tmpfs file creation request contains the specified original inode number. For example, the container migration tool initiates the tmpfs file creation request with an explicitly specified inode number by calling a tmpfs file creation interface with an explicitly specified inode number and specifying the original inode number as an input parameter.

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

[0150] Creating a target file in the third mount point; according to the original inode number corresponding to the target file in the file metadata, assigning the created target file with the original inode number corresponding to the target file in the explicit inode number pool.

[0151] Exemplarily, according to the file metadata, assigning the created target file with the original inode number corresponding to the target file in the explicit inode number pool can be implemented in the following way:

[0152] According to the original inode number corresponding to the target file in the file metadata, querying the state of the original inode number corresponding to the target file in the explicit inode number pool. If the state of the original inode number corresponding to the target file is unused, assigning the original inode number corresponding to the target file to the target file, and updating the state of the assigned original inode number to used.

[0153] If the original inode number corresponding to the target file does not exist in the explicit inode number pool, or the state of the original inode number corresponding to the target file in the explicit inode number pool is used, the mounting fails, and a third mount failure prompt information is returned. The third mount failure prompt information is used to prompt the mounting failure and prompt that the mounting failure reason is the failure of the explicit inode number assignment.

[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] In the container saving stage, the container migration tool of the source end saves the mapping relationship between the file name and the inode number of each file in the original tmpfs into the mount point image when saving the mount point image. The mount point image saves the file content and the file metadata of the mount point. The file metadata includes the mapping relationship between the file name and the inode number. As shown in FIG. 8, taking the mount point of “ / tmp / targetdlr” as an example, there are three files under the mount point: a.txt, b.txt and c.txt, and the inode numbers of the three files are 127, 256 and 511 respectively. Figure 8

[0162] Step 2: Recover the files.

[0163] In the container recovery stage, the container migration tool of the target end recovers the files in the mount point by decompressing the mount point image.

[0164] Step 3: Call the tmpfs file creation interface with explicit specification of inode number.

[0165] The container migration tool of the target end initiates the request for creating the tmpfs file with explicit specification of inode number by calling the tmpfs file creation interface with explicit specification of inode number and specifying the original inode number as an input parameter. The kernel creates the corresponding file and allocates the original inode number of the file to the file.

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

[0167] In this embodiment, the container migration tool has the following capabilities: in the container saving stage, collecting and persisting the mapping relationship between the file name and the inode number of the file in the tmpfs; in the container recovery stage, reconstructing the file structure according to the specified inode number by calling the interface provided by the kernel. The container migration tool adopts the “packing-decompressing” mechanism when saving and recovering the tmpfs file system. The decompressing process is actually the process of creating a file, and in this process, the container migration tool directly calls the tmpfs file creation interface with explicit specification of inode number provided by the kernel, so as to ensure that the inode number of the file is consistent with the original inode number before saving.

[0168] ​The scheme of the embodiment implements the tmpfs device number reservation and designated allocation mechanism, the tmpfs device number namespace mechanism and the device number designated allocation mechanism, and the tmpfs index node number designated allocation mechanism in the kernel. For the target container corresponding to an independent guest operating system, the tmpfs device number reservation and designated allocation mechanism is introduced, the device numbers to be reserved are divided into a reserved device number pool through a kernel start parameter, and the tmpfs mounting interface of explicitly specifying the device number is extended to support the tmpfs mounting request of explicitly specifying the device number.

[0169] For the target container sharing the operating system kernel of the host machine, the tmpfs device number namespace mechanism and the device number designated allocation mechanism are introduced, the kernel namespace mechanism is extended, and a tmpfs device number namespace is created for each container, so that the containers do not interfere with each other, and the device number conflict problem caused by the shared reserved device number pool in the scenario of multiple containers sharing the same host kernel (such as the RunC container) is effectively avoided.

[0170] The tmpfs index node number designated allocation mechanism implements a tmpfs file creation interface supporting explicit specification of the index node number, so as to realize the strong consistency between file creation and the expected index node number (i.e. the original index node number).

[0171] In combination with the above mechanisms, the scheme of saving and restoring the tmpfs metadata is realized by the coordination of the kernel, the container management platform and the user state container migration tool. In the container saving stage, the container migration tool saves the device number and file index node number of the tmpfs mounting point in addition to the conventional data of the tmpfs file system. In the container recovery stage, the container migration tool mounts the tmpfs by explicitly specifying the original device number, and explicitly specifies the original index node number of the file through the kernel interface when reconstructing the file content, so as to ensure that the metadata of the recovered tmpfs containing the device number and the file index node number are consistent with the original state.

[0172] Figure 9 The flowchart of the file system processing method provided by another exemplary embodiment of the present application is shown. The execution subject of the embodiment is the target device of container migration. As shown in Figure 9 the processing flow of the target device in the container migration process is as follows:

[0173] Step S901, the file metadata and mounting metadata of the original temporary file system tmpfs in the source container are obtained, the mounting metadata includes the original device number of the mounting point, the mounting point path and the mounting source, and the file metadata includes the original index node number of the file.

[0174] Step S902, when a mount point is created in the target container, according to the mount metadata, the created mount point is explicitly assigned with a corresponding original device number.

[0175] Step S903, when a file is created in the mount point, according to the file metadata, the created file is explicitly assigned with a corresponding original inode number.

[0176] In this embodiment, the implementation principle and technical effects of the source device in the container migration process are the same as those of the foregoing embodiments, which will not be repeated here.

[0177] Figure 10 A flowchart of a file system processing method provided by another exemplary embodiment of the present application is shown in FIG. 11. The execution subject of this embodiment is a container management platform. As shown in FIG. 11, the processing flow of the container management platform in the container migration process is as follows: Figure 10

[0178] Step S1001, read the file metadata and mount metadata of the original tmpfs in the source container, the mount metadata including the original device number of the mount point, the mount point path and the mount source, and the file metadata including the original inode number of the file.

[0179] Step S1002, write the file metadata and mount metadata of the original tmpfs into the configuration file.

[0180] Step S1003, send the configuration file to the container management platform, so that the container management platform sends the file metadata and mount metadata of the original tmpfs to the target.

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

[0182] Figure 11 A flowchart of a file system processing method provided by another exemplary embodiment of the present application is shown in FIG. 11. The execution subject of this embodiment is a container management platform. As shown in FIG. 11, the processing flow of the container management platform in the container migration process is as follows: Figure 11

[0183] Step S1101, receive the configuration file sent by the source.

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

[0185] Step S1103, transmit the file metadata and mount metadata of the original tmpfs to the target.

[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 a portion of the components and does not imply 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] The embodiment of the present application provides a chip, comprising: a processing module and a communication interface, the processing module can execute the technical solutions of the source end device, the target end device or the container management end in the foregoing method embodiments. Optionally, the chip further comprises a storage module (such as a memory), the storage module is used for storing instructions, the processing module is used for executing 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 by any of the foregoing method embodiments.

[0193] The integrated module in the form of the software function module can be stored in a computer readable storage medium. The software function module is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute part of steps of the method of each embodiment of the present application.

[0194] It should be understood that the processor can be a central processing unit (CPU), a graphics processing unit (GPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC) and the like. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the application can be directly embodied as hardware processor execution or combined execution by hardware and software modules in at least one processor.

[0195] The memory can include a high-speed random access memory (RAM), and can also include a nonvolatile storage, for example, at least one disk memory, and can also be a U disk, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk.

[0196] The memory can be object storage (OSS).

[0197] The aforementioned memory can be implemented by any type of volatile or nonvolatile memory devices 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 memory, flash memory, magnetic disk or optical disk.

[0198] The aforementioned communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located 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) mobile communication networks, or a combination thereof. In an example embodiment, the communication component receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, infrared technology, Ultra Wide Band (UWB) technology, Bluetooth technology, and other technologies.

[0199] The aforementioned power component provides power to various components of the device where the power component is located. The power component can include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device where the power component is located.

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

[0201] An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. Of course, the storage medium can be a part of the processor. Consistent with the teachings provided herein, the processor and the storage medium can be located in a single component or distributed across multiple components. The storage medium can be embodied in a computer-readable medium.

[0202] It is important to note that the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0203] The sequence of the above-mentioned embodiments of the present application is only for description, and does not represent the advantages and disadvantages of the embodiments. In addition, some of the processes described in the above embodiments and the accompanying drawings contain a plurality of operations appearing in a specific order, but it should be clearly understood that these operations can be executed in the order appearing in this text or in parallel, only to distinguish different operations. The sequence number itself does not represent any execution order. In addition, these processes can include more or fewer operations, and these operations can be executed in sequence or in parallel. It should be noted that the "first", "second", etc. in this text are used to distinguish different messages, devices, modules, etc., and do not represent the order. "First" and "second" are different types. The meaning of "multiple" is more than two, unless otherwise specifically limited.

[0204] Those skilled in the art can clearly understand the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, also can be through hardware, but in many cases the former is the better embodiment. Based on such understanding, the technical solutions of the present application essentially or say the part of the prior art to make contributions can be embodied in the form of software products, the computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc), including a number of instructions to make a terminal device (may be a mobile phone, computer, server, air conditioner, or network equipment, etc.) executes the method of each embodiment of the present application.

[0205] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the present application cover any and all variations of the application that come within the scope of the present application, along with all of the equivalents thereof. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0206] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, any equivalent structure or equivalent process transformation using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present 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 temporary file system 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 the target container, assigning the created mounting point a corresponding original device number according to the mounting metadata; when the file is created in the mounting point, assigning the created file a corresponding original inode number 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 the 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 assigning the created mounting point a corresponding original device number 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 a tmpfs mounting request of explicitly specified device number 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 the 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 the 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 the 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 tmpfs mounting request of unspecified device number through the container runtime to request the kernel to perform the following atomic operations: creating the second mounting point in the target container according to the mounting point path and the mounting source of the second mounting point; In the global device number pool, a device number in a state of unused is allocated to the created second mount point, and the state of the allocated device number is updated to used.

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

8. The method of claim 7, wherein, When the mount point is created in the target container, a corresponding original device number is explicitly allocated to the created mount point according to the mount metadata, which comprises: For any first mount point that needs to reserve an original device number, a tmpfs mount request of explicitly specifying a device number is initiated through the container runtime of the target container, so as to request the operating system kernel of the host machine to perform the following atomic operation: A first mount point is created in the target container according to the mount point path and the mount source of the first mount point; In the tmpfs device number namespace of the target container, a corresponding original device number is allocated to the created first mount point; The tmpfs mount request contains the original device number, the mount point path and the mount source of the first mount point.

9. The method according to any one of claims 1-8, characterized in that, After the original device number is explicitly allocated to the created mount point according to the mount metadata when the mount point is created in the target container, the method further comprises: An explicit index node number pool is created for the mount point; An original index node number of a file in the mount point is added to the explicit index node number pool of the mount point, and the state of the original index node number is set to unused.

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

11. The method of claim 10, wherein, The original index node number corresponding to the target file is queried in the explicit index node number pool according to the file metadata; If the state of the original index node number corresponding to the target file is unused, the original index node number corresponding to the target file is allocated to the target file, and the state of the allocated original index node number is updated to used. The method applied to a source end of container migration, the method comprising:

12. A file system processing method characterized by comprising: ​ read file metadata and mounting metadata of the original tmpfs in the source container, the mounting metadata including original device number of a mounting point, mounting point path and mounting source, and the file metadata including original inode number of a file; write the file metadata and the mounting metadata of the original tmpfs into a configuration file; send 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, the mounting metadata including original device number of a mounting point, mounting point path and mounting source, and the file metadata including 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, the kernel command line being used to set kernel start parameters of a guest operating system of a target container, and the kernel start parameters containing 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, the source end running a source container mounted with an original tmpfs; 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 includes original device number of a mounting point, and the file metadata includes 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, explicitly assign a corresponding original device number to the created mounting point according to the mounting metadata; when creating the file in the mounting point, explicitly assign a corresponding original inode number to the created file 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, the kernel command line being used to set kernel start parameters of a guest operating system, and the kernel start parameters containing 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 kernel start parameters set by the kernel command line, the kernel start parameters containing the original device number; start the guest operating system, create a reserved device number pool through a kernel of the guest operating system according to the kernel start parameters, add the original device number into the reserved device number pool, and set a state of the original device number in the reserved device number pool as reserved and unused.

18. A server, characterized by Comprise: at least one processor; and a memory in communication connection with the at least one processor; 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-executable instructions, and when the processor executes the computer-executable 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