Electrical computers and digital processing systems: multicomput – Remote data accessing
Reexamination Certificate
1998-03-20
2004-02-24
Coulter, Kenneth R. (Department: 2141)
Electrical computers and digital processing systems: multicomput
Remote data accessing
C709S203000, C709S213000, C709S214000, C709S215000, C709S219000, C709S245000, C711S147000, C707S793000, C707S793000
Reexamination Certificate
active
06697846
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates general to computer file systems. More specifically, the present invention involves a distributed file system based on two technologies: shared storage and file system layering.
BACKGROUND OF THE INVENTION
File Systems
The term “file system” refers to the system designed to provide computer applications with access to data stored on storage devices in a logical, coherent way. File systems generally hide the details of how data is stored on a storage device from the application program. For instance, data on a storage device is generally block accessible, in that data is addressed with the smallest granularity of a block; with multiple blocks forming an extent. The size of the particular block depends upon the actual device involved. Application programs generally request data from file systems byte by byte. Consequently, file systems are responsible for seamlessly mapping between application program memory space and the storage device address space.
Application programs store and retrieve data from files as contiguous, randomly accessible segments of bytes. Users are responsible for organizing data stored in these files, since file systems are generally not concerned with the content of each file. With a byte-addressable address space, users may read and write data at any offset within a file. Users can grow files by writing data to the end of a file. The size of the file increases by the amount of data written. Conversely, users can truncate files by reducing the file size to a particular length.
To maximize storage efficiency, file systems place “holes” in areas within files that contain no data. Holes act as space holders between allocated sections of user data. File systems must manage holes, though no data is allocated to the holes until users write data to the location. When a user reads from a hole, the file system fills the user buffer with zeros.
A hole can either occupy space within an allocated block or occupy space of entire blocks. File systems manage block aligned holes in a manner similar to real-data blocks, yet no blocks are allocated. File systems manage holes internal to allocated blocks simply by zeroing the space of the hole.
In addition, file systems are generally responsible for maintaining a disk cache. Caching is a technique to speed up data requests from application programs by saving frequently accessed data in solid-state memory for quick recall by the file system without having to physically retrieve the data from the storage device. Caching is also useful during file writes; file system may write user data to cache memory and complete the request before the data is actually written disk storage.
Additionally, file systems maintain information indicating which data blocks are available to be allocated to files. File systems modify these free lists during file allocation and de-allocation. Most modern file systems manage free lists by means of bitmap tables. File systems set bits to signify blocks that are allocated to files.
File systems present data to application programs as files—contiguous, randomly accessible segments of bytes. These files, called regular files, are presented to application programs through directory files which form a tree-like hierarchy of files and subdirectories containing more files. The complete directory structure is called the file system name space. Link files are a third type of file used to provide multiple file names per physical file.
File systems are required to map this application level interface to the often non-contiguous data blocks stored on the storage device. Generally, information required to map a particular file or directory to the physical locations of the storage device is stored by the file system in an inode within a data block. Inodes contain information, called attributes, about a particular file, such as file type, ownership information, access permissions and times, and file size. Inodes also contain a list of pointers which address data blocks. These pointers may address single data blocks or address an extent of several consecutive blocks. The addressed data blocks contain either actual data or a list of other pointers. With the information specified by these pointers, the contents of a file can be read or written by an application program. When an application program writes to a file, data blocks may be allocated by the file system. Such allocation modifies the inode.
The terms meta-data and real-data classify file system structure data and user data, respectively. In other words, real-data is data that users store in regular files. Other terms for real-data include user data and file data. File systems create meta-data to store layout information, such as inodes and free block bitmap tables. Meta-data is not directly visible to users. Meta-data requires a fraction of the amount of storage space that real-data occupies and has significant locality of reference. As a result, meta-data caching drastically influences file system performance.
Meta-data consistency is to vital file system integrity. Corruption of meta-data may result in the complete destruction of the file system. Corruption of real-data may have bad consequences to users but will not effect the integrity of the whole file system.
Distributed Files Systems
File systems can generally be divided into two separate types. Local file systems allow computers to access files and data stored on locally attached storage devices. While local files systems have advanced significantly over the years, such file systems have limited usefulness when data needs to be shared between multiple computers. Distributed files systems have been developed in order to make shared data available to multiple computer systems over a computer network. Distributed file systems provide users and applications with transparent access to files and data from any computer connected to the file system. Distributed file system performance cannot equal local file system performance due to resource sharing and lack of data locality.
Traditional distributed file systems are based on client-server architectures. Server computers store shared data on locally attached storage devices, called server-attached devices. Clients send file system requests to server computers via networks. Early distributed file systems, such as Sun Microsystems Network File System (NFS), use a central server to store real and meta-data for the file system. These central servers locally maintain meta-data and transport only real-data to clients. The central server design is simple yet efficient, since all meta-data remains local to the server. Like local file systems, central servers only need to manage meta-data consistency between main memory and storage devices. In fact, central server distributed file systems often use local file systems to manage and store meta-data for the file system. In this regard, the only job of the central server file system is to transport real-data between client and server.
As the need grew for greater parallelism and enhanced availability, distributed file system designs evolved from central servers to multiple server configurations. As with central servers, multiple servers, also known as distributed servers, store all file system data on devices connected to server computers. Since multiple servers cooperatively manage the file system, servers may share meta-data between computers. The complexity of these designs increases an order of magnitude, since distributed system integrity requires strong meta-data consistency between servers. Such systems cannot use local file systems to store data. As a result, server software must manage, store, and transport meta-data between servers. Two examples of distributed server file systems are the Andrew File System from Carnegie Mellon University and the Sprite File System from the University of California at Berkeley.
Distributed server file systems have further evolved into designs where clients and servers are often difficult to distinguish. In these systems, clients ma
Beck & Tysver P.L.L.C.
Coulter Kenneth R.
Dataplow, Inc.
Kang Paul
LandOfFree
Shared file system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Shared file system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Shared file system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3327411