File Management in a Computing Device

Abstract

When reading a directory on a computing device, the file server adds unique tags to the listing when passing the listing to a client application. The file server keeps a list of the unique tags together with the physical addresses of the files to which they correspond. When a client wishes to open a file, it can do so by passing the tag to the file server. This enables the file server to load the file directly without having to undertake a second directory search to discover the physical location of the file from its filename.

Description

An embodiment of the present invention will now be described, by way of further example only.

With the present invention, when a client requests a directory listing, the file system builds two lists; one is returned to the client, whilst the other is held by the server. The list returned to the client is a standard directory list with each entry extended to include a tag referring to the corresponding entry in the server-side list. The list held by the server includes (as a minimum) the tag; together with information about the physical location of each file on a drive (this is the information that is needed to open the file). Note that because each entry returned to the client is tagged, the client can freely sort its own list without breaking the link between that list and the server-side list.

Preferably, the server list is held in an array with the tag of each item in the list also acting as its index to the array.

When a client wants to open a file, a new open file method is provided by the file server. Instead of being passed a filename or a pathname as a parameter, this new method takes as a parameter the tag for one of the entries in the directory listing.

The file server then uses this tag to find the location information in its array and passes this to the file system. The file can then be opened immediately without having to search the directory again.

This method is clearly advantageous over a system which simply caches directory listings, in which files still have to be opened by name even when a cache hit occurs, incurring the extra search overhead. The multiple string comparisons that this entails, especially on modern systems which use Unicode filenames, are non trivial.

On read-only filesystems (such those for ROM and ROFS disks) the steps already described are sufficient, because the contents of the disks never change. There will therefore be a performance improvement for all cases where files are loaded after searching a directory listing; the filesystem innovations of this invention will always allow files to be opened directly by tag with no searches involved.

In order to extend this innovation to writeable drives, a mechanism to handle changes to a directory list may be included. Such changes can comprise, for example, changes to the length of existing files, file deletion, or the creation of new files.

A number of possible mechanisms for achieving this will now be described.

The most straightforward mechanism is to flag the entire server-side list as being invalid if the directory is changed. In this case, attempts to open a file (or any object) referred to by any entry by means of passing its tag then causes the file server to return an error code to the client, which then reverts to opening the file (or object) by name.

A modified implementation of the above mechanism requires the server-side list to additionally store the filename, as well as the tag and the physical location of the file. In this case, passing a tag to a file on an invalidated list causes the file server, rather than the client as in the above example, to revert to opening the file or object by name, transparently to the client.

An alternative mechanism which avoids the necessity for the storage of the filename in the server-side list is for an additional version of the file open method to be provided which takes both a tag and a filename as parameters. This mechanism may be used with writable filesystems and enables the transparent fallback to opening the file by name by the server described above without the necessity for the storage of filenames in the server-side list.

The fact that there is no need to keep filenames in the server-side list in this implementation is particularly advantageous as far as memory utilisation is concerned. Storage of all names (especially long Unicode names) can be particularly burdensome on memory; as a result, many *nix implementations of DNLC name caches have found it necessary to limit the size of cached names to around 15 characters, which seriously affects the utility of the name caching scheme. Battery operated mobile computing devices in particular are resource constrained, so a method enabling the server list to simply store tags and physical locations even for writable drives is considered highly desirable and beneficial.

Optionally, with either of the two latter mechanisms, the server-side list may be updated automatically at the same time as the reversion to name specified file tag opening by the server.

A set of more complex mechanisms may also be developed by enabling the file server to actively monitor activity that could potentially cause changes to a directory and to dynamically adjust the contents of its list to ensure that it was always valid. For example, the server may be arranged to check whether there is an open file listing on a directory before making a change and either invalidate a single entry in the server side array, or ideally update it with new information.

Where a single entry is invalidated, either an error code may be returned to the client, or if the server list included file names as described above, the server could automatically fall back on opening the file by name; optionally, the server-side list entry could be updated and revalidated at the same time.

The application of the invention to ROM/ROFS drives is most significant, as it directly improves device boot time. The simplicity of this form of the invention means that there is no significant run-time overhead beyond the initial generation and storage of the server-side list; and because this overhead involves internal memory on the computing device rather than slow external media, the initial overhead would almost certainly be recouped the first time a new call to open a file by tag is used.

One particular advantage of this invention is that it can be included in most filesystem application programme interfaces (APIs) without breaking compatibility with previous client APIs. The only changes needed will usually be one or more file Open( ) functions which take tags as parameters either in addition to or instead of filenames. However, it is acknowledged that some systems may require modification to use this invention but a method that encapsulates a directory search and a file open as a single operation would in most cases benefit in terms of speed of operation and power consumption were it to be adapted to make use of the invention.

There are a number of ways of deciding how many directory lists the file server should keep, examples of which will now be outlined:

• • A single server-side list may be provided for all file sessions on each logical drive; this is beneficial in situations where a single client is loading up files in a single file session, or where a single directory is being used by all file sessions. However, such situations are in practice likely to occur relatively infrequently, because file servers are used to allow multiple clients to access files without locking each other out.
  • One server-side list per file session may be provided. This potentially uses more memory than the single server-side list, but is still beneficial when multiple sessions are opened with the file server.
  • Multiple server-side lists per file session may also be provided; this may be implemented either via a hardwired number, or by introducing additional methods giving some minimum number of lists to all file sessions but also allowing them to request extra lists up to either a fixed maximum or a dynamic maximum which depends on factors like memory usage and system loading. Note that in this case, where a session could have multiple lists, the server needs to ensure that all the tags used are unique across all lists.
  • A precompiled list of commonly used system directories in the boot ROM may be used which enables a large number of operations to proceed without any directory searches, and is considered to be especially beneficial in terms of faster boot time.

Which of these options is best in any particular circumstance may be determined by profiling a device to discover common usage patterns. Those skilled in this art will both know how to achieve such profiling and will also appreciate that the necessary trade-off in memory usage against speed are dependent on circumstances and cannot be legislated rigidly in advance.

Thus, with the present invention, when reading a directory on a computing device, the file server adds unique tags to the listing when passing the listing to a client application. The file server keeps a list of the unique tags together with the physical addresses of the files to which they correspond. When a client wishes to open a file, it can do so by passing the tag to the file server. This enables the file server to load the file directly without having to undertake a second directory search to discover the physical location of the file from its filename.

The present invention is considered to provide several significant advantages over known file management systems, including

• • avoiding double searching of directories on disk by saving the position information of a file when building the directory list; this means clients can open files immediately from this information without having to search the directory again
  • quicker searching for files to open; the code is shorter and fewer accesses are required to slower persistent storage. This is of particular benefit when searches of the same directory are followed by file loads
  • because fewer accesses are required to less power-efficient persistent storage as well as fewer CPU cycles, improved battery life on mobile computing devices can be achieved, providing benefits in terms of user satisfaction and the environment
  • when applied to read-only filesystems used to boot up devices it results in a shorter time between device switch on and the device becoming operational. This directly improves user experience and utility, especially of portable battery operated devices such as mobile phones, PDAs and digital cameras, which are often switched off to save power but for which quick access to full functionality is considered extremely useful and important
  • optimised speed and power consumption by eliminating unwanted disk accesses and directory searches. In this respect it is superior to caching methods, which can reduce disk accesses but do not eliminate any directory searches
  • in comparison to caching the entire directory, the server-side list makes far fewer demands on memory than does a cache. It consists, as a minimum, of a tag and a physical disk address. Furthermore, in the preferred implementation where the tag can be used as an index to the server-side list held as an array, the retrieval of the physical location of a file is extremely fast; unlike a cache, there is no searching necessary
  • in comparison to caching techniques in general, far lower management overhead is achieved; maintaining and searching a cache is a non-trivial exercise and there is the additional burden whenever there is a cache miss
  • for most operating systems, this invention may be implemented extremely quickly and with very few changes to existing APIs and data structures. There is consequently a high probability that there will be no compatibility breaks with existing software
  • the method is highly generic and can be implemented in the prevailing idioms and patterns used by a variety of operating system APIs and in a wide variety of programming languages
  • because previous methods of opening files work unchanged, there is no need for any existing software applications to change
  • because the new file open methods are simple, very little effort is required by application developers deciding to use the invention.

Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims.

Claims

1. A method of file management in a computing device incorporating a directory structure, the method comprising a. arranging a directory listing of a filesystem to include a uniquely identifiable tag for each entry in the directory;b. when providing the directory listing to a client, retaining a copy of the listing comprising a tag for each entry in the listing indicative of the physical location of an object referred to by that entry;c. accepting a request to open an object by reference to its tag; andd. retrieving the physical location of the said object, and opening the object at its physical location.

2. A method according to claim 1 wherein the filesystem is controlled by a file server for providing filesystem services to multiple clients arranged to maintain one or more distinct sessions with the file server.

3. A method according to claim 1 wherein the objects are selected to comprise files or other directories or any other entities.

4. A method according to claim 1 wherein the tags are maintained in a listing in the form of an array in which the tags act as an index for enabling the physical location of respective objects to be retrieved.

5. A method according to claim 1 wherein the filesystem comprises a read-only filesystem.

6. A method according to claim 5 wherein the read-only filesystem is used to boot the computing device.

7. A method according to claim 1 wherein the filesystem comprises a writable filesystem.

8. A method according to claim 7 wherein the retained listing is invalidated if any change is made to the directory from which it was originally derived; and, passing an error code back to a client requesting to open an object having a tag in an invalidated listing for causing the client to open the object by name.

9. A method according to claim 7 wherein the retained copy of the listing further comprises respective names for objects; the retained list is invalidated if any change is made to the directory from which it is was originally derived; and a request to open an object in an invalidated list causes the object to be opened using the respective name in the retained list.

10. A method according to claim 7 wherein the filesystem is arranged to accept a request for opening an object referred by tag and by object name; the retained listing of tags is invalidated if any change is made to the directory from which it is was originally derived; and a request to open an object by a tag in an invalidated listing causes the filesystem to open the object using the object name.

11. A method according to claim 8 wherein the filesystem is arranged to update and revalidate its retained listing after an invalidated listing has caused an object to be opened by name.

12. A method according to claim 8 in which the filesystem is arranged to monitor activity for causing changes to entries in a directory for which it has a retained directory listing, and in which a tag is invalidated whenever affected by a change instead of invalidating the retained listing, and objects are opened by name only when a request is made using an invalidated tag; or the filesystem is arranged to dynamically update entries which would otherwise have been invalidated.

13. A method according to claim 1 wherein either a. a single retained directory list is allowed for each logical drive on a system; orb. a fixed number of retained directory lists is allowed per file server session; orc. multiple retained directory lists are allowed per file server session by client request, up to a fixed or dynamic maximum.

14. A method according to claim 5 in which read-only filesystem usage is profiled and one or more retained directory listings are predefined and included in a boot ROM for automatic use during the boot process or any other predicable and profitable sequence of operations for the computing device.

15. A computing device arranged to operate in accordance with a method as defined in claim 1.

16. An operating system for a computing device for causing the computing device to operate in accordance with a method as defined in claim 1.