Browse Prior Art Database

A Virtual FileSystem (VFS) across multiple network nodes and disks

IP.com Disclosure Number: IPCOM000014201D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 46K

Publishing Venue

IBM

Related People

Edd Doutre: AUTHOR [+2]

Abstract

In a network of computers, there is often a need to extend some operating systems' file systems to accommodate file and directory names that are not supported natively. When implementing Java Virtual Machines (JVMs) on file systems that only support "8.3" names (up to 8 characters for the name and up to 3 characters for an extension or type) this becomes very apparent. An trivial example is: "SomeJavaApplication.class", which violates both the 8 character name and the 3 character extension limits. Special characters, DBCS (Double Byte Character Set), UpperCase and LowerCase letters, spaces within names and a host of other limitations can cause problems that limit the usefulness of an otherwise desirable file system. The author has implemented a Virtual File System (VFS) that allows clients to map many names that use these 'problem' characters and can far exceed the length of a file or directory name or total length of a 'path'. The VFS consists of a Name Space Server accessed via TCP/IP sockets (for now) and a run-time VFS Client. In essence the run-time client intercepts names that are allowed to exceed the limits of the native file system and sends them to the Name Space Server to be converted into names that are supported natively. The function of this VFS Name Space Server is analogous to that of a TCP/IP network Domain Name Server (DNS) or bind server which maps IP addresses and node names back and forth. However, the VFS Name Space Server is involved in many simultaneous operations performed by numerous applications and therefore has some severe performance requirements and also does not have the IP name restrictions that limit the total number of usable names. A typical DNS implementation also does not face the dynamic creation and deletion of names and the attendant management problems that entails. Some of these differences are readily apparent when given some examples: A typical DNS would map the IP node name "mymachine.mysubnet.mydomain.net" to an IP address of (for example) 9.67.5.1 and another IP node name with the same "mysubnet.mydomain.net" would only differ in the least significant number (the ".1" might be for instance become ".2"). These restrictions are documented in various Request For Comment documents (commonly known as RFC's) (e.g. RFC 1034/2535) and are tightly controlled because of their impact on IP routers, which depend on these addresses to deliver packets to the correct sub-network.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

A Virtual FileSystem (VFS) across multiple network nodes and disks

       In a network of computers, there is often a need to extend some operating systems' file systems to accommodate file and directory names that are not supported natively. When implementing Java Virtual Machines (JVMs) on file systems that only support "8.3" names (up to 8 characters for the name and up to 3 characters for an extension or type) this becomes very apparent. An trivial example is: "SomeJavaApplication.class", which violates both the 8 character name and the 3 character extension limits. Special characters, DBCS (Double Byte Character Set), UpperCase and LowerCase letters, spaces within names and a host of other limitations can cause problems that limit the usefulness of an otherwise desirable file system.

       The author has implemented a Virtual File System (VFS) that allows clients to map many names that use these 'problem' characters and can far exceed the length of a file or directory name or total length of a 'path'. The VFS consists of a Name Space Server accessed via TCP/IP sockets (for now) and a run-time VFS Client. In essence the run-time client intercepts names that are allowed to exceed the limits of the native file system and sends them to the Name Space Server to be converted into names that are supported natively.

       The function of this VFS Name Space Server is analogous to that of a TCP/IP network Domain Name Server (DNS) or bind server which maps IP addresses and node names back and forth. However, the VFS Name Space Server is involved in many simultaneous operations performed by numerous applications and therefore has some severe performance requirements and also does not have the IP name restrictions that limit the total number of usable names. A typical DNS implementation also does not face the dynamic creation and deletion of names and the attendant management problems that entails.

       Some of these differences are readily apparent when given some examples: A typical DNS would map the IP node name "mymachine.mysubnet.mydomain.net" to an IP address of (for example) 9.67.5.1 and another IP node name with the same "mysubnet.mydomain.net" would only differ in the least significant number (the ".1" might be for instance become ".2"). These restrictions are documented in various Request For Comment documents (commonly known as RFC's) (e.g. RFC 1034/2535) and are tightly controlled because of their impact on IP routers, which depend on these addresses to deliver packets to the correct sub-network.

       In the VFS Name Space Server, Virtual File Names (VFNs) are reusable, in part, as long as different sub- directories make them unique and the Real File Names (RFNs) that they map to can be distinguished in some fashion. In addition, the VFNs can be very long in that they may contain a large number of sub-directories and there is no direct correlation between these intermediate components and the allocation of RFNs. An example is needed. The VFN: "nodename::...