WO2022029290A1

WO2022029290A1 - Interfacing between file client and file server

Info

Publication number: WO2022029290A1
Application number: PCT/EP2021/072005
Authority: WO
Inventors: Carlos Ardanza Azcondo
Original assignee: Carlos Ardanza Azcondo
Priority date: 2020-08-07
Filing date: 2021-08-06
Publication date: 2022-02-10

Abstract

Methods are provided for interfacing between file-client and file-server on top of pre- existing underlying filesystem. File-server includes a structure of filesystem-items, each of the filesystem-items being a file or a folder, and each of the filesystem-items being included in one of the folders. The method comprises obtaining from underlying filesystem, for each of the filesystem-items, underlying metadata representing path and name and position in disk of the filesystem-item. The method further comprises converting the underlying metadata into interface metadata representing, for each of the folders, the path of the folder and name and position in disk of each of the filesystem-items in the folder. The method still further comprises storing the interface metadata in execution 1memory, and interfacing between file-client and file-server by using the interface metadata in execution memory instead of underlying metadata. Computer programs and systems are also provided that are suitable for performing such methods.

Description

INTERFACING BETWEEN FILE CLIENT AND FILE SERVER

This application claims the benefit of European Patent Application EP20382739.9 filed 07 August 2020.

The present disclosure relates to methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem. The present disclosure further relates to systems, computing systems and computer programs suitable for performing such interfacing methods.

BACKGROUND

A file server is a type of server that stores and distributes different types of computer files to clients on a computer network. Its function is to allow remote access in different ways to the files that are stored and accessible at the server. File servers are specialized in storing and managing large quantities of files, which may be seen as the main reason for its existence. In some computing applications and environments, it is necessary to list, copy, move, read, write, etc. large sets of files at a glance. File servers play a crucial role in this type of massive file operations.

However, inefficiencies may certainly exist in known filesystems with this type of massive operations. In client-server architectures, operation requests are normally sent from file client to file server, and the later resolves the request by returning large lists, sets, contents of files and/or folders to the former. This resolution by the file server may take long time and, therefore, the file client has to “patiently” wait for the server response.

An object of the disclosure is to provide new methods, systems and computer programs aimed at solving at least some of the aforementioned problems.

SUMMARY

In an aspect, a method is provided for interfacing between a file client and a file server on top of a pre-existing underlying filesystem. The file server includes a structure of filesystem-items, wherein each of the filesystem-items is a file or a folder, and each of the filesystem-items is included in one of the folders. The method comprises obtaining from the underlying filesystem, for each of the filesystem-items, underlying metadata representing a path and a name of the filesystem-item. The method further comprises converting the underlying metadata into interface metadata representing, for each of the folders, the path of the folder and the name of each of the filesystem-items within the folder. The method still further comprises storing the interface metadata in execution memory (e.g. RAM), and interfacing between the file client and the file server by using the interface metadata stored in the execution memory instead of the underlying metadata in the underlying filesystem.

The folders may comprise root and non-root folders. A root folder may be defined as the top-level directory or folder of a filesystem. The directory structure can be seen as an upside-down tree, so the term "root" represents the top level. Non-root folders may be seen as "branches" or subdirectories of a root folder. In such a tree structure, inclusion of a filesystem-item in a folder may be interpreted as a parent-child relationship with the folder as parent and the filesystem-item (included in the folder) as child. Therefore, each of the filesystem-items is included in one of the folders, except when the filesystem is a root folder, in which case the root folder is not included in another folder.

The concept of “metadata representing a path of a filesystem-item” may refer to any kind of metadata from which location of the filesystem-item may be directly inferred. Location of the filesystem-item may correspond to a sequence of folders from root folder to non- root folder containing the filesystem-item that have to be followed to get to the filesystemitem. Path or location of a filesystem-item may be represented in different manners, such as e.g. with a concatenation of folder names from root folder to non-root folder containing the filesystem-item, a list of folders with pointers from previous to next folder in the path, a list of folders with pointers from next to previous folder in the path, etc. Such pointers may be implemented in a variety of manners, such as e.g. through indexes, positions in memory, any data that may denote relations between filesystem-items, etc. One of the key aspects of the proposed methods may be that “underlying” metadata representing paths (in the underlying filesystem) is significantly reduced into much less voluminous interface metadata representing paths (in execution memory).

The proposed “interfacing” method permits performing (massive) file operations on top of pre-existing underlying filesystem much more efficiently than the underlying filesystem itself. The underlying metadata representing a path (obtained from underlying filesystem) may have any form or structure depending on the pre-existing underlying filesystem. In any case, said “underlying” metadata is converted into “interface” metadata which is much less voluminous than the former one. Metadata in the underlying filesystem representing same path several times is reduced to metadata (in filesystem interface performing the method) that represents the path of multiple files in same folder just once. This reduction of metadata may be achieved in different ways, such as e.g. through forward linked list and/or backward linked list of filesystem-items. These list-based manners of significantly reducing metadata from the underlying filesystem is described in detail in other parts of the disclosure. Moreover, this significant reduction of metadata permits storing it in execution memory (e.g. RAM), and this may permit performing (massive) file operations much more efficiently in comparison to the underlying filesystem itself.

A main purpose of methods according to present disclosure is two-fold: maximum reduction of metadata from underlying filesystem and having said reduced metadata (interface metadata) in execution memory (e.g. RAM). This two-fold purpose permits obtaining a synergic effect in the sense that the first one (metadata reduction) facilitates the second one (metadata in execution memory). In other words, the second aspect (metadata in RAM) may not be practicable or may be much less practicable without the first aspect (metadata reduction).

In some examples, obtaining the underlying metadata may further comprise obtaining metadata representing a structural relationship between folders and a tree of filesystemitems in the underlying filesystem, and converting the underlying metadata into interface metadata may comprise converting the metadata representing the structural relationship into a linked list of filesystem-items according to (and/or preserving) the structural relationship. The linked list may be formed or structured according to a forward linking approach and/or a backward linking approach.

In the forward linking approach, the linked list of filesystem-items may include, for each of the folders, a link to first filesystem-item in the folder and, for each of the filesystem-items in the folder, a link to next filesystem-item in the folder. Last filesystem-item in the folder may include null link (i.e. pointing to nothing). In the backward linking approach, the linked list of filesystem-items may include, for each of the filesystem-items, a link to the folder that includes the filesystem-item, such that a path of the filesystem-item may be formed by following “backward” links towards root folder. Backward link in root folder may be null link (i.e. pointing to nothing).

In the forward linking approach, paths may be formed by following the linked list forwardly, while in the backward linking approach, paths may be formed by following the linked list backwardly.

In implementations of the method, interfacing between the file client and the file server may include processing a listing request by selecting, from the interface metadata in the execution memory, a list of filesystem-items according to selection criteria in the listing request, and returning said list of filesystem-items in response to the listing request. Listing operations may be very efficient, since necessary information (interface metadata) is in execution memory and, therefore, accessing or calling the underlying filesystem may be avoided.

In some configurations, obtaining the underlying metadata may further comprise obtaining, for each of the files in the filesystem, a position of the file in disk, and the method may further comprise adding said obtained file positions in disk into the interface metadata stored in the execution memory.

In examples of the method, interfacing between the file client and the file server may include processing a request of reading multiple files. Said processing may include obtaining, from the interface metadata in the execution memory, the position in disk of the multiple files, determining disk block or blocks to be read depending on the obtained position in disk of the multiple files, and performing a sequential reading of the determined one or more blocks in order of their location in disk.

In some configurations, interfacing between the file client and the file server may include processing a request of performing a one-to-one reading of files by obtaining, from the interface metadata in the execution memory, the position in disk of each of the files to be read, determining disk block or blocks of each of the files depending on the obtained position in disk of the file, and performing a reading, for each of the files, of the determined one or more blocks of the file in order of their location in the file. The request may specify the one-to-one reading of one or more files and/or one or more partial folders and/or one or more complete folders, etc. The request may then be responded by reading the file(s) and/or partial or complete folder(s) specified in the request in one-to-one manner (i.e. one file after another).

According to some implementations, obtaining the underlying metadata may further comprise obtaining, for each of the files in the filesystem, a size and/or a last write time of the file, and the method may further comprise adding the obtained file sizes and/or last write times into the interface metadata stored in the execution memory.

In configurations of the method, interfacing between the file client and the file server may be performed without using or calling any file application programming interface, API, in operating system supporting the underlying filesystem. In line with the synergic effect described in other parts of the disclosure, file APIs may be bypassed since necessary information or metadata to perform (massive) file operations is in execution memory. In a further aspect, a system is disclosed for interfacing between a file client and a file server on top of a pre-existing underlying filesystem, the file server including a structure of filesystem-items. Each of the filesystem-items is a file or a folder, and each of the filesystem-items is included in one of the folders. The system comprises an obtaining module, a converting module, a storing module, and an interfacing module. The obtaining module is configured to obtain from the underlying filesystem, for each of the filesystemitems, underlying metadata representing a path and a name of the filesystem-item. The converting module is configured to convert the underlying metadata into interface metadata representing, for each of the folders, the path of the folder and the name of each of the filesystem-items within the folder. The storing module is configured to store the interface metadata in execution memory. The interfacing module is configured to interface between the file client and the file server by using the interface metadata stored in the execution memory instead of the underlying metadata in the underlying filesystem. This suggested “interfacing” system is suitable for performing “interfacing” methods according to present disclosure. Hence, aspects of such “interfacing” methods, such as e.g. functional, structural, advantageous aspects, may be similarly attributable to “interfacing” systems.

In a still further aspect, a computer program is provided comprising program instructions for causing a computing system to perform methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem, such as the ones described in other parts of the disclosure. The computer program may be embodied on a storage medium and/or carried on a carrier signal. This suggested “interfacing” computer program is suitable for performing “interfacing” methods according to present disclosure. Hence, aspects of such “interfacing” methods, such as e.g. functional, structural, advantageous aspects, may be similarly attributable to “interfacing” computer programs.

In a still further aspect, a computing system is provided for interfacing between a file client and a file server on top of a pre-existing underlying filesystem, the computing system comprising a memory and a processor, embodying instructions stored in the memory and executable by the processor, and the instructions comprising functionality or functionalities to execute methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem, such as the ones described in other parts of the disclosure. This suggested “interfacing” computing system is suitable for performing “interfacing” methods according to present disclosure. Hence, aspects of such “interfacing” methods, such as e.g. functional, structural, advantageous aspects, may be similarly attributable to “interfacing” computing systems. In some examples, a file server may be further provided including a system or a computing system for interfacing between a file client and the file server on top of a pre-existing underlying filesystem, such as the ones described in other parts of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting examples of the disclosure will be described in the following, with reference to the appended drawings, in which:

Figure 1 is a block diagram schematically illustrating systems for interfacing between a file client and a file server on top of a pre-existing underlying filesystem, according to examples.

Figure 2 is a flow chart schematically illustrating methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem, according to examples.

DETAILED DESCRIPTION OF EXAMPLES

Figure 1 is a block diagram schematically illustrating systems 100 for interfacing between a file client 102 and a file server 109 on top of a pre-existing underlying filesystem 101. The file server 109 may include a structure of filesystem-items. Each of the filesystemitems may be a file or a folder. Each of the filesystem-items may be included in one of the folders. The folders may comprise root folder(s) and non-root folders. A root folder may be defined as the top-level directory or folder of a filesystem. The directory structure can be visually represented as an upside-down tree, so the term "root" represents the top level. Non-root folders may be seen as "branches" or subdirectories of the root folder. A root folder is not included in another folder.

The system 100 comprises an obtaining module 103, a converting module 104, a storing module 105 and an interfacing module 107. The obtaining module 103 is configured to obtain from the underlying filesystem 101 , for each of the filesystem-items, underlying metadata representing a path and a name of the filesystem-item. The converting module 104 is configured to convert the underlying metadata into interface metadata representing, for each of the folders, the path of the folder and the name of each of the filesystem-items within the folder. The storing module 105 is configured to store the interface metadata in execution memory 106. The interfacing module 107 is configured to interface between the file client 102 and the file server 109 by using the interface metadata stored in the execution memory 106 instead of the underlying metadata in the underlying filesystem 101. Functionality of obtaining the underlying metadata (performable by e.g. obtaining module 103) may further comprise obtaining metadata representing a structural relationship between folders and a tree of filesystem-items in the underlying filesystem. Furthermore, the functionality of converting the underlying metadata into interface metadata (performable by e.g. converting module 104) may comprise converting the metadata representing the structural relationship into a linked list of filesystem-items according to (i.e. preserving) the structural relationship. In some examples, said linked list of filesystem-items may include, for each of the folders, a link to first filesystem-item in the folder and, for each of the filesystem-items in the folder, a link to next filesystem-item in the folder.

Functionality of interfacing between the file client 102 and the file server 109 (performable by e.g. interfacing module 107) may include processing a listing request from e.g. file client 102. Said processing may include selecting, from the interface metadata in the execution memory 106, a list of filesystem-items according to selection criteria in the listing request, and returning (to e.g. file client 102) said list of filesystem-items in response to the listing request.

Functionality of obtaining the underlying metadata (performable by e.g. obtaining module 103) may further comprise obtaining, for each of the files in the filesystem, a position of the file in disk 108. Once obtained, said file positions in disk 108 may then be added (by e.g. the storing module 105) into the interface metadata stored in the execution memory 106.

Functionality of interfacing between the file client 102 and the file server 109 (performable by e.g. interfacing module 107) may include processing a request of reading multiple files, said request being received from e.g. the file client 102. Said processing may include obtaining, from the interface metadata in the execution memory 106, the position in disk 108 of the multiple files, determining disk blocks to be read depending on the obtained position in disk 108 of the multiple files, and performing a sequential reading of the determined blocks.

Functionality of interfacing between the file client 102 and the file server 109 (performable by e.g. interfacing module 107) may include processing a request of performing a one-to- one reading of files, said request being received from e.g. the file client 102. Said processing may include obtaining, from the interface metadata in the execution memory 106, the position in disk 108 of each of the files to be read, determining disk block or blocks of each of the files depending on the obtained position in disk 108 of the file, and performing a reading, for each of the files, of the determined one or more blocks of the file in order of their location in the file.

Functionality of obtaining the underlying metadata (performable by e.g. obtaining module 103) may further comprise obtaining, for each of the files in the filesystem, a size and/or a last write time of the file. Once obtained, said file sizes and last write times may then be added (by e.g. the storing module 105) into the interface metadata stored in the execution memory 106.

In some implementations, functionality of interfacing between the file client and the file server (performable by e.g. interfacing module 107) without using any file application programming interface, API, in operating system supporting the underlying filesystem.

Figure 2 is a flow chart schematically illustrating methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem, according to examples. As generally shown in the figure, such “interfacing” methods may be initiated (e.g. at block 200) upon detection of a starting condition such as e.g. a request for starting the method or an invocation of the method from an operator of the interface or the like. Since interfacing methods according to Figure 2 are performable by systems according to previous Figure, number references from Figure 1 may be reused in following description of Figure 2.

Interfacing methods may further include (e.g. at block 201) obtaining from the underlying filesystem 101 , for each of the filesystem-items, underlying metadata representing a path and a name of the filesystem-item. This functionality implementable at block 201 may be performed by e.g. obtaining module such as module 103 previously described with reference to Figure 1. Functional details and considerations explained about said module 103 may thus be similarly attributed to method block 201.

Interfacing methods may still further include (e.g. at block 202) converting the obtained underlying metadata (from e.g. block 201) into interface metadata representing, for each of the folders, the path of the folder and the name of each of the filesystem-items within the folder. This functionality implementable at block 202 may be performed by e.g. converting module such as module 104 previously described with reference to Figure 1. Functional details and considerations explained about said module 104 may thus be similarly attributed to method block 202. Interfacing methods may yet further include (e.g. at block 203) storing the interface metadata (generated at e.g. block 202) in execution memory 106. This functionality implementable at block 203 may be performed by e.g. storing module such as module 105 previously described with reference to Figure 1 . Functional details and considerations explained about said module 105 may thus be similarly attributed to method block 203.

Interfacing methods may furthermore include (e.g. at block 204) interfacing between the file client 102 and the file server 109 by using the interface metadata stored in the execution memory 106 instead of the underlying metadata in the underlying filesystem 101. This functionality implementable at block 204 may be performed by e.g. interfacing module such as module 107 previously described with reference to Figure 1. Functional details and considerations explained about said module 107 may thus be similarly attributed to method block 204.

Interfacing methods may terminate (e.g. at block 205) when an ending condition is detected such as e.g. request for ending the method or an invocation of the method from an operator of the interface system or the like.

As used herein, the term “module” may be understood to refer to software, firmware, hardware and/or various combinations thereof. It is noted that the modules are exemplary. The modules may be combined, integrated, separated, and/or duplicated to support various applications. Also, a function described herein as being performed by a particular module may be performed by one or more other modules and/or by one or more other devices instead of or in addition to the function performed by the described particular module.

The modules may be implemented across multiple devices, associated or linked to corresponding methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem proposed herein, and/or to other components that may be local or remote to one another. Additionally, the modules may be moved from one device and added to another device, and/or may be included in both devices, associated to corresponding methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem proposed herein. Any software implementations may be tangibly embodied in one or more storage media, such as e.g. a memory device, a floppy disk, a compact disk (CD), a digital versatile disk (DVD), hard drives (HD), SSD units or other devices that may store computer code. The methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem according to present disclosure may be implemented by computing means, electronic means or a combination thereof. The computing means may be a set of instructions (e.g. a computer program) and then the methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem may comprise a memory and a processor, embodying said set of instructions stored in the memory and executable by the processor. These instructions may comprise functionality or functionalities to execute corresponding methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem such as e.g. the ones described with reference to other figures.

In case the methods of interfacing between a file client and a file server on top of a preexisting underlying filesystem are implemented only by electronic means, a controller of the system may be, for example, a CPLD (Complex Programmable Logic Device), an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit).

In case the methods of interfacing between a file client and a file server on top of a preexisting underlying filesystem are a combination of electronic and computing means, the computing means may be a set of instructions (e.g. a computer program) and the electronic means may be any electronic circuit capable of implementing corresponding method-steps of the methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem proposed herein, such as the ones described with reference to other figures.

The computer program(s) may be embodied on a storage medium (for example, a CD- ROM, a DVD, a USB drive, a computer memory or a read-only memory) or carried on a carrier signal (for example, on an electrical or optical carrier signal).

The computer program(s) may be in the form of source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other form suitable for use in implementing the methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem according to present disclosure. The carrier may be any entity or device capable of carrying the computer program(s).

For example, the carrier may comprise a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a hard disk. Further, the carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via electrical or optical cable or by radio or other means.

When the computer program(s) is/are embodied in a signal that may be conveyed directly by a cable or other device or means, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the computer program(s) is/are embedded, the integrated circuit being adapted for performing, or for use in the performance of, the methods of interfacing between a file client and a file server on top of a pre-existing underlying filesystem proposed herein.

Although only a number of examples have been disclosed herein, other alternatives, modifications, uses and/or equivalents thereof are possible. Furthermore, all possible combinations of the described examples are also covered. Thus, the scope of the disclosure should not be limited by particular examples, but it should be determined only by a fair reading of the claims that follow.

Claims

1 . A method of interfacing between a file client and a file server on top of a pre-existing underlying filesystem, the file server including a structure of filesystem-items, wherein each of the filesystem-items is a file or a folder, and each of the filesystem-items is included in one of the folders, the method comprising: obtaining from the underlying filesystem, for each of the filesystem-items, underlying metadata representing a path and a name of the filesystem-item; converting the underlying metadata into interface metadata representing, for each of the folders, the path of the folder and the name of each of the filesystem-items within the folder; storing the interface metadata in execution memory; and interfacing between the file client and the file server by using the interface metadata stored in the execution memory instead of the underlying metadata in the underlying filesystem.

2. A method according to claim 1 , wherein obtaining the underlying metadata further comprises obtaining metadata representing a structural relationship between folders and a tree of filesystem-items in the underlying filesystem; and wherein converting the underlying metadata into interface metadata comprises converting the metadata representing the structural relationship into a linked list of filesystem-items according to the structural relationship.

3. A method according to claim 2, wherein the linked list of filesystem-items includes, for each of the folders, a link to first filesystem-item in the folder and, for each of the filesystem-items in the folder, a link to next filesystem-item in the folder.

4. A method according to any of claims 2 or 3, wherein the linked list of filesystemitems includes, for each of the filesystem-items, a link to the folder that includes the filesystem-item.

5. A method according to any of claims 1 to 4, wherein interfacing between the file client and the file server includes processing a listing request by selecting, from the interface metadata in the execution memory, a list of filesystem-items according to selection criteria in the listing request, and returning said list of filesystem-items in response to the listing request.

6. A method according to any of claims 1 to 5, wherein obtaining the underlying metadata further comprises obtaining, for each of the files in the filesystem, a position of the file in disk; and wherein the method further comprises adding the obtained file positions in disk into the interface metadata stored in the execution memory.

7. A method according to claim 6, wherein interfacing between the file client and the file server includes processing a request of reading multiple files by obtaining, from the interface metadata in the execution memory, the position in disk of the multiple files, determining disk block or blocks to be read depending on the obtained position in disk of the multiple files, and performing a sequential reading of the determined block or blocks in order of their location in disk.

8. A method according to any of claims 6 or 7, wherein interfacing between the file client and the file server includes processing a request of performing a one-to-one reading of several files by obtaining, from the interface metadata in the execution memory, the position in disk of each of the files to be read, determining disk block or blocks of each of the files depending on the obtained position in disk of the file, and performing a reading of the determined block or blocks for each of the files to be read.

9. A method according to any of claims 1 to 8, wherein obtaining the underlying metadata further comprises obtaining, for each of the files in the filesystem, a size and/or a last write time of the file; and wherein the method further comprises adding the obtained sizes and/or last write times into the interface metadata stored in the execution memory.

10. A method according to any of claims 1 to 9, wherein interfacing between the file client and the file server is performed without using any file application programming interface, API, in operating system supporting the underlying filesystem.

11. A computer program comprising program instructions for causing a computing system to perform a method according to any of claims 1 to 10 of interfacing between a file client and a file server on top of a pre-existing underlying filesystem.

12. A computer program according to claim 11 , embodied on a storage medium and/or carried on a carrier signal.

13. A computing system for interfacing between a file client and a file server on top of a pre-existing underlying filesystem, the computing system comprising a memory and a processor, embodying instructions stored in the memory and executable by the processor, 14 the instructions comprising functionality to execute a method according to any of claims 1 to 10 of interfacing between a file client and a file server on top of a pre-existing underlying filesystem.

14. A system for interfacing between a file client and a file server on top of a pre-existing underlying filesystem, the file server including a structure of filesystem-items, wherein each of the filesystem-items is a file or a folder, and each of the filesystem-items is included in one of the folders, the system comprising: an obtaining module configured to obtain from the underlying filesystem, for each of the filesystem-items, underlying metadata representing a path and a name of the filesystem-item; a converting module configured to convert the underlying metadata into interface metadata representing, for each of the folders, the path of the folder and the name of each of the filesystem-items within the folder; a storing module configured to store the interface metadata in execution memory; and an interfacing module configured to interface between the file client and the file server by using the interface metadata stored in the execution memory instead of the underlying metadata in the underlying filesystem.

15. A file server comprising a system according to claim 14 for interfacing between a file client and the file server on top of a pre-existing underlying filesystem.