The file system module offers the file system interface to service applications. It also manages access to data objects and maintains the file security.
3.4.1 File system model
File types and attributes
In Peeraid, user files are represented by File-Objects, which could be either directories or general files. The File-Object of a directory records information about each entry in that directory, including its path name, type (a general file or a sub-directory), permission mode, and file owner and group. Comparing with the contents of directories on UNIX, Peeraid include additional file information and has no index to their Metadata-Objects. This is because files belong to the same directories might be distributed to different nodes. In order to improve the performance of reading directories, Peeraid duplicates some file information that is also stored in Metadata-Objects and puts them into the File-Objects of directories. In addition, Metadata-Objects are stored at the nodes that mapped from File IDs directly so that users can locate them by using the DHT module without any index.
Integrate attributes of a user file are recoded in the corresponding Metadata-Object, which includes the file path name, file ID, file type, permission mode, file size, file owner and group, and time information.
File system interface
Peeraid provides the file system interface listed below to service applications.
For directories:
mkdir: Create a subdirectory in a given directory.
opendir: Open a directory – that is, retrieve the Metadata-Object of the
directory.
readdir: Read entries under a directory – that is, retrieve the File-Object of the directory.
closedir: Close a directory.
rmdir: Remove an empty subdirectory from a directory.
For general files:
create: Create a general file.
open: Open a file – that is, retrieve the Metadata-Object of the file.
read: Read the data contained in a file – that is, retrieve the File-Object of the
file.
write: Write data to a file.
close: Close a file.
unlink: Remove a file from a file system.
getattr: Get the attribute values for a file.
setattr: Set one or more attribute values for a file.
Directory structure
Figure 3-9 shows the directory structure of Peeraid. The top level is root directory, and each user and group has their own home directories on the second level. Users and group members can arbitrarily create new files or subdirectories in their home directories.
File system mounting
Peeraid allows users to mount the file system under any local directory. At least one bootstrap node that has already existed in the system must be specified when mounting file system. It assists the new-coming user in building his own routing table, and notifies other users of the arrival of the entrant.
/
Figure 3-9 Directory structure of Peeraid.
3.4.2 Data object management
There are individual units for managing access to data objects in the file system module: SysInfo unit, metadata unit, and file unit. Users only communicate with their local file units by the file system interface. Whenever they issue a file system operation, the local file unit will accomplish it by cooperating with other units on different nodes and call the functions that the storage module provides if necessary.
A SysInfo-Object is named with the user name or group name it represents, stored at the nodes that mapped from the SysInfo ID, hash of its name, and managed by their SysInfo units. Similarly, a Metadata-Object is named with the file path name it represents, stored at the nodes that mapped from the File ID, hash of its file path name, and managed by their metadata units. Users can locate them efficiently by the DHT module.
File-Objects are stored as erasure-coded shares. Because block is the basic unit when accessing files, Peeraid authenticates each share by naming it with the file
policies that users assign and managed by their file units.
Every node in the system might be unable to access temporarily for some reasons;
even damage to hardware or software could happen. The file system should maintain the number of active backups of any data object to guarantee data availability. Peeraid requests every node to republish SysInfo-Objects and Metadata-Objects stored at them periodically. File-Objects are maintained by file owners. When someone fails to access a file share, he sends a notification to the file owner. The file owner accumulates these notifications and republishes corresponding blocks periodically.
3.4.3 Security
In Peeraid, file security are protected by three mechanisms. First, users must be authenticated when they send requests for retrieving Metadata-Objects. The metadata unit which receives a request will examine the permission mode of the file and retrieves the required information for user authentication from SysInfo-Objects. This protects Metadata-Objects from being accessed by users without appropriate permission. Second, information about locations of file shares in Metadata-Objects is encrypted so that only users who have correct decryption keys can obtain this knowledge. Finally, the contents of File-Objects are also encrypted.
Every user and group has a public/private key pair for authentication and another one for encryption. Authentication public keys are recorded in their SysInfo-Objects and can be accessed by any user.
File permission mode, like UNIX, is divided into three classifications: owner, group, and others. Permission mode determines how to encrypt the Metadata-Object and File-Object, and which key is required for user authentication when accessing the Metadata-Object.
4 Evaluation
This chapter evaluates some primary characteristics of Peeraid, including the difference between erasure coding and replication, and the effects of group locality and network locality on performance.