CN116150116B

CN116150116B - File system sharing method and device, electronic equipment and storage medium

Info

Publication number: CN116150116B
Application number: CN202310407040.7A
Authority: CN
Inventors: 徐静波; 刘奖
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2023-04-12
Filing date: 2023-04-12
Publication date: 2023-07-04
Anticipated expiration: 2043-04-12
Also published as: CN116150116A

Abstract

The application provides a method and a device for sharing a file system, electronic equipment and a storage medium, wherein the method comprises the following steps: creating mounting information of a file system to be shared, wherein the file system to be shared is a file system already mounted on the first container; the mounting information and the file system to be shared have a mapping relation, and the mounting information is used for enabling the non-privileged container to mount the file system to be shared; mounting the file system to be shared in the determined second container by using the mounting information; the first container and the second container are non-privileged containers. According to the embodiment of the application, the file system in the container can be propagated and shared among a plurality of containers under the condition that the container does not have the privilege.

Description

File system sharing method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of cloud computing technologies, and in particular, to a method and apparatus for sharing a file system, an electronic device, and a storage medium.

Background

In recent years, due to the characteristic of convenient and rapid deployment of the cloud primary environment, related technologies of the cloud primary environment are gradually adopted by applications such as big data processing, AI (Artificial Intelligence ) model training and the like. Based on security considerations, containers in a cloud native environment typically do not have privileged rights, which presents challenges for the use of file systems in non-privileged containers, particularly for sharing among multiple containers.

Disclosure of Invention

The embodiment of the application provides a file system sharing method, a data access device, a data access system, electronic equipment and a storage medium, so that the file system existing in a container can be propagated and shared among a plurality of containers under the condition that the container does not have privilege rights.

In a first aspect, an embodiment of the present application provides a method for sharing a file system, where the method may include:

creating mounting information of a file system to be shared, wherein the file system to be shared is a file system already mounted on the first container; the mounting information and the file system to be shared have a mapping relation, and the mounting information is used for enabling the non-privileged container to mount the file system to be shared;

mounting the file system to be shared in the determined second container by using the mounting information; the first container and the second container are non-privileged containers.

In a second aspect, embodiments of the present application provide a method of data access, for use with a non-privileged container, the method may include:

accessing the mounted shared file system in response to the data processing task; the shared file system is mounted by using mounting information in advance;

and performing data processing operation corresponding to the data processing task from the shared file system.

In a third aspect, an embodiment of the present application provides an apparatus for file system sharing, where the apparatus may include:

the mounting information creating module is used for creating mounting information of a file system to be shared, wherein the file system to be shared is a file system mounted on the first container; the mounting information and the file system to be shared have a mapping relation, and the mounting information is used for enabling the non-privileged container to mount the file system to be shared;

the mounting module is used for mounting the file system to be shared in the determined second container by using the mounting information; the first container and the second container are non-privileged containers.

In a fourth aspect, embodiments of the present application provide an apparatus for data access, where the apparatus may include:

the access module is used for responding to the data processing task and accessing the mounted shared file system; the shared file system is mounted by using mounting information in advance;

and the data processing module is used for performing data processing operation corresponding to the data processing task from the shared file system.

In a fifth aspect, embodiments of the present application provide a system for data access, the system may include:

a device plugin for performing the method of file system sharing referred to in the first aspect;

a non-privileged container for performing the method of data access referred to in the second aspect.

In a sixth aspect, embodiments of the present application provide an electronic device comprising a memory, a processor and a computer program stored on the memory, the processor implementing the method of any one of the preceding claims when the computer program is executed.

In a seventh aspect, embodiments of the present application provide a computer-readable storage medium having a computer program stored therein, which when executed by a processor, implements the method of any one of the above.

Compared with the prior art, the application has the following advantages:

according to the embodiment of the application, the execution main body of the file system is adjusted to be the equipment plug-in. I.e. the overall process of file system sharing is dominated by the device plugin. Thus, even if the sharing object is a non-privileged container, the sharing of the file system can be performed through the mounting information created by the device plugin. Therefore, the file system to be shared existing in one container can be propagated and shared among a plurality of containers under the condition that the containers have no privilege.

The foregoing description is merely an overview of the technical solutions of the present application, and in order to make the technical means of the present application more clearly understood, it is possible to implement the present application according to the content of the present specification, and in order to make the above and other objects, features and advantages of the present application more clearly understood, the following detailed description of the present application will be given.

Drawings

In the drawings, the same reference numerals refer to the same or similar parts or elements throughout the several views unless otherwise specified. The figures are not necessarily drawn to scale. It is appreciated that these drawings depict only some embodiments according to the application and are not to be considered limiting of its scope.

FIG. 1 is a schematic diagram of a file system sharing method provided in the present application;

FIG. 2 is a flow chart of a method of file system sharing according to an embodiment of the present application;

FIG. 3 is a flow chart of a method of data access according to another embodiment of the present application;

FIG. 4 is a block diagram of an apparatus for file system sharing according to an embodiment of the present application;

FIG. 5 is a block diagram of an apparatus for data access according to another embodiment of the present application; and

fig. 6 is a block diagram of an electronic device used to implement an embodiment of the present application.

Detailed Description

Hereinafter, only certain exemplary embodiments are briefly described. As will be recognized by those of skill in the pertinent art, the described embodiments may be modified in various different ways without departing from the spirit or scope of the present application. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the following describes related technologies of the embodiments of the present application. The following related technologies may be optionally combined with the technical solutions of the embodiments of the present application, which all belong to the protection scope of the embodiments of the present application.

For application scenarios such as big data processing and AI model training, a large amount of data needs to be processed, and the storage of the large amount of data is followed. Compared with local storage, remote storage is gradually becoming storage of application scenes such as big data processing and AI model training due to the characteristics of low cost and elastic capacity. Illustratively, the remote store may generally include NFS (Network File System ) store, OSS store (Object Storage Service), and the like. Generally, OSS storage is favored over NFS storage for lower cost. Based on this, the remote object store may be linked with a FUSE (Filesystem in Userspace, user space file system) to implement big data processing or AI model training procedures. The FUSE file system is configured with a POSIX (Portable Operating System Interface, portable operating system) interface, which defines the interface standard that the operating system should provide for applications, and is a generic term for a series of Application Programming Interface (API) standards defined for software running on various kinds of UNIX operating systems. In implementing big data processing or AI model training, multiple containers (containers) are typically required to share a FUSE file system to achieve the effect of improving data processing efficiency.

For privileged containers, the mount point of the FUSE file system in one privileged container can be transferred to other privileged containers by way of mount point propagation (Mount Propagation) of Kubernets, thereby realizing the sharing of the FUSE file system among multiple containers. By privilege is meant a privilege authority that owns a UNIX system and a UNIX-like system (hereinafter, the UNIX system and the UNIX-like system are simply referred to as an operating system), and for example, the privilege authority can be understood to have all functions of the operating system and to release all restrictions. Many operations in an operating system, such as the mounting of a file system, require privileged rights. Correspondingly, the non-privileged container has the advantage of being safer than the rights container, and when one non-privileged container runs in the operating system, the root user identification (root UID) of the non-privileged container will be mapped to the non-root UID of the operating system, so that it is difficult for an attacker to obtain the root rights of the operating system by compromising the non-privileged container.

The mount point propagation described above must require that the containers have privileged rights, whereas in a cloud-native environment, only few containers possess privileged rights for security reasons, while most containers typically do not have privileged rights, i.e., none of these containers are non-privileged containers. Thus, the related art faces great difficulty in performing FUSE file system sharing among non-privileged containers.

Fig. 1 is a schematic diagram of an exemplary application scenario for implementing the method of the embodiments of the present application. Two containers (containers) belonging to the same group of containers (Pod) are exemplarily shown in fig. 1, in the example shown in fig. 1, container a and Container B, respectively. The container group is the smallest basic unit of Kubernetes deployment application or service. A container group may encapsulate multiple containers (or just one container), storage resources, a separate network IP, and policy options to manage the manner in which the containers are controlled. The operating system, when started, needs to initiate many system services that provide system function interfaces to local and network users, directly oriented to applications and users. Programs that provide these services are executed by daemons (daemons) that run in the background. In the embodiment of the application, when the operating system is started, the daemon can mount the FUSE file system to the container A to provide the service of the FUSE file system. That is, container A may be considered a carrier of the FUSE file system. The container B is a non-privileged container, and the functions of the container B can be regarded as a process for executing data reading and writing or data computing in an application scene, and the process of the non-privileged container B in the application scene needs to access the FUSE file system. Therefore, the technical scheme of the application can solve the problems.

An embodiment of the present application provides a method for sharing a file system, as shown in fig. 2, which is a flowchart of a method for sharing a file system in an embodiment of the present application, and corresponding to the first embodiment, the method may include:

step S201: creating mounting information of a file system to be shared, wherein the file system to be shared is a file system already mounted on the first container; the mounting information and the file system to be shared have a mapping relation, and the mounting information is used for enabling the non-privileged container to mount the file system to be shared.

The execution body corresponding to the first embodiment of the present application may be a Device plug in (Device-plug in). Kubernetes introduced a device plug-in mechanism from version 1.8, through which objects such as containers, groups of containers, etc. can be managed. The device plug-in is deployed on the nodes of Kubernetes and runs all the time as a separate daemon.

In case that it is detected that the file system needs to be shared, mount information of the file system to be shared may be created. The file system needs to be shared can be dynamically initiated by a user or can be predetermined. The file system to be shared may be a FUSE file system already mounted on the first container. So-called first container may correspond to container a in fig. 1, where container a may be a container for providing the FUSE file system, and when the system is started, the daemon may mount the FUSE file system to container a to provide the FUSE file system service. That is, container A may be considered a carrier of the FUSE file system. Wherein container a may be a non-privileged container.

The effect of the mount information of the file system to be shared is to have other non-privileged containers mount. The mounting information may be a handle, a hook function, or the like. The mounting information can make other containers aware to realize mounting, and needs to be associated with a file system to be shared to realize mapping matching of the two. Taking the mounting information as an example, the handle can be mapped with the file system to be shared by establishing the handle, so that the association of the handle with the file system to be shared is realized. In the case of a hook function, its usage is similar to a handle.

Step S202: mounting the file system to be shared in the determined second container by using the mounting information; the first container and the second container are non-privileged containers.

After the mount information of the file system to be shared is created, a mount (mount) operation can be performed in the second container according to the mount information. The second container may correspond to the container B in fig. 1, and the second container is a non-privileged container, and its functions may include a process of performing data reading and writing or data calculation in an application scenario such as large data processing, AI model training, or the like.

For performing the mount operation, it may refer to mounting the file system represented by the mount information to the mount directory of the container. For example, in one approach, the file system represented by the mount information may be directly mounted to the mount directory of the second container. For another example, in another manner, the file system represented by the mount information may be first mounted on the mount directory of the container group, and then the mount directory of the container group is shared for being transferred to the second container, so as to realize sharing the mount directory of the container group to the second container, and finally, the file system represented by the mount information is mounted on the mount directory of the second container. After the mounting is completed, the second container can realize the access to the file system which is completed to be shared.

Through the above-mentioned process of the present application, the execution subject of the file system mount is adjusted to be a device plug-in. I.e. the overall process of file system sharing is dominated by the device plugin. Thus, even if the sharing object is a non-privileged container, the sharing of the file system can be performed through the mounting information created by the device plugin. Thus, the file system existing in one container can be propagated and shared among a plurality of containers under the condition that the containers have no privilege rights.

In one embodiment, the creation of mount information of the file system to be shared in step S201 may include:

step S2011: a handle is created.

The created handle may be a set of codes, such as a numeric code or an alphabetic code, etc. A handle is an identifier used to identify an object, and generally refers to a method of acquiring an object, and one of the functions of the handle is to establish a connection with an object to be accessed.

Step S2012: and establishing mapping matching between the handle and the file system to be shared, and taking the handle after the mapping matching is established as mounting information.

As previously mentioned, a handle generally refers to a method of obtaining an object, one of its functions being to establish a connection with an object being accessed. Accordingly, a handle may be viewed as a method of acquiring or referencing the FUSE file system to be shared. Thus, a mapping match needs to be established between the created handle and the FUSE file system to be shared, so that there is an association between the created handle and the FUSE file system to be shared. After mapping and matching the created handle with the FUSE file system to be shared, the created handle can be used as the mounting information of the file system to be shared.

Based on the above, the created handle is used for referencing the file system to be shared existing in the first container, so that the handle can be used as the mounting information of the file system to be shared, and the mounting of the file system to be shared in the subsequent process can be realized.

In one embodiment, the mounting of the file system to be shared in the second container using the mounting information in step S202 may include:

step S2021: determining a first mount catalog in the container group; the container group comprises a first container and a second container.

The container group is a container group including a first container and a second container. And the execution and mounting are to enter the kernel for processing through an operating system call path, copy the user space transfer parameters to the kernel and carry out mounting delegation. The delivery parameters may include a mount directory, mount objects, some mount options, and the like. The mount catalog is a mount catalog in the container group, and in order to distinguish from a mount catalog in a second container, the mount catalog in the container group is referred to as a first mount catalog. The mounting object is the file system to be shared which is matched through the mounting information. The mount option may include specifying a type of file system to be mounted, specifying a mount manner as read-only mount or read-write mount, and the like.

The entire operating system is managed as a file in the operating system. Illustratively, "/" is the operating system root directory, which is the most important directory in the operating system, the root directory acting as an entry, all subdirectories being created under the root. Depending on the configuration of the container group, the mounting catalog in the container group may be determined. The first mount directory in the container group may be a directory for permanent storage of data or data caching configured at the time of container group creation, and illustratively, the mount directory may be a temporary mount directory ("/mnt"), a temporary file directory ("/tmp"), or the like. The above list is only illustrative, and the mount list may be adjusted or changed according to the requirement in the actual process.

Step S2022: and taking the first mounting catalogue as a mounting target, and mounting the file system to be shared, which is matched by using the mounting information.

The determined first mounting catalog can be used as a mounting target, so that the file system to be shared is mounted. Illustratively, the mount information referred to in the previous examples may be a handle that matches a mapping already established for the file system to be shared. Thus, the file system to be shared can be matched based on the handle. That is, the handle can obtain the mount object in the transfer parameter. Thus, the file system to be shared can be mounted to the first mounting directory of the container group based on the mounting parameters.

Step S2023: binding and mounting the first mounting catalogue to a second mounting catalogue in a second container.

Since the final objective is to make the file system to be shared accessible to the second container of non-privileged properties, the step of transferring the file system to be shared mounted in the container group to the second container also needs to be performed after mounting the file system to be shared to the container group. For this, a binding mount (bind mount) manner may be used to mount the first mount directory in the container group to the second mount directory in the second container. The function of binding mount is to mount one directory onto another directory, for example, by using a mount command with a bind parameter. When the first mount directory of the set of containers is bound to the second mount directory in the second container, the first mount directory and the second mount directory will reference the same object. The files of the first mount directory may be accessed from the second mount directory, i.e. the file system to be shared may be accessed from the second mount directory and vice versa. After the mount is completed, the so-called file system to be shared becomes a shared file system.

Since the design concept of the container group is to support multiple containers to share a network and a file system in one container group, the multiple containers can be combined to complete a service in a simple and efficient manner through inter-process communication and file sharing. Therefore, the method of firstly mounting the first mounting catalog of the container group to the second container by binding and mounting the first mounting catalog of the container group can be more in line with the existing container execution flow.

step S2024: in the second container, a second mounting catalog is determined.

In the foregoing manner, the file system is shared by first mounting the file system in the container group, and then binding and mounting the first mount directory of the container group to the second container. In the present mode, the file system may be shared by directly mounting the file system to the second container.

The above description is that the execution mount enters the kernel through the system call path to process, copies the user space transfer parameters to the kernel, and performs mount entrustment. The delivery parameters may include a mount directory, mount objects, some mount options, and the like. Thus, the file system is shared by directly mounting the file system to the second container, and the mount directory needs to be determined in the second container. In order to distinguish from the mount catalog in the container assembly previously described, the mount catalog in the second container is designated herein as the second mount catalog. The determining logic of the second mount directory is the same as the determining mode of the first mount directory, and will not be described again.

Step S2025: and taking the second mounting catalogue as a mounting target, and mounting the file system to be shared, which is matched by using the mounting information.

The determined second mounting catalog can be used as a mounting target, so that the file system to be shared is mounted. Illustratively, the mount information referred to in the previous examples may be a handle that matches a mapping already established for the file system to be shared. Thus, the file system to be shared can be matched based on the handle. That is, the handle can obtain the mount object in the transfer parameter. Thus, the file system to be shared can be mounted to the second mounting directory of the container group based on the mounting parameters.

Through the process, the file system is shared in a mode of being directly mounted in the second container, and the shared system does not pass through the container assembly, so that the risk of leakage does not exist, and the file system is more safely shared in a mode of being directly mounted in the second container.

In one embodiment, the mounting of the file system to be shared, which is matched using the mounting information, referred to in step S2022 or step S2025 may include:

step S20221: and determining a mounting point according to the mounting target.

The mount target may include a first mount catalog in a group of containers or a second mount catalog in a second container, collectively referred to herein as mount targets. The catalog corresponding to the mounting target may have multiple stages, and the mounting point is equivalent to an entry, for example, the multiple stages of catalogues "/mnt/a/b/c", "/mnt/a/" can be used as the determined mounting point. However, it should be noted that, since the mount operation may hide the files in the original directory, in general, if the root directory and the original directory of the operating system are used as mount points, an abnormal operating system and even a crash may be caused. Therefore, for the determination of the mounting point, a newly built empty directory is preferable.

Step S20222: and associating the file system to be shared matched by using the mounting information with the mounting point so as to mount the file system to be shared.

Mount refers to associating the file system to be shared with the container through a specified directory as a mount point. When performing a mount operation, it is necessary to determine a mount object. In this application, the validation of the mount object needs to depend on the mount information, i.e. the handle in the preamble step. The handle is matched with the mapping of the file system to be shared, so that the mounting object, namely the file system to be shared, can be matched through the unique handle. And finally, the mount command is utilized to complete the association of the file system to be shared and the mount point, so that the mount action is completed.

In one embodiment, the determining manner of the second container may include:

and analyzing the received file system sharing information to determine a second container, wherein the number of the second containers is at least one.

The file system sharing information is used for disclosing the number of containers and/or specific containers which need to participate in data processing in application scenes such as big data processing, AI model training and the like. Based on the above, the container to be shared by the file system to be shared can be determined according to the file system sharing information, that is, the second container is determined. It will be appreciated that the second container may be one or more according to the requirements of the application scenario.

An embodiment of the present application provides a method for sharing a file system, as shown in fig. 3, which is a flowchart of a method for accessing data in an embodiment of the present application, and corresponding to a second embodiment, the method may include:

step S301: accessing the mounted shared file system in response to the data processing task; the shared file system is mounted in advance using mounting information.

The data processing tasks may be generated based on application scenarios such as big data processing, AI model training, etc. Depending on the requirements of the application scenario, the data processing tasks may be distributed to different containers, so that the processes of data reading and writing or data computing may be performed by the respective containers. The different container is the container B in the example shown in fig. 1, i.e. the second container in the first embodiment. The number of second containers is plural and a second container is described herein as an example.

In application scenarios such as big data processing and AI model training, a data access request from a client is first transmitted to a daemon in a user state. The daemon will mount the FUSE file system to container a after system startup to provide FUSE file system services. That is, it will be appreciated that a data access request from a client will be transmitted into the first container in FIG. 1. In the first container, the data access request forwarded by the daemon will be parsed to determine the data to be accessed. Thereafter, the data to be accessed may be obtained in a remote object storage server.

When the second container executes the process, corresponding data is required to be obtained from the FUSE file system according to own data processing task, and the FUSE file system can correspond to the mounted shared file system. The device plug-in of Kubernets creates the mounting information, and the mounting information can be a handle, a hook function, and the like. The mount information may make other non-privileged containers perceivable to effect mount on the one hand and also need to be associated with the file system to be shared on the other hand. Taking the mounting information as an example of the handle, the handle can be established, and mapping matching is established between the handle and the file system to be shared, so that the association between the handle and the file system to be shared is realized. In the case of a hook function, its usage is similar to a handle. After the mount information of the file system to be shared is created, a mount (mount) operation may be performed in the second container. For performing mount operations, it may be referred to as mounting the file system represented by the handle to the mount directory of the container. For example, in one approach, the file system represented by the handle may be mounted directly to the mount directory of the second container. For another example, in another manner, the file system represented by the handle may be first mounted on the mount directory of the container group, and then the mount directory of the container group is shared for being transferred to the second container, so as to realize sharing the mount directory of the container group to the second container, and finally the file system represented by the handle is mounted on the mount directory of the second container.

Based on this, the second container, upon receiving the data processing task, may access the mounted shared file system in response to the data processing task.

Step S302: and performing data processing operation corresponding to the data processing task from the shared file system.

After the shared file system is accessed, the shared file system can be queried based on the data processing task so as to acquire the data corresponding to the data processing task for operation.

Through the above process, the process of file system sharing is dominated by the device plugin. Thus, even if the sharing object is a non-privileged container, the sharing of the file system can be performed through the mounting information created by the device plugin. Thus, the file system existing in one container can be propagated and shared among a plurality of containers under the condition that the containers have no privilege rights.

Corresponding to the application scene and the method of the method provided by the embodiment of the application, the embodiment of the application also provides a file system sharing device. FIG. 4 is a block diagram illustrating a file system sharing apparatus according to an embodiment of the present application, where the file system sharing apparatus may include:

the mounting information creating module 401 is configured to create mounting information of a file system to be shared, where the file system to be shared is a file system already mounted on the first container; the mounting information and the file system to be shared have a mapping relation, and the mounting information is used for enabling the non-privileged container to mount the file system to be shared;

a mounting module 402, configured to mount a file system to be shared in the determined second container by using mounting information; the first container and the second container are non-privileged containers.

In one embodiment, the mounting information creation module 401 may include:

a handle creation sub-module for creating a handle;

and the mapping matching sub-module is used for establishing mapping matching between the handle and the file system to be shared, and the handle after the mapping matching is established is used as mounting information.

In one embodiment, mounting module 402 may include:

the first mounting catalog determining submodule is used for determining a first mounting catalog in the container group; the container group comprises a first container and a second container;

the mounting execution sub-module is used for taking the first mounting catalogue as a mounting target and mounting the file system to be shared, which is matched by using the mounting information;

and the binding and mounting sub-module is used for binding and mounting the first mounting catalogue to a second mounting catalogue in the second container.

In one embodiment, mounting module 402 may include:

the second mounting catalog determining submodule is used for determining a second mounting catalog in the second container;

and the mounting execution sub-module is also used for taking the second mounting catalogue as a mounting target and mounting the file system to be shared which is matched by using the mounting information.

In one embodiment, the mounting execution sub-module may include:

the mounting point determining unit is used for determining mounting points according to the mounting targets;

and the association unit is used for associating the file system to be shared, which is matched by using the mounting information, with the mounting point so as to mount the file system to be shared.

In one embodiment, the method further comprises a second container determination module, the second container determination module being specifically configured to:

Corresponding to the application scene and the method of the method provided by the embodiment of the application, the embodiment of the application also provides a device for data access. FIG. 5 is a block diagram of an apparatus for data access according to an embodiment of the present application, which may include:

an access module 501 for accessing the mounted shared file system in response to a data processing task; the shared file system is mounted by using mounting information in advance;

the data processing module 502 is configured to perform a data processing operation corresponding to a data processing task from the shared file system.

Corresponding to the application scenario and method of the method provided by the embodiment of the present application, the embodiment of the present application further provides a system for data access, where the system may include:

a device plug-in for executing the method of file system sharing referred to in the first embodiment.

A non-privileged container for performing the method of data access referred to in the second embodiment.

The functions of each module in each device of the embodiments of the present application may be referred to the corresponding descriptions in the above methods, and have corresponding beneficial effects, which are not described herein.

Fig. 6 is a block diagram of an electronic device used to implement an embodiment of the present application. As shown in fig. 6, the electronic device includes: a memory 610 and a processor 620, the memory 610 storing a computer program executable on the processor 620. The processor 620, when executing the computer program, implements the methods of the above-described embodiments. The number of memory 610 and processors 620 may be one or more.

The electronic device further includes:

the communication interface 630 is used for communicating with external devices for data interactive transmission.

If the memory 610, the processor 620, and the communication interface 630 are implemented independently, the memory 610, the processor 620, and the communication interface 630 may be connected to each other and perform communication with each other through buses. The bus may be an industry standard architecture (Industry Standard Architecture, ISA) bus, an external device interconnect (PeripheralComponent Interconnect, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, among others. The bus may be classified as an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in fig. 6, but not only one bus or one type of bus.

Alternatively, in a specific implementation, if the memory 610, the processor 620, and the communication interface 630 are integrated on a chip, the memory 610, the processor 620, and the communication interface 630 may communicate with each other through internal interfaces.

The present embodiments provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods provided in the embodiments of the present application.

The embodiment of the application also provides a chip, which comprises a processor and is used for calling the instructions stored in the memory from the memory and running the instructions stored in the memory, so that the communication device provided with the chip executes the method provided by the embodiment of the application.

The embodiment of the application also provides a chip, which comprises: the input interface, the output interface, the processor and the memory are connected through an internal connection path, the processor is used for executing codes in the memory, and when the codes are executed, the processor is used for executing the method provided by the application embodiment.

It should be appreciated that the processor may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (FieldProgrammable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or any conventional processor or the like. It is noted that the processor may be a processor supporting an advanced reduced instruction set machine (Advanced RISC Machines, ARM) architecture.

Further alternatively, the memory may include a read-only memory and a random access memory. The memory may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), programmable Read-Only Memory (ProgrammableROM, PROM), erasable programmable Read-Only Memory (EPROM), electrically Erasable programmable Read-Only Memory (ElectricallyEPROM, EEPROM), or flash Memory, among others. Volatile memory can include random access memory (Random Access Memory, RAM), which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available. For example, static RAM (SRAM), dynamic RAM (Dynamic Random Access Memory, DRAM), synchronous DRAM (SDRAM), double data Rate Synchronous DRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), and direct memory bus RAM (DR RAM).

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. Computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another.

In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.

Any process or method described in flow charts or otherwise herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process. And the scope of the preferred embodiments of the present application includes additional implementations in which functions may be performed in a substantially simultaneous manner or in an opposite order from that shown or discussed, including in accordance with the functions that are involved.

Logic and/or steps described in the flowcharts or otherwise described herein, e.g., may be considered a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

It is to be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the methods of the embodiments described above may be performed by a program that, when executed, comprises one or a combination of the steps of the method embodiments, instructs the associated hardware to perform the method.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing module, or each unit may exist alone physically, or two or more units may be integrated in one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated modules described above, if implemented in the form of software functional modules and sold or used as a stand-alone product, may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic or optical disk, or the like.

The foregoing is merely exemplary embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think of various changes or substitutions within the technical scope of the present application, which should be covered in the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of file system sharing, comprising:

creating mounting information of a file system to be shared, wherein the file system to be shared is a file system already mounted on a first container; the mounting information and the file system to be shared have a mapping relation, and the mounting information is used for enabling the non-privileged container to mount the file system to be shared;

mounting the file system to be shared in the determined second container by utilizing the mounting information; the first container and the second container are non-privileged containers;

the determining mode of the second container comprises the following steps:

2. The method of claim 1, wherein creating mount information for the file system to be shared comprises:

creating a handle;

and establishing mapping matching between the handle and the file system to be shared, and taking the handle after the mapping matching as the mounting information.

3. The method of claim 1, wherein using the mount information to mount the file system to be shared in a second container comprises:

determining a first mount catalog in the container group; the container group comprises the first container and the second container;

taking the first mounting catalogue as a mounting target, and mounting the file system to be shared, which is matched by using the mounting information;

and binding and mounting the first mounting catalogue to a second mounting catalogue in the second container.

4. The method of claim 1, wherein using the mount information to mount the file system to be shared in a second container comprises:

determining a second mounting catalog in the second container;

and taking the second mounting catalogue as a mounting target, and mounting the file system to be shared, which is matched by using the mounting information.

5. The method according to claim 3 or 4, wherein the mounting the file system to be shared that is matched by using the mounting information includes:

determining a mounting point according to the mounting target;

and associating the file system to be shared, which is matched by using the mounting information, with the mounting point so as to mount the file system to be shared.

6. A method of data access, applied to a non-privileged container, the method comprising:

accessing the mounted shared file system in response to the data processing task; the shared file system is mounted by using mounting information in advance; said shared file system being pre-mounted using the method of any one of claims 1 to 5;

and carrying out data processing operation corresponding to the data processing task from the shared file system.

7. A system for data access, comprising:

a device plug-in for performing the method of file system sharing of any of claims 1 to 5;

a non-privileged container for performing the method of data access of claim 6.

8. An electronic device comprising a memory, a processor and a computer program stored on the memory, the processor implementing the method of any one of claims 1-6 when the computer program is executed.

9. A computer readable storage medium having stored therein a computer program which, when executed by a processor, implements the method of any of claims 1-6.