A file access system, access, apparatus and device

Abstract

This application discloses a file access system, access method, and device. In this application, a file system client receives a first request from an application, requesting to open and read a file, and the first request carries the file's path. The file system client sends a second request to a file system server, indicating that the file should be opened and read, and the second request includes the file's path. The file system server opens and reads the file according to the second request; the file system server then returns the file to the file system client. The file system client then sends the file to the application. The application's first request simultaneously requests to open and read the file. The file system client only needs to send the second request to the file system server to achieve both opening and reading of the file, effectively reducing the number of interactions between the application, the file system client, and the file system server, thus improving file access efficiency.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a file access system, access device, and equipment. Background Technology

[0002] Currently, when the computing side accesses files on the storage side (e.g., reading or writing files), multiple interactions are required between the computing and storage sides. The computing side first needs to obtain the file's metadata to determine its storage address. After obtaining the storage address, the computing side sends a request to the storage side to retrieve the file. Upon receiving the request, the storage side sends the file back to the storage side. This multiple interaction process results in low file access efficiency. Summary of the Invention

[0003] This application provides a file access system, access device, and equipment to improve file access efficiency.

[0004] Firstly, embodiments of this application provide a file access system, which includes a file system client and a file system server. The file system client is deployed close to the user, allowing the user to interact with the file system server and access files stored on the server. Taking reading a target file as an example, in this file access system, the file system client receives a first request from an application. This first request requests to open and read the target file, and the first request carries the path to the target file. Embodiments of this application do not limit the number of target files; there can be one or more.

[0005] The file system client sends a second request to the file system server, which instructs the target file to be opened and read. The second request includes the path of the target file.

[0006] After receiving the second request, the file system server opens and reads the target file according to the request; after reading the target file, the file system server sends the target file back to the file system client.

[0007] The file system client retrieves the target file from the file system server and sends a response to the first request to the application, which includes the target file.

[0008] The above only illustrates the reading of the target file. The writing process of the target file is similar and will not be described in detail here.

[0009] With the above system, when an application (such as one triggered by a user) reads a target file from the file system server through the file system client, it only needs to trigger a first request. This first request can simultaneously request to open and read the target file. The file system client only needs to send a second request to the file system server to open and read the target file, which can effectively reduce the number of interactions between the application, the file system client, and the file system server, and improve file access efficiency.

[0010] In one possible implementation, the file system client provides a first interface to the application. This first interface is a composite interface, through which the application can send a first request to the file system client to request the opening and reading of the target file.

[0011] Through the above system, the file system client can provide a first interface for applications, ensuring that applications can initiate the first request, thereby reducing the number of interactions between applications and the file system client.

[0012] In one possible implementation, the first request requests to open and read the target file. "Reading the target file" can mean reading the entire target file or reading a portion of the data within it; this portion of data is referred to as the target data. When the first request requests to read the target data, it also includes a data location, indicating the position of the target data within the target file. Correspondingly, the second request instructs to open the target file and read the target data from it. This second request also includes the data location.

[0013] When reading a target file, the file system server opens the target file and reads the target data from it according to the data location. After reading the target data, the file system server sends the target data back to the file system client; the response from the file system client to the application includes the target data.

[0014] Through the above system, the interaction method between the application, file system client, and file system server based on the first request and the second request is not only applicable to reading the entire target file, but also to reading part of the data in the target file, effectively expanding the applicable scenarios of the file access method.

[0015] In one possible implementation, the target data includes multiple sub-data distributed in a scattered manner in the target file, and the data location includes the location information of the multiple sub-data, the location information of any sub-data indicating the location of the sub-data in the target file.

[0016] Since the embodiments of this application do not limit the number of target files, the target data can be multiple sub-data distributed in one target file, or multiple sub-data distributed in multiple target files.

[0017] Through the above system, the target data consists of multiple distributed sub-data. The application, file system client, and file system server interact with each other based on the first request and the second request to read the sub-data in the target file in batches. That is, multiple sub-data can be read with one first request and one second request, which effectively ensures the efficiency of file access.

[0018] In one possible implementation, when the target data consists of multiple distributed sub-data items, the file system server opens the target file according to its path and reads the sub-data items from the target file based on their respective locations. The file system server then sends the sub-data items back to the file system client, and the file system client sends a response containing these sub-data items to the application.

[0019] The system described above enables the file system server to support batch reading of multiple sub-data items, which simplifies the file access process and improves file access efficiency.

[0020] In one possible implementation, the file system server sends multiple sub-data to the file system client via a single input / output (IO) message.

[0021] Through the above system, the file system server can send back multiple sub-data at once, reducing the number of interactions between the file system client and the file system server.

[0022] In one possible implementation, the location information of any sub-data includes an offset and a data length, where the offset indicates the offset of the sub-data from the start position of the target file, and the data length is the length of the sub-data.

[0023] The system described above allows for a simple representation of the position of sub-data within the target file using offset and data length.

[0024] Secondly, embodiments of this application also provide a file access method, which can be executed by a file system client. The beneficial effects are described in the relevant section of the first aspect and will not be repeated here. In this method:

[0025] The file system client receives a first request from the application, which is used to open and read the target file. The first request carries the path of the target file.

[0026] The file system client sends a second request to the file system server, instructing that the target file be opened and read. This second request includes the path to the target file. The file system client then retrieves the target file from the file system server.

[0027] The file system client sends a response to the application in response to the first request, which includes the target file.

[0028] In one possible implementation, the file system client provides a first interface to the application, enabling the application to call the first interface to send a first request to the file system client.

[0029] In one possible implementation, the first request is used to request the opening of the target file and the reading of the target data in the target file. The first request also includes a data location, which indicates the location of the target data in the target file. The second request is used to instruct the opening of the target file and the reading of the target data in the target file. When the file system client obtains the target file returned by the file system server, it also obtains the target data returned by the file system server.

[0030] In one possible implementation, the target data includes multiple sub-data distributed in a scattered manner in the target file, and the data location includes the location information of the multiple sub-data, the location information of any sub-data indicating the location of the sub-data in the target file.

[0031] In one possible implementation, when the file system client obtains the target data returned by the file system server, it also obtains multiple sub-data items returned by the file system server; the response from the file system client to the application includes these multiple sub-data items.

[0032] In one possible implementation, when the file system client obtains multiple sub-data items from the file system server, it obtains the multiple sub-data items from the file system server through a single IO message.

[0033] In one possible implementation, the location information of any sub-data includes an offset and a data length, where the offset indicates the offset of the sub-data from the start position of the target file, and the data length is the length of the sub-data.

[0034] Thirdly, this application also provides a file access method, which can be executed by a file system server. The beneficial effects are described in the relevant section of the first aspect and will not be repeated here. In this method:

[0035] The file system server receives a second request from the file system client. The second request instructs the client to open and read the target file. The second request includes the path to the target file.

[0036] The file system server opens and reads the target file based on the second request, and then sends the target file back to the file system client.

[0037] In one possible implementation, the second request instructs the opening of the target file and the reading of the target data within it; the data location indicates the position of the target data within the target file; when the file system server opens and reads the target file according to the second request, it opens the target file based on the file path, and reads the target data from the target file based on the data location. The file system server then reports the target data back to the file system client.

[0038] In one possible implementation, the target data includes multiple sub-data distributed in a scattered manner in the target file, and the data location includes the location information of the multiple sub-data, the location information of any sub-data indicating the location of the sub-data in the target file.

[0039] In one possible implementation, when the file system server reads target data from the target file based on the data location, it opens the target file according to the path of the target file, reads multiple sub-data from the target file according to the location of multiple sub-data, and then feeds back the multiple sub-data to the file system client.

[0040] In one possible implementation, when the file system server sends the target file back to the file system client, it sends back multiple sub-data items through a single IO message.

[0041] In one possible implementation, the location information of any sub-data includes an offset and a data length, where the offset indicates the offset of the sub-data from the start position of the target file, and the data length is the length of the sub-data.

[0042] Fourthly, embodiments of this application also provide a file access device. This file access device has the function of implementing the behavior in the method example of the second aspect described above. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the file access device includes a first receiving module and a first sending module. These modules can perform the corresponding functions in the method example of the second aspect described above. For details, please refer to the detailed description in the method example, which will not be repeated here.

[0043] Fifthly, embodiments of this application also provide a file access device. This data transmission device has the function of implementing the behavior in the method example of the third aspect described above. The beneficial effects can be found in the description of the first aspect and will not be repeated here. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the file access device includes a second receiving module, a processing module, and a second sending module. These modules can perform the corresponding functions in the method example of the first aspect described above, as detailed in the method example description, and will not be repeated here.

[0044] Sixthly, this application also provides a computing device, which includes a processor and a memory, and may further include a communication interface. The processor executes computer program instructions in the memory to perform the method provided by the second aspect or any possible implementation thereof. Alternatively, the processor executes computer program instructions in the memory to perform the method provided by the third aspect or any possible implementation thereof. The memory is coupled to the processor and stores computer program instructions and data necessary for determining data transmission. The communication interface is used for communicating with other devices.

[0045] Seventhly, this application also provides a computing device, which includes a memory and a processor, and optionally, a communication interface. The memory is coupled to the processor and stores computer program instructions and data required for file access. The processor executes the method provided in the second aspect or any possible implementation thereof; or executes the method provided in the third aspect or any possible implementation thereof. The communication interface is used for communicating with other devices.

[0046] Eighthly, this application provides a computing device system including at least one computing device. Each computing device includes a memory and a processor. The processor of at least one computing device is configured to access code in the memory to execute the method provided by the second aspect or any possible implementation thereof, or the processor of at least one computing device is configured to access code in the memory to execute the method provided by the third aspect or any possible implementation thereof.

[0047] Ninthly, this application provides a computer-readable storage medium that, when executed by a computing device, allows the computing device to perform the method provided in the second aspect or any possible implementation thereof, or to perform the method provided in the third aspect or any possible implementation thereof. The storage medium stores computer program instructions. The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid-state drive (SSD).

[0048] Tenthly, this application provides a computer device program product, which includes computer program instructions. When executed by a computing device, the computing device performs the method provided in the second aspect or any possible implementation thereof, or performs the method provided in the third aspect or any possible implementation thereof. The computer program product can be a software installation package. When it is necessary to use the method provided in the second aspect or any possible implementation thereof, or when it is necessary to use the method provided in the third aspect or any possible implementation thereof, the computer program product can be downloaded and executed on the computing device.

[0049] In the eleventh aspect, this application also provides a computer chip connected to a memory, the chip being used to read and execute computer program instructions stored in the memory, to execute the methods in the second aspect and various possible implementations of the second aspect, or to execute the methods in the third aspect and various possible implementations of the third aspect.

[0050] The technical effects that can be achieved in the second to eleventh aspects mentioned above are described in the description of the technical effects that can be achieved by the corresponding design schemes in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of a file reading process;

[0052] Figure 2 A schematic diagram of the structure of a file access system provided in this application;

[0053] Figure 3 A schematic diagram of the computing side provided in this application;

[0054] Figures 4A-4B This application provides a schematic diagram of the structure of a file system server.

[0055] Figure 5A schematic diagram of a file access method provided in this application;

[0056] Figure 6 A schematic diagram of the distribution of target data provided in this application;

[0057] Figures 7-8 A schematic diagram of a file access device provided in this application;

[0058] Figures 9-10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0059] Before introducing the file access system, method, apparatus, and device provided in the embodiments of this application, the following concepts involved in the embodiments of this application shall be clarified:

[0060] (1) Metadata.

[0061] Metadata, also known as intermediary data or relay data, is data about data. It mainly describes information about data properties, such as the storage address of the data, the data modification history, the size of the data, and the creation date of the data.

[0062] (2) File system.

[0063] A file system is a structured form of data storage and organization. It organizes data using the concept of "files," grouping data for the same purpose into different types of files according to the structural requirements of different applications. Different file extensions are typically used to indicate different file types, and each file is assigned an easy-to-remember name, or "filename." When there are many files, they are grouped according to a certain method, with each group of files placed in the same directory (or folder). Furthermore, directories can contain subdirectories (or subfolders) in addition to files, forming a tree-like structure. This tree-like structure has a specific name: file system. There are many types of file systems, common ones being Windows' FAT / FAT32 / NTFS, and Linux's EXT2 / EXT3 / EXT4 / XFS / BtrFS, etc. To facilitate searching, directories are listed level by level from the root node down to the file itself. The names of these directories, subdirectories, and files are concatenated using special characters (e.g., "\" in Windows / DOS, " / " in Unix-like systems). This string of characters is called the file path, such as " / etc / systemd / system.conf" in Linux or "C:\Windows\System32\taskmgr.exe" in Windows. A path is a unique identifier for accessing a specific file. For example, D:\data\file.exe in Windows is a file path, representing the file.exe file located in the data directory on the D partition.

[0064] The file system is built on block devices. The file system not only records the file path, but also records which blocks make up a file and which blocks record directory / subdirectory information.

[0065] For a file system, file system-related metadata includes two categories: file system metadata and inodes. The first category is file system metadata, which primarily describes the file system's structure. This file system metadata includes directory entries (dentry) and inodes. Dentry is the directory metadata within the file system. Each directory has a corresponding dentry. For any directory, the dentry records the directory names of its subdirectories, file names of its files, and the inode numbers of those files. The directory dentry can also record information such as the directory's creation time, modification time, and modification history. The second category is inodes. For any file, the inode records the file's creation time, modification time, file size, access permissions, and the object ID. All file inodes are collected to form an inode table, where inode numbers are used to index the inodes of individual files.

[0066] Another type is file metadata, which describes the file's own attributes, such as its storage address and modification history. For this type of file metadata, a metadata index can be built using the file's storage object identifier. This metadata index can be a B+ tree index, a B-tree index, or a hash index. The metadata index records the metadata of each file in key-value pairs, where the key is the file's storage object identifier, and the pointer is the file's metadata.

[0067] In a file system, to access a file, the system first queries the file system metadata based on the file's path. It then uses the directory names along the file's path to look up the dentry of each directory until it finds the file's inode number in the dentry of the last directory along the file's path. Finally, it uses this inode number to retrieve the file's inode from the inode table.

[0068] After obtaining the file's inode, the file's storage object identifier is determined from the inode. Using this identifier, the metadata index is queried to retrieve the file's metadata and determine its storage address. Once the storage address is determined, the file is accessed using that address.

[0069] Currently, when the computing side accesses files on the storage side (e.g., reading or writing files), multiple interactions are required between the computing side and the storage side. The computing side first needs to obtain the file's metadata to determine its storage address. After obtaining the file's storage address, the computing side sends a request to the storage side based on that address to retrieve the file. Upon receiving the request, the storage side sends the file back to the storage side. The process of the computing side accessing files on the storage side is described below.

[0070] like Figure 1 The diagram shows a flow chart of the process of accessing files on the computing side and the storage side. Before explaining the flow chart of accessing files on the computing side and the storage side, let's first introduce the structure of the computing side and the storage side.

[0071] The computing side is deployed with applications, virtual file systems (VFS), and clients.

[0072] In this context, the application is an application deployed on the computing side that needs to access files; that is, the application is the initiator of the file access operation.

[0073] A Virtual File System (VFS) is an "interface layer" that adapts to the deployment of different file systems on the compute side. The VFS sits between different file systems and applications. It can be understood as an abstraction of different file systems within the compute-side operating system, allowing different file systems to be presented in a unified form on the compute side. Strictly speaking, the VFS is not an actual file system. It only exists on the compute side; the VFS is created when the operating system starts and disappears when the operating system shuts down. The VFS is a software module in the compute-side kernel used to provide applications with an interface to access files, allowing different file systems to coexist.

[0074] The client is the file system client deployed on the compute side. All requests that the compute side needs to send to the storage side must go through the file system client. This client can be seen as the "front-end" software of the file system deployed on the compute side.

[0075] A storage device is provided on the storage side. This storage device can be a single computing device with storage capacity, or it can be a storage system, such as a centralized storage system or a distributed storage system. A file system is deployed on the storage device, storing the various files in the file system and metadata related to the file system, such as file system metadata and file metadata.

[0076] The process of accessing files on the storage side from the compute side is as follows:

[0077] ① The application calls the open (or Lookup) interface in the interface library to send an open command to the VFS. The open command is used to instruct the opening of a file (or to obtain the file's metadata). The open command carries the path of the file.

[0078] ② After receiving the open command, VFS analyzes it to determine the metadata of the file that needs to be retrieved. VFS then sends a first instruction to the client, which requests the metadata of the file.

[0079] ③ The client sends a metadata request to the storage device. This metadata request is used to request the metadata of the file and carries the path of the file.

[0080] ④ Upon receiving the metadata request, the storage device retrieves the file's metadata based on the file's path and sends the metadata back to the client. The client then transfers the file's metadata to the VFS. The VFS then transfers the file's metadata to the application.

[0081] ⑤ After obtaining the file's metadata, the application can perform operations such as reading and writing to the file. When the application determines that it needs to read the file, it calls the read interface in the interface library and sends a read command to the VFS. This read command indicates that the file should be read and carries the file's storage address.

[0082] Applications can read an entire file or just data within a file by calling the `read` interface. When an application calls the `read` interface to read data, the instruction carries not only the file's storage address but also the data's position within the file. This position information includes the data length and an offset. The data length is the length of the data to be read, and the offset is the offset from the beginning of the file. Furthermore, the `read` interface only supports carrying one data length and one offset; in other words, an application can only read a single continuous segment of data from the file by calling the `read` interface. If multiple continuous segments of data from the file are needed, the `read` interface must be called multiple times to trigger multiple `read` instructions. The following explanation uses the processing of a single `read` instruction as an example.

[0083] ⑥ After receiving the read instruction, VFS analyzes it and determines that the file needs to be read. VFS then sends a second instruction to the client, which requests to read the file.

[0084] ⑦ The client sends a file read request to the storage device. This file read request is used to request the reading of a file and carries the storage address of the file.

[0085] ⑧. After receiving a file read request, the storage device retrieves the file based on its storage address and sends the file back to the client. The client then transfers the file to the VFS. The VFS then transfers the file to the application.

[0086] 9. When the application no longer needs to read the file, it calls the close interface in the interface library to send a close instruction to the VFS. This close instruction is used to instruct the file to be closed.

[0087] ⑩ Upon receiving the close instruction, VFS analyzes it and determines that the file needs to be closed. VFS sends a third instruction to the client, which requests the file to be closed. The client then sends a file close request to the storage device, requesting that the file be closed.

[0088] The storage device closes the file after receiving a request to close it.

[0089] The process of writing and modifying files is similar to that of reading files. The difference lies in the different interfaces called by the application and the different content indicated by the information exchanged between VFS, the client, and the storage device. These details will not be elaborated here.

[0090] The process of the compute side accessing a file on the storage side shows that at least three interactions are required between the compute side and the storage side before the compute side can access the file on the storage side. This method has low file access efficiency and long latency.

[0091] Therefore, this application provides a file access method in which an application and a file system client are deployed on the computing side. The application can send a first request to the file system client, which requests to open and read a target file. That is, the first request requests to perform open and read operations on the target file. The first request carries the path of the target file.

[0092] After receiving the first request, the file system client sends a second request to the file system server (corresponding to the aforementioned storage device or storage side). This second request requests to open and read the target file, and includes the path to the target file. Upon receiving the second request, the file system server opens and reads the target file accordingly and returns the target file to the file system client. The file system client then sends a response to the first request to the application, which includes the target file.

[0093] On the file system client side, the first connection is provided to the application, which initiates the first request by calling the first interface.

[0094] As can be seen from the above process, when a file system client accesses a target file on a file system server, it only needs to send a second request carrying the target file path. It does not need to first obtain the target file's metadata and then use that metadata (i.e., the target file's storage address) to access the target file on the file system server. This reduces the number of interactions between the file system client and the file system server, effectively improving file access efficiency and reducing latency.

[0095] like Figure 2 The diagram shown is a structural schematic of a file access system provided in an embodiment of this application. The file access system includes a file system client 100 and a file system server 200.

[0096] A file system is deployed on the file system server 200, and the file system client 100 can access files (such as target files) on the file system server 200. In this embodiment, when the file system client 100 accesses a target file in the file system server 200, it only needs to send a second request carrying the path of the target file, without needing to obtain the metadata of the target file or the storage address of the target file (the storage address of the file is the address of the target file in the file system server 200), thereby reducing the number of interactions when the file system client 100 accesses the target file of the file system server 200.

[0097] In this embodiment of the application, the file system client 100 has the following functions:

[0098] Function 1: The file system client 100 provides a first interface to the application 300. This first interface supports opening and reading target files via their paths. Reading a target file can involve reading the entire file or reading a portion of the data within it (as mentioned in the question below).

[0099] The application 300 deployed on the computing side can call this first interface to obtain the target file by the path of the target file, without having to obtain the target file's metadata during the process of obtaining the target file.

[0100] In other words, when the application 300 needs to access the target file, it only needs to call the first interface once to complete the reading and opening of the target file.

[0101] It should be noted that the first interface refers to a function provided to application 300, which allows application 300 to open and read a target file through the target file's path. This application embodiment does not limit the specific form of the first interface. The first interface can be represented as a preset first request format, or it can be represented as a function callable by application 300.

[0102] by Figure 1 Taking the file reading process shown as an example, in Figure 1 In the illustrated file reading process, application 300 needs to call the open, read, and close interfaces sequentially to complete the file reading. However, in this embodiment, application 300 only needs to call a single first interface to read the target file. This simplifies the file access process for application 300.

[0103] Function 2: The file system client 100 reads the target file from the file system server 200 through a second request carrying the path of the target file.

[0104] The file system client 100 can send the second request when triggered by the application 300. As described above regarding the interaction between the client and the file system server 200, when the file system client 100 reads a target file from the file system server 200, it needs to first obtain the target file's metadata, and then access the target file from the file system server 200 based on its storage address. However, in this embodiment, the file system client 100 only needs to send one second request to complete the reading of the target file, thus reducing the number of interactions between the file system client 100 and the file system server 200.

[0105] exist Figure 1 In the illustrated file reading process, the file system client 100 first needs to send a metadata retrieval request to obtain the file's storage address. After obtaining the file's storage address, it sends a file read request carrying the file's storage address to the file system server 200 to read the file. After reading the file, it sends a file close request to the file system server 200 to instruct it to close the file. The computing side needs to send three requests sequentially. However, in this embodiment, when the application 300 needs to read the target file, it does not need to obtain the target file's metadata first; it only needs to send a first request carrying the target file's path to the file system client 100 to open and read the target file. The file system client 100 and the file system server 200 only need to interact once (i.e., send the second request) to complete the opening and reading of the target file, effectively ensuring file access efficiency and reducing file latency.

[0106] Furthermore, in practical application scenarios, there may be situations where application 300 only needs to read a portion of the data in the target file. For ease of explanation, this portion of data will be referred to as the target data. In this case, when application 300 accesses the target file through the first interface, in addition to indicating the path of the target file, it can also indicate the data location. The data location is used to indicate the position of the target data in the target file.

[0107] The file system server 200 has storage capabilities, and a file system is deployed on the file system server 200. The file system server 200 can receive and process a second request sent by the file system client 100, and open and read the target file according to the second request.

[0108] The file system server 200 determines the storage address of the target file based on the path of the target file, reads the target file from the storage address of the target file, and sends the target file back to the file system client 100.

[0109] The structure of the computation side is described below, such as... Figure 3 As shown, from a software perspective, the computing side includes application 300 and file system client 100.

[0110] Regarding the functions of application 300 and file system client 100 Figure 1 The computing-side application 300, VFS, and client functions shown are similar and will not be repeated here. The differences here are... Figure 1 The functions of the computing-side application 300, VFS, and client are described below. In this embodiment, the file system client 100 includes VFS and a client.

[0111] Application 300, deployed on the file system client 100 side, is an application used to access files. When it determines that it needs to access a target file, application 300 can call a first interface to initiate a first request. This first request instructs the opening and reading of the target file. The first request carries the path of the target file. When it is necessary to read target data from the target file, the first request can also carry the data location of the target data.

[0112] After receiving the first request, the file system client 100 generates a second request and sends it to the file system server 200. The file system client 100 and... Figure 1 The client and VFS correspondence shown indicate that client 100 of this file system undertakes the following: Figure 1 The mentioned client and VFS roles refer to the file system client 100, which includes both VFS and the client. The difference lies in:

[0113] The file system client 100 provides a first interface to the application 300, enabling the application 300 to initiate a first request by calling the first interface. Within the file system client, the VFS can receive the first request initiated by the application 300. The VFS may choose not to process the first request further, i.e., not to analyze its specific semantics, but instead transmit the first request to the client. The client, upon receiving the first request, can then generate and send the second request.

[0114] The interaction process between application 300 and file system client 100 (VFS and client) shows that when reading a file, only a small amount of interaction is needed between application 300 and file system client 100 to trigger file system client 100 to send a second request to file system server 200. The internal interaction method of file system client 100 is relatively simple and efficient. Furthermore, in situations such as... Figure 1 Although the file reading process shown is not explained in detail, VFS actually needs to perform some analysis operations, which consume some time and reduce file reading efficiency. However, in this embodiment, after receiving the first request, VFS can directly transmit the first request to the client, avoiding the time-consuming analysis operations and further ensuring file access efficiency.

[0115] The specific form of the file system server 200 is not limited in this embodiment. For example, the file system server 200 can be a storage device in a computing device, such as a hard disk or other persistent storage. Alternatively, the file system server 200 can be a storage system.

[0116] The following lists several possible storage system configurations that a file system server 200 might possess:

[0117] Type 1: Centralized storage system.

[0118] The data file system server 200 exists in the form of a centralized storage system, such as... Figure 4A As shown, the centralized storage system 210 has a unified entry point through which all data from external devices must pass. This entry point is the engine 211 of the centralized storage system. The engine 211 is the most core component of the centralized storage system, and many advanced functions of the storage system are implemented within it.

[0119] like Figure 4A As shown, engine 211 contains one or more controllers. Figure 4ATaking an engine containing a controller as an example, after the controller writes data to its memory 214, the controller can execute the steps performed by the data file system server 200 in the data access method provided in this application embodiment. In terms of hardware, the controller includes at least a network interface card (NIC) 212, a processor 213, and memory 214. The NIC 212 can be used to communicate with the file system client 100, thereby providing storage services to the file system client 100. The NIC 212 can also be used to communicate with the hard disk 215 to expand the storage system capacity. Through the NIC 212, the engine 211 can connect to more hard disks 215, thereby forming a very large storage resource pool.

[0120] Processor 213 can be a central processing unit (CPU) or other specific integrated circuits. Processor 221 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 213 is the main processing core inside the storage system, capable of maintaining the storage system, such as updating data metadata, performing persistent data storage, and data backup. In this embodiment, processor 213 can process the second request from the file system client 100, query the storage address of the target file using the target file's path, and read the target file according to the target file's storage address.

[0121] Memory 214 refers to the internal memory that directly exchanges data with processor 213. Memory includes at least one type of memory, such as random access memory (RAM) or read-only memory (ROM). For example, RAM can be dynamic random access memory (DRAM) or storage class memory (SCM). Memory 214 may also include other types of RAM, such as static random access memory (SRAM) or read-only memory. For read-only memory, it can be programmable read-only memory (PROM) or erasable programmable read-only memory (EPROM). Memory 214 may also be a dual in-line memory module (DIMM).

[0122] Memory 214 can be used to store file system metadata and metadata indexes. Memory 214 can also store computer program instructions required by processor 213 to perform processing operations on the second request.

[0123] Hard disk 215 is used to provide storage space, such as storing data. It can be a disk or other type of storage medium, such as a solid-state drive or a shingled magnetic recording hard disk. In this embodiment, hard disk 215 can be used to persistently store file system metadata and metadata inodes, as well as files in the file system.

[0124] Type 2: Distributed storage system.

[0125] like Figure 4B The diagram shown is a system architecture schematic of a distributed storage system provided in an embodiment of this application. The distributed storage system includes a server cluster. The server cluster includes one or more servers 220 ( Figure 4B The diagram shows three servers 220 (but is not limited to two servers 220), and these servers 220 can communicate with each other. A server 220 is a device that has both computing and storage capabilities, such as a server or desktop computer. A server is a node in this distributed storage system.

[0126] In terms of hardware, such as Figure 4BAs shown, server 220 includes at least processor 221, memory 222, network interface card 223, and hard disk 224. Processor 221, memory 222, network interface card 223, and hard disk 224 are connected via a bus.

[0127] The functions and types of processor 221, memory 222, network card 223 and hard disk 224 are the same as those of network card 212, processor 213, memory 214 and hard disk 215. For details, please refer to the above description, which will not be repeated here.

[0128] Unlike centralized storage systems, in distributed storage systems, file system metadata, metadata indexes, and files within the file system are distributed across various servers 220. Within the distributed storage system, the servers 220 can collaborate to handle second requests from the file system client 100. This application embodiment does not limit the specific method by which the distributed storage system handles the file system client 100.

[0129] join Figure 5 The illustration shows a file access method provided in this application embodiment. The method uses the file to be opened and read as the target file for explanation. The file access method includes two parts: one part is the process of the file system client 100 initiating a second request. In this process, the file system client 100 sends a second request to the file system server 200 under the trigger of the application 300, as detailed in steps 501 to 503; the other part is the process of the file system server 200 processing the second request. In this process, after receiving the second request from the file system client 100, the file system server 200 opens and reads the target file according to the second request, as detailed in steps 504 to 506.

[0130] Step 501: Application 300 calls the first interface to generate a first request. This first request instructs the opening and reading of a target file, and carries the path to the target file. Optionally, the first request may also carry the data location. This embodiment does not limit the number of target files; the first request may request the opening and reading of one target file or multiple target files. That is, the first request may carry the path to one target file or the paths to multiple target files.

[0131] When application 300 determines that it needs to read a target file, it calls the first interface to generate a first request. This embodiment of the application does not limit the method by which application 300 determines that it needs to read a target file.

[0132] For example, application 300 provides a visual interface to the user, allowing the user to view the file system, determine its structure, and perform operations such as viewing and writing files within the file system. Application 300 can determine whether to read the target file by detecting the user's actions within the visual interface.

[0133] For example, application 300 has data processing capabilities and can process data. If application 300 is used to train a machine learning model, during the training process, it needs to read the parameter file of the machine learning model (which includes the parameters to be configured for the model). During training, it adjusts the parameters in the parameter file and stores the adjusted parameters in the file system server 200. Therefore, application 300 needs to access the parameter file in the file system server 200.

[0134] For example, application 300 might be a neural network model (a common type of machine learning model). During operation, this model needs to obtain the input data and its parameter file stored on the file system server 200. It then configures itself using the parameters in the parameter file. After configuration, it obtains the input data, learns from it, and outputs a prediction result. Therefore, the neural network model needs to interact with the file system server 200 to obtain data and parameter files during operation.

[0135] The first request generated by application 300 carries the path to the target file. When application 300 needs to read target data from the target file, the first request may also carry the data location. This data location indicates the position of the target data within the file. For information on file paths, please refer to the aforementioned explanation of the file system; it will not be repeated here.

[0136] This application does not limit the specific presentation of the data position. For example, the data position includes an offset and a length, where the offset is the length of the target data in the target file from the start position of the target file. The length is the size of the target data. As another example, the data position includes a start position and an end position. The start position is the start position of the target data in the target file, which can be represented by the offset of the start position of the target data from the start position of the target file. The end position is the end position of the target data in the target file, which can be represented by the offset of the end of the target data from the start position of the target file.

[0137] The specific location of the target data in the target file is not limited in the embodiments of this application. For example Figure 6 As shown, two exemplary distribution methods of target data in a target file are demonstrated. One distribution method is continuous distribution, meaning the target data is continuously distributed within the target file, which indicates that the target data is a continuous segment of data without gaps. The other distribution method is distributed distribution, meaning the target data is more dispersed within the target file, i.e., the target data includes multiple sub-data, each of which is continuously distributed within the target file.

[0138] When the target data is distributed in a scattered manner in the target file, the data location includes the location information of each sub-data. The location information of each sub-data is used to indicate the location of the sub-data in the target file. The specific procedure for the location information of the sub-data is similar to the specific presentation method of the data location. For details, please refer to the above description, which will not be repeated here.

[0139] Furthermore, since the number of target files requested to be opened and read in this application embodiment is not limited, when the first request requests to open and read target data in a target file, the target data may be concentrated in one target file. In other words, the target data includes multiple sub-data, which are concentrated in one target file. Within that target file, the multiple sub-data can be distributed dispersedly or continuously. Alternatively, the target data may be distributed across different target files. In other words, the target data includes multiple sub-data, which are distributed across different target files. For any given target file, the target file includes one or more sub-data. When the target file includes multiple data, the multiple sub-data can be distributed dispersedly or continuously.

[0140] Step 502: File system client 100 receives the first request.

[0141] Within the file system client, since VFS is an abstraction layer for different file systems in file system client 100, all file access messages or commands must go through VFS. When application 300 initiates a first request, the first request will first reach VFS. After VFS determines that the first request is a command generated by calling the first interface, it will transmit the first request to the client.

[0142] This application embodiment does not limit the method by which the VFS determines that the first request is an instruction generated by calling the first interface. For example, the first request generated by application 300 calling the first interface includes an operation type field, which describes the operation type of the first request, that is, the operation type field indicates that the operation type is file access. By parsing the operation type field, the VFS determines that the operation type of the first request is file open and read, and thus determines that the first request is an instruction generated by calling the first interface.

[0143] For example, the first request generated by application 300 calling the first interface includes an interface field. This interface field describes the interface called to generate the first request; that is, the interface field indicates the first interface. VFS determines that the interface called to generate the first request is the first interface by parsing this interface field.

[0144] Step 503: The file system client 100 generates a second request based on the first request and sends the second request to the file system server 200. The second request carries the path to the target file, and optionally, the data location as well.

[0145] In this embodiment of the application, the first request and the second request have the same meaning. The first request is a message transmitted internally by the file system client 100, while the second request is a message exchanged between the file system client 100 and the file system server 200. The format of the second request needs to follow the protocol between the file system client 100 and the file system server 200, such as server message block (SMB) or common internet file system (CIFS).

[0146] Step 504: After receiving the second request, the file system server 200 opens and reads the target file according to the second request.

[0147] When the file system server 200 opens and reads the target file according to the second request, it obtains the path of the target file from the second request (optionally, it can also obtain the data location).

[0148] The file system server 200 uses the path of the target file to query the file system metadata to determine the file's storage object identifier. The process of using the target file's path to query the file system metadata to determine the file's storage object identifier can be found in the relevant documentation on file systems, and will not be elaborated upon here.

[0149] After obtaining the storage object identifier of the file, the file system server 200 uses the storage object identifier of the target file to query the metadata index and obtain the metadata of the target file.

[0150] The method for querying the metadata index using the storage object identifier of the target file depends on the type of the metadata index. Different types of metadata indexes require different query methods. For example, when the metadata index is a B+ tree index, the file system server 200 uses the storage object identifier of the metadata to query layer by layer from the root node of the B+ tree index until it locates the leaf node at the bottom level, where it retrieves the file's metadata.

[0151] After obtaining the file's metadata, the file system server 200 obtains the target file's storage address from the target file's metadata and reads the target file based on the target file's storage address.

[0152] When the second request carries the data location, the file system server 200 determines the storage address of the target data based on the storage address of the target file and the data location, and reads the target data based on the storage address of the target data.

[0153] For example, assuming the data location includes an offset and a length, the storage address of the target file includes the length of the target file and its starting address. The address of the starting address of the target file offset by this offset is the starting address of the target data. The storage address of the target data includes the length of the target data and its starting address. Alternatively, assuming the data location includes a starting position and an ending position, the storage address of the target file includes the length of the target file and its starting address. The address of the starting address of the target file offset by this starting position is the starting address of the target data. The address of the starting address of the target file offset by this ending position is the ending address of the target data. The storage address of the target data includes both the starting address and the ending address.

[0154] When the target data includes multiple sub-data items distributed throughout the file, the data location includes the location information of each sub-data item. For any sub-data item, the file system server 200 determines the storage address of the sub-data item based on the storage address of the target file and the location information of the sub-data item, and reads the sub-data item based on the storage address of the sub-data item. The method by which the file system server 200 determines the storage address of the sub-data item based on the storage address of the target file and the location information of the sub-data item is similar to the method by which the file system server 200 determines the storage address of the target data item based on the storage address of the target file and the location information of the data item. For details, please refer to the foregoing explanation, which will not be repeated here.

[0155] For the file system server 200, it stores file system metadata. Using the file path, the server can quickly retrieve the metadata of the file to be accessed through both the file system metadata and the file metadata, thereby obtaining the file's storage address and enabling file access. The server 200 no longer needs to return file metadata to the file system client 100; it internally handles the metadata lookup and the operation of reading the target file based on the storage address, improving file access efficiency. Furthermore, the server 200 supports access to distributed target data. It only needs to receive one second request to access the distributed target data, further ensuring file access efficiency.

[0156] Step 505: The file system server 200 sends the target file back to the file system client 100. If the second request is used to request opening the target file and reading the target data, then the file system server 200 sends the target data back to the file system client 100.

[0157] In step 505, the file system server 200 only needs to return the target file or target data through a single IO message, which reduces the number of interactions between the file system server 200 and the file system client 100.

[0158] Step 506: The file system client 100 sends a response to the first request to the application 300, the response including the target file. If the first request was used to request opening the target file and reading the target data, then the response carries the target data.

[0159] Inside the file system client 100, after receiving the target file (or target file), the file system client 100 transmits the response to the application 300 through the VFS.

[0160] The aforementioned explanation uses file opening and reading as examples. In reality, the file system client 100 also supports file writing. Similar to file reading, the file system client 100 can provide a second interface to the application 300, which supports opening and writing files. The application 300 (by calling this second interface) sends a third request to the file system client 100, requesting to open and write a file. After receiving the third request, the file system client 100 sends a fourth request to the file system server 200, requesting to open and write a file. The file server then opens and writes the file according to this fourth request. The interaction between the application 300, the file system client 100, and the file system server 200 is similar to the interaction during file reading. The only difference is that during the writing process, each request indicates writing to the target file. The file system server 200 writes the target file after determining its storage address. For details, please refer to the relevant explanations of the file reading process; they will not be repeated here.

[0161] Based on the same inventive concept as the method embodiments, this application also provides a file access device, which is deployed in the file system client 100. This file access device is used to execute the method executed by the file system client 100 in the above method embodiments. Figure 7 As shown, the file access device 700 includes a first receiving module 701 and a first sending module 702. Specifically, in the file access device 700, the modules are connected through a communication path.

[0162] The first receiving module 701 is used to: receive a first request from the application, the first request being used to open and read a target file, the first request carrying the path of the target file.

[0163] The first sending module 702 is used to: send a second request to the file system server, the second request being used to instruct the opening and reading of the target file, the second request including the path of the target file.

[0164] The first receiving module 701 is also used to: obtain the target file returned by the file system server.

[0165] The first sending module 702 is further configured to: send a response to the first request to the application, the response including the target file.

[0166] As one possible implementation, the first receiving module 701 provides a first interface to the application, so that the application calls the first interface to send a first request to the file system client.

[0167] As one possible implementation, the first request is used to request the opening of the target file and the reading of the target data in the target file. The first request also includes a data location, which indicates the location of the target data in the target file. The second request is used to instruct the opening of the target file and the reading of the target data in the target file. The first receiving module 701 obtains the target data fed back by the file system server.

[0168] As one possible implementation, the target data includes multiple sub-data distributed in a scattered manner in the target file, and the data location includes the location information of multiple sub-data, with the location information of any sub-data indicating the location of the sub-data in the target file.

[0169] As one possible implementation, the response includes multiple sub-data, and the first receiving module 701 obtains multiple sub-data fed back by the file system server.

[0170] As one possible implementation, the first receiving module 701 obtains multiple sub-data fed back by the file system server through a single input / output IO message.

[0171] As one possible implementation, the location information of any sub-data includes an offset and a data length. The offset indicates the offset of the sub-data from the start position of the target file, and the data length is the length of the sub-data.

[0172] Based on the same inventive concept as the method embodiments, this application also provides a file access device, which is deployed on the file system server 200 and is used to execute the method executed on the file system server 200 in the above method embodiments. Figure 8 As shown, the file access device 800 includes a second receiving module 801, a processing module 802, and a second sending module 803. Specifically, in the file access device 800, the modules are connected through a communication path.

[0173] The second receiving module 801 is configured to: receive a second request sent by the file system client, the second request being used to instruct the opening and reading of a target file, the second request including the path of the target file.

[0174] Processing module 802 is used to: open and read the target file according to the second request.

[0175] The second sending module 803 is used to: send the target file back to the file system client.

[0176] In one possible implementation, the second request is used to instruct the opening of the target file and the reading of the target data in the target file; the data location indicates the position of the target data in the target file; when the processing module 802 opens and reads the target file according to the second request, it opens the target file and reads the target data from the target file according to the data location; the second sending module 803 sends the target data back to the file system client.

[0177] As one possible implementation, the target data includes multiple sub-data distributed in a scattered manner in the target file, and the data location includes the location information of multiple sub-data, with the location information of any sub-data indicating the location of the sub-data in the target file.

[0178] In one possible implementation, processing module 802 opens the target file according to its path and reads multiple sub-data items from the target file based on their positions. Second sending module 803 then sends the multiple sub-data items back to the file system client.

[0179] As one possible implementation, the second sending module 803 sends multiple sub-data to the file system client via a single IO message.

[0180] As one possible implementation, the location information of any sub-data includes an offset and a data length. The offset indicates the offset of the sub-data from the start position of the target file, and the data length is the length of the sub-data.

[0181] The module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0182] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a terminal device (which may be a personal computer, mobile phone, or network device, etc.) or processor to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0183] This application also provides, for example Figure 9 The computing device 900 shown includes a bus 901, a processor 902, a communication interface 903, and a memory 904. The processor 902, the memory 904, and the communication interface 903 communicate with each other via the bus 901.

[0184] The processor 902 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0185] Memory 904 can be dynamic random access memory (DRAM). Besides DRAM, memory 904 can also be other types of random access memory, such as static random access memory (SRAM). Additionally, memory 902 can also be read-only memory (ROM). For example, read-only memory can be programmable read-only memory (PROM) or erasable programmable read-only memory (EPROM). Memory 904 can also be flash memory, hard disk drive (HDD), or solid-state drive (SSD).

[0186] The memory 904 stores computer program instructions, and the processor 902 calls these computer program instructions to execute the aforementioned... Figure 5 The steps performed by the file system client 100 in the described method, or the computer program instructions invoked to perform the aforementioned steps, are described. Figure 5 The described method includes the steps of the file system server 200. The memory 904 may also include software modules required by other running processes, such as the operating system (e.g., multiple modules in file access device 700 or file access device 800). The operating system may be Linux. TM UNIX TM WINDOWS TM wait.

[0187] This application also provides a computing device system, the computing device system including at least one such as Figure 10 The computing device 1000 shown includes a bus 1001, a processor 1002, a communication interface 1003, and a memory 1004. The processor 1002, the memory 1004, and the communication interface 1003 communicate with each other via the bus 1001. At least one computing device 1000 in the computing device system communicates with each other via a communication path.

[0188] The specific types of processor 1002 and memory 1004 can be found in the relevant descriptions of processor 902 and memory 904, and will not be repeated here. Processor 1002 calls the computer program instructions stored in memory 1004 to execute the aforementioned... Figure 5The described method involves some or all of the steps performed by the file system client 100. Alternatively, the processor 1002 may invoke computer program instructions stored in the memory 1004 to execute the aforementioned steps. Figure 5 The described method includes some or all of the steps executed by the file system server 200. The storage may also include other software modules required by the running processes, such as the operating system. The operating system may be Linux. TM UNIX TM WINDOWS TM wait.

[0189] At least one computing device 1000 in the computing device system establishes communication with each other through a communication network, and each computing device 1000 runs any one or any multiple modules of the file access device 700.

[0190] At least one computing device 1000 in the computing device system establishes communication with each other through a communication network, and each computing device 1000 runs any one or any multiple modules of the file access device 800.

[0191] The descriptions of the processes corresponding to the above-mentioned figures each have their own emphasis. For parts of a process that are not described in detail, please refer to the relevant descriptions of other processes.

[0192] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, in the form of a computer program product. A computer program product includes computer program instructions, which, when loaded and executed on a computer, generate, in whole or in part, the product according to the embodiments of the present invention. Figure 5 The process or function described.

[0193] The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., SSD).

[0194] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A file access system, characterized in that, The system includes a file system client and a file system server; The file system client is used to receive a first request from the application, the first request being to request to open and read a target file, the first request carrying the path of the target file; Send a second request to the file system server, the second request being used to instruct the opening and reading of the target file, the second request including the path of the target file; The file system server is used to open and read the target file according to the second request; The target file is returned to the file system client; The file system client is also configured to send a response to the first request to the application, the response including the target file.

2. The system as described in claim 1, characterized in that, The file system client is also used for: A first interface is provided to the application so that the application can call the first interface to send the first request to the file system client.

3. The system as described in claim 1 or 2, characterized in that, The first request is used to request the opening of the target file and the reading of the target data in the target file. The first request also includes a data location, which indicates the position of the target data in the target file. The second request is used to instruct the opening of the target file and the reading of the target data in the target file. The file system server is further configured to open the target file, read the target data from the target file according to the data location, and send the target data back to the file system client; the response includes the target data.

4. The system as described in claim 3, characterized in that, The target data includes multiple sub-data distributed in the target file, and the data location includes the location information of the multiple sub-data, wherein the location information of any one of the sub-data indicates the location of the sub-data in the target file.

5. The system as described in claim 4, characterized in that, The file system server is used for: The target file is opened according to the path of the target file, and the multiple sub-data are read from the target file according to their respective positions; the multiple sub-data are fed back to the file system client; the response includes the multiple sub-data.

6. The system according to claim 5, characterized in that, The file system server is configured to: send the multiple sub-data back to the file system client via a single input / output (IO) message.

7. The system according to any one of claims 4 to 6, characterized in that, The location information of any of the sub-data includes an offset and a data length, wherein the offset indicates the offset of the sub-data from the starting position of the target file, and the data length is the length of the sub-data.

8. A file access method, characterized in that, The method is applied to a file system client, and the method includes: Receive a first request from the application. The first request is used to open and read the target file. The first request carries the path of the target file. Send a second request to the file system server, the second request being used to instruct the opening and reading of the target file, the second request including the path of the target file; Obtain the target file returned by the file system server; Send a response to the first request to the application, the response including the target file.

9. The method as described in claim 8, characterized in that, The method further includes: A first interface is provided to the application so that the application can call the first interface to send the first request to the file system client.

10. The method as described in claim 8 or 9, characterized in that, The first request is used to request the opening of the target file and the reading of the target data in the target file. The first request also includes a data location, which indicates the position of the target data in the target file. The second request is used to instruct the opening of the target file and the reading of the target data in the target file. The step of obtaining the target file returned by the file system server includes: Obtain the target data returned by the file system server.

11. A file access method, characterized in that, The method is applied to a file system server, and the method includes: Receive a second request sent by the file system client, the second request being used to instruct the opening and reading of the target file, the second request including the path of the target file; According to the second request, open and read the target file; The target file is returned to the file system client.

12. The method as described in claim 11, characterized in that, The second request is used to instruct the opening of the target file and the reading of the target data from the target file; The data location indicates the position of the target data in the target file; The step of opening and reading the target file according to the second request includes: Open the target file and read the target data from the target file according to the data location; The step of sending the target file back to the file system client includes: The target data is fed back to the file system client.

13. A file access device, characterized in that, The device is deployed in a file system client, and the device includes: The first receiving module is configured to: receive a first request from the application, the first request being used to open and read a target file, the first request carrying the path of the target file; The first sending module is configured to: send a second request to the file system server, the second request being used to instruct the opening and reading of the target file, the second request including the path of the target file; The first receiving module is further configured to: obtain the target file fed back by the file system server; The first sending module is further configured to: send a response to the first request to the application, the response including the target file.

14. The apparatus as claimed in claim 13, characterized in that, The first receiving module is further configured to: A first interface is provided to the application so that the application can call the first interface to send the first request to the file system client.

15. The apparatus as claimed in claim 13 or 14, characterized in that, The first request is used to request the opening of the target file and the reading of the target data in the target file. The first request also includes a data location, which indicates the position of the target data in the target file. The second request is used to instruct the opening of the target file and the reading of the target data in the target file. The first receiving module is used for: Obtain the target data returned by the file system server.

16. A file access device, characterized in that, The device is deployed on a file system server, and the device includes: The second receiving module is configured to: receive a second request sent by a file system client, the second request being used to instruct the opening and reading of the target file, the second request including the path of the target file; The processing module is configured to: open and read the target file according to the second request; The second sending module is used to: send the target file back to the file system client.

17. The apparatus as claimed in claim 16, characterized in that, The second request is used to instruct the opening of the target file and the reading of the target data from the target file; the data location indicates the position of the target data in the target file; the processing module is used to: Open the target file and read the target data from the target file according to the data location; The second sending module is used for: The target data is fed back to the file system client.

18. The apparatus as claimed in claim 17, characterized in that, The target data includes multiple sub-data distributed in the target file, and the data location includes the location information of the multiple sub-data, wherein the location information of any one of the sub-data indicates the location of the sub-data in the target file.

19. A computing device, characterized in that, The computing device includes a processor and memory; The memory is used to store computer program instructions; The processor executes computer program instructions in the memory to perform the method as described in any one of claims 8 to 12.

20. A computer-readable storage medium, characterized in that, When the computer-readable storage medium is executed by a computing device, the computing device performs the method of any one of claims 8 to 12.

Images