Bağ dağıtılmış dosya sistemi

Abstract

Bu çalışmada, EEEAG-BA?2 projesi kapsamında Motorola VME sistemi üzerinde gerçeklenen BA? gerçek zamanlı dağıtılmış sisteminin bir parçası olarak tasarlanan BA? dağıtılmış dosya sistemi gerçeklenmiştir. BA? dosya sistemi, sistemdeki görevlere (task) gerçek zamanlı, dağıtılmış dosya desteği sağlamaktadır. Dağıtılmış dosya hizmeti, sistemdeki düğümlere yüklenen dosya hizmetlileri ve dosya temsilcileri tararından sağlanır. BA? dağıtılmış dosya sistemi, hiyerarşik ağaç tabanlıdır. Sistemdeki tüm dosya ve kataloglar hiyerarşik ağaç yapısı üzerinde yerleştirilir. Tasarlanan dosya sisteminde, kullanıcılar dosyalara ad üzerinden erişir. Sistemdeki tüm kullanıcılara tek bir global ad uzayı sağlanmaktadır. Buna göre, sistemdeki herhangi bir kullanıcı, ad uzayının herhangi bir noktasındaki dosyaya erişebilir. Kullanıcı, istediği dosyaya, dosyanın fiziksel olarak sistemin neresinde bulunduğunu bilmesine gerek kalmadan, sadece ad vererek erişebildiğinden, saydam erişim kuralı sağlanır. Dosya sistemine dağıtılmışlık özelliği kazandırmak için, görevlere yerleşkeden bağımsız bir adlandırma mekanizması ve temel katalog hizmeti sağlanmıştır. Dosya sistemi, sistemdeki veri saklama ortamlarının dengeli bir şekilde yüklenmelerini hedefler. Dosya sistemi bu sürümünde, dosyaların birden fazla hizmetli üzerinde çoğaltılmasına destek vermemektedir. Dosya sistemi bu sürümünde, dosyaların bir hizmetliden diğerine göç etmesini desteklememektedir.

This study introduces the BAG distributed file system (BDFS), that has been implemented on the BAG real-time distributed system. The BAG real-time distributed system is constructed as the objective of two projects sponsored by Turkish Scientific and Technological Research Council (TÜBİTAK): EEEAG-BAG2 and EEEAG- BAG3. The project BAG2 has the objective of constructing a real-time distributed system in a Motorola VME chassis. The chassis includes a host node and one or more target nodes. These nodes are interconnected by VMEbus. In the scope of this project, the tasks in the system have gained the capability of migrating from one target to another. Also, a distributed file system service has been presented by this work. The project BAG3 aims to provide inter-chassis message communication and system- wide clock synchronization in a distributed system formed by interconnecting multiple VME chassis by one or more LANs (Local Area Network). At the first stage the chassis will be connected by two FDDI (Fiber Distributed Data Interface) rings. The communication and synchronization primitives developed in BAG3 will be used by application and system software developed in BAG2. Therefore, as the two projects come to an end, it is conceived that BDFS will serve as the file system of a distributed system formed by the networking of multiple VME chassis across LANs. BDFS has been constructed in a Motorola VME chassis. The chassis is composed of a host node (MVME 167) and one or more target nodes (MVME 162). The host runs the SYSTEM V/68 operating system. Besides this, it provides the users to develop multitasking real-time applications by using the target nodes. This facility is presented by the VMEexec software package that also runs partly on the host. The VMEexec software package includes real-time kernel software (pSOS+), SYSTEM V/68 Interface Definition Library (SVIDlib), auxiliary programs used to develop target environments, source debugging tools (pROBE+, vmexray), facilities for shared memory, writing device drivers, and communication between target nodes. pSOS+ is the portion of the VMEexec software package and runs on target nodes. It is a real-time kernel software that forms the basis for developing multitasking real time applications. In pSOS+ terminology, the processes are called tasks. pSOS+ presents the following system services to a task running on a target: Task management, queue management, event management, asynchronous signal management, semaphore management, time management and storage management. Vlll Utilizing the task management facilities of pSOS+, the users can create tasks, get the identity of a task, start tasks with a predetermined priority, delete tasks, suspend tasks, resume suspended tasks, restart tasks (forcibly starting), change the priority of a task. Some queue management services provided by pSOS+ include creating a message queue, getting the identity of a queue, sending a message to a queue, receiving a message from a queue, broadcasting a message to a queue. One of the synchronization tools provided by pSOS+ is the event. The synchronization between tasks can be achieved by using the calls that are getting or waiting for events and sending events to a task. Asynchronous signal management presents calls to send an asynchronous signal to a task, and receive and evaluate signals. Signal receiving and evaluating is done by ASRs (Asynchronous Signal Routines). Tasks can share system-wide resources by using semaphores. In order to gain access to a shared resource, a task must wait for a semaphore to be released if another task did get it before, or get the semaphore. After using the resource, the task releases the semaphore. Other semaphore operations are deleting a semaphore, getting the identity of a semaphore. By using time management services, a task can handle cyclical external events, go asleep for a certain time interval, set and get current time and date, send event to another task after a time interval. pSOS+ storage management services provide dynamic allocation of both variable size segments and fixed size buffers. Some of them include creating a memory region, getting the identity of a memory region, deleting a memory region, allocating a segment from a region and returning a segment to a region. BDFS provides distributed file service to both SVIDlib tasks and non-SVDDlib tasks. SVIDlib tasks are almost the same as SYSTEM V/68 processes. They have the capability of carrying out non-distributed file operations. But when an SVIDlib task is migrated from a target to another, its link with the shared SVID server is broken. Thus, SVIDlib tasks also use BDFS. Non-SVK)lib tasks have no capability of issuing file operations. So, these tasks, that are initially capable of doing low-level I/O (Input/Output) operations, have received the capability of doing high-level file operations in a distributed environment. BDFS basically includes three tasks: agent, server and worker. The agent task is loaded and started on every target node of the system. When a client task issues a request message for a file operation, it also envelopes a priority and a time-out value in the message and sends it to the agent task. The agent receives file operation requests from client tasks that are running on the same target as it is and sorts these requests by priority. The message with the highest priority will be served first. In the case when two or more priority values are the same, the message with the lowest value of time-out will be served first. The agent sends the first message at the head of the priority queue to the server it recognizes. If the time-out interval in a IX message expires, it will not be sent to the server but the client task will receive a time out error. BDFS operates on a system structure comprising of host nodes, target nodes with disk devices and diskless targets. On targets that have disk devices, the agent tasks send the request messages to the server task on its nodes. On diskless targets, the agent tasks send the request messages to one of the file servers in the system. The server task is loaded and started on those nodes of the system that have a disk. It receives file request messages, sorts them by priority and time-out, and if the message at the head of the priority queue has not undergone time-out expiration it will be evaluated. If the file mentioned in the message is present on the server, in certain circumstances a new worker task will be created and the request will be served by the worker. Otherwise, the message will be forwarded to another server. In BDFS the server tasks are located in a logical ring. Each member of the logical ring knows the identity of its successor. When a server receives a request for a file, it investigates whether that file is present or not. If the file is not present, the server sends the message to its successor in the ring. The worker task is loaded and started on those nodes of the system that have a disk. It receives file operation requests only from the server task that is resident on its node and carries out the requests on a certain file. When the worker receives a request for file opening, it opens that file and returns a unique file identifier to the client task. For further operations on the same file, the client uses this unique identifier instead of the file name. The unique file identifier is a 32-bit long word in our system. It includes the identity of the file server on which the file resides and the count of the file created on this server. BDFS is based on a global hierarchical tree structure. Every file and directory in the system is placed on this tree. BDFS provides this tree structure to all tasks in the system. Since all the tasks have the same global tree view, a specific file can be shared in a system-wide manner. In order to equally load the disks in the system, it is probable for a portion of files in a directory to reside physically on one server and another portion of the directory to reside on another server. The file system provides distributed file system service with real-time criteria. Therefore, when a task claims to perform an operation on a file, it puts a priority and a time-out value into its request message. The message having the highest priority is served first. In the first version of BDFS the files that are to be shared in a system-wide manner, i.e. by all the tasks in the system, are locked entirely. This means that this first version of BDFS does not support record- or block-based sharing of the files. The users of BDFS access files by means of names. All the users in the system have the same global name space view. This means that any user can access any file in any point of the name space only by giving name and without knowing where the file actually resides. In this way transparent access is implemented. Basic directory services are included in BDFS. BFDS also supports expansion of the system with new disk devices by adding new servers to the system. Although it is controversial to transparency, BDFS provides access to local disk by creating local files. This facility greatly improves system performance and decreases system traffic by limiting some of the accesses to the local disk. Files created on the local disk can only be seen by the resident tasks of the node. BDFS aims to equally load all the disks in the system. This is achieved by giving a storage limit factor to each file server. If a server realizes that it has run off the limit value, it sends the request to its successor in the server ring. This version of BDFS does not support multiple copying of files. For reliability reasons, this is an important facility and it is conceived to append this facility in the next versions. This version of BDFS does not support migration of files. By migrating files from one server to another, maximum storage efficiency can be achieved. It is conceived to append this facility in the next versions. In BDFS all operations on a specific file are performed by the file server. This implies that BDFS does not use caching of files on local nodes. Some distributed file system implementations use this method in order to enhance performance. But in this case, a system-wide cache coherence protocol must be active. Basic file operations provided by BDFS are f_open, f_close, fjputc, f_getc, f_read, fwrite, and fseek. fopen opens a file with the specified mode within the specified time-out period in the given priority. On success this function returns a file pointer for usage in the further file operations on this file. If it fails to open the file it returns an error code including the time-out error. fclose closes a file specified by its file pointer within the specified time-out period in the given priority. On success this function returns 0. If it fails to close the file it returns an error code including the time-out error. fputc writes a character to the file specified by its file pointer and increments the file pointer. On success this function returns the ASCII code of the character. On failure it returns EOF, or -2 in case of time-out. f_getc reads a character from the file specified by its file pointer and increments the file pointer. On success this function returns the ASCII code of the character. On failure it returns EOF, or -2 in case of time-out. f_read copies the specified number of characters from the named input stream into the specified array. On success this function returns the number of items read. On failure it returns 0, or -2 in case of time-out. XI fwrite appends the specified number of characters from the specified character string to the file specified by its file pointer. On success this function returns the number of items written. On failure it returns 0, or -2 in case of time-out. fseek sets the position of the next input or output operation on the file specified by its file pointer. The new position is at the specified signed distance from the beginning, from the current position, or from the end of the file, according to the value of the "pointer name" parameter. fjseek returns non-zero for improper seeks and in case of time-out, otherwise zero. An improper seek can be, for example, an fseek done on a file that has not been opened via fopen. Basic command-line directory operations provided by BDFS are cwd, dir, chdir, md, rd, del, and prn. cwd prints the path name of the current working directory. For each directory argument, dir lists the contents of the directory; for each file argument, dir repeats its name. chdir changes the current working directory to the one given on the command line. md creates the named directory in mode 777. rd removes the named directory if it is empty. del removes the named file. prn lists the contents of the named file.