Method and apparatus for extending traditional operating...

Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C709S241000

Reexamination Certificate

active

06298390

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the fields of computer operating systems, distributed multi-processing hardware systems, object oriented programming, data caching, file systems, and virtual memory systems. More particularly, the present invention relates to improved techniques for establishing and efficiently extending the functionality of traditional file systems by using a set of dynamically configurable layers.
2. Description of Related Art
Vnode interface as described in “Vnodes: An Architecture for Multiple File System Types in Sun UNIX,” by Steve Kleiman, Summer USENIX 1986, June 1986, is an architecture that allows multiple file system types to co-exist within an operating system (OS). Vnode is an abstraction of a file and is used by the OS to access files in file systems of different types without knowing how the file operations are implemented in those different file systems. Over the years, several flaws of the vnode interface have been discovered. These include flaws such as: (1) a single vnode interface represents the interfaces of several different OS objects, such as files, directories, and devices; and (2) a vnode combines file access with file caching.
Traditional operating systems, such as UNIX® (UNIX is a Registered Trademark of AT&T), provide a vnode interface or a vnode-like file system switch that is used to add new file systems to the OS. Such interfaces, however, are complex and cannot be invoked from remote machines. Moreover, the vnode interface is a cumbersome interface—i.e. it provides all the interfaces that a file system may need and a new file system has to implement all of the interfaces regardless of whether the new file system will provide a complete set of functionality.
FIG. 1
illustrates a prior art vnode
1
with a system call processing unit
3
, a data caching unit
5
and a storage management unit
7
. Storage management unit
7
interfaces with a storage system
9
through a device driver interface
11
.
As described above, one problem with prior art vnode
1
is that it contains an interface that is a “super-set” of several interfaces. Vnode
1
contains functionality for carrying out operation on behalf of system calls, operation call from virtual memory manager to participate in data caching, and functionality to control the storage of data. For example, in Sun Microsystems, Inc., Solaris® 2.4, a vnode would have to implement
42
operations.
Another problem with vnode
1
is that it combines the function of the file access and file caching interfaces. By having these two functions in a single object, it is impossible to implement the occurrences in a distributed system where there are multiple caches for a single file.
In both “Evolving the Vnode Interface,” by David S. H. Rosenthal, USENIX 1990, June 1990 (Rosenthal), and “Stacking Vnodes: A Progress Report,” by Glenn C. Skinner and Thomas K. Wong, Summer USENIX 1993, June 1993 (Skinner), a description is contained to make the vnode interface more extensible. Both Rosenthal and Skinner describe the creation of a stack of vnodes and utilizing frameworks for managing the stack. However, the protocols described by both Rosenthal and Skinner assume that all vnodes in the stack are in the same address space. Neither Rosenthal nor Skinner considers: (1) composing stacks where some of the vnodes would be located in the kernel and other vnodes located in the user space, or (2) distributing vnodes on multiple computer nodes in a distributed system. It is not clear how the frameworks described by Rosenthal and Skinner would support a coherent distributed file system.
In “Extensible File Systems in Spring,” by Yousef A. Khalidi and Michael N. Nelson, SMLI TR-93-18, Sun Microsystems Laboratories, Inc., September 1993 (Khalidi), a flexible framework for extensible file systems is presented which applies to a distributed object oriented operating system. However, the framework provided by Khalidi is incompatible with traditional operating systems such as UNIX and therefore cannot take advantage of existing applications configured for executing in a UNIX environment. Thus, it is considered highly desirable to develop a framework with the same flexibility as in Khalidi which could be applied to traditional operating systems. Such a framework would support inter-operability between the traditional operating systems, such as UNIX, and new operating systems, such as the Spring operating system as described by Khalidi. Thus, it is desirable to enable a vnode-based system to support flexible, extensible file system building that is tailored for a distributed system, without having to re-write or throw away the current investment in the OS code.
SUMMARY
The invention breaks the functionality of a vnode into multiple objects. For compatibility with existing UNIX® (UNIX is a Registered Trademark of AT&T), operating systems(UNIX), the new vnode objects retain some of the characteristics of the prior art vnodes. Implementation of the new objects involve the use of:
(1) an interface definition language (IDL) in the UNIX kernel;
(2) a distributed object framework, including:
(a) a set of proxy vnodes as an interface to the UNIX system interface, wherein each proxy vnode has a specific type and provides access to either a file, directory, device, or some other object;
(b) a set of memcache vnodes as an interface with the UNIX virtual memory (VM) system;
(c) a set of storage vnodes as an interface with the underlying file system, wherein each storage vnode is configured to only handle access to files, directories, devices, and other objects; and,
(3) file paging interfaces that support extension to the file system while providing full coherence of data. The paging interfaces are described using the IDL language.
The three-sets of vnodes of a preferred embodiment—i.e., proxy, memcache and storage—are specialized such that each vnode provides specific functionality and together provide more functionality than the prior art vnode.
A preferred embodiment of the invention allows the different vnodes to be:
(1) contained in the same address space—e.g. the address space of a kernel;
(2) contained in separate address spaces—e.g. some vnodes can be contained in the kernel while others are contained in the user space; or
(3) distributed over several computing nodes in the network.
Thus, the distribution of the vnodes is transparent to both the system executing the vnode code and the system executing the UNIX code and allowing the distribution of the code and processors required for providing the functionality and the physical file systems that combine to create the logical file system over multiple computing nodes. In addition, a preferred embodiment makes it possible for one or more of the vnodes in a preferred embodiment be implemented as objects in a non-UNIX operating system, thereby allowing coherent sharing of file data among systems with both UNIX and non-UNIX operating systems.
Another benefit of the invention is that it allows a vendor of a traditional operating system to provide the extensibility of a file system required by a distributed file system or file stacking protocol in an evolutionary manner. As mentioned above, the new objects of the preferred embodiment retain some of the characteristics of the prior art vnodes for compatibility with the existing UNIX systems. However, it will be possible in the future to completely eliminate the support for prior vnode interfaces and transition toward a more object oriented operating system, either by evolution or replacement of the generic UNIX code. Thus, the file system interfaces can be gradually evolved in the existing operating system into a more state-of-the-art object oriented approach, such as that taken in Spring.
Other objects, features and advantages of the present invention will be apparent from the accompanying drawings, and from the detailed description that follows below.


REFERENCES:
patent: 5412808 (1995-05-01), Bauer
patent: 5463772 (1995-10-01), Thompson et al.
patent: 5689701 (1997-11-01

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Method and apparatus for extending traditional operating... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method and apparatus for extending traditional operating..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for extending traditional operating... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2555119

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.