Patent Application
20060129614
1. Field of the Invention
The present invention relates to a system and method of checking and recovering a consistency of a file system, and more particularly, to a system and method of checking a structural consistency of a file system and effectively managing the file system against failure of a server in a network based distributed file server using an object-based storage device (OSD).
2. Description of the Related Art
Generally, file systems store files and directories in a storage device as their unique structures, and a file system check and recovery (FSCR) routine is a sequence of operations for checking a consistency of a file system after the file system is failed, and performs a recovery routine if the consistency of the file system is broken. Accordingly the FSCR routine must be provided as a necessary function to stably manage a file system when a new structure of a file system is developed. As an example of the FSCR routine, a check disk (chkdsk) utility is provided for a file allocation table (fat) file system, a file system consistency check (fsck) utility is provided for an ext2 file system and an ext3 file system and a scandisk utility is provided for a NT file system.
A FSCR routine must be provided for a distributed file system (DFS). The DFS is configured with a plurality of servers. The FSCR routine for DFS checks a structural consistency of a distributed file system to fine a structural defect and corrects the structural defect to recovery the distributed file system. Especially, a distributed file system on object-based storage device (OSDFS) also requires a FSCR routine. However, the FSCR routine of the DFS has comparatively higher complexity than a FSCR routine of single file system.
The OSDFS is an example of an asymmetric distributed file server having an independent metadata server. The OSDFS includes a metadata server (MDS) for processing metadata (MD); an object based storage device (OSD) for processing all data, and a plurality of file system clients for providing a file service by accessing the MDS and the OSD. In the OSDFS, data of files are distributed and stored in objects of a plurality of OSDs and object ids are stored in an Inode of the MDS with metadata of a corresponding file such as a file name, a size, a property and an ownership. Theoretically, a cross reference between them must not be broken in any cases. However, a structural defect may be temporary occurred when the plurality of servers and storage devices are failed according to system characteristics. Therefore, a FSCR routine must find and correct all of structural defects.
A FSCR routine of the distributed file system on object-based storage device (OSDFS) must be developed by considering following factors.
At first, although a FSCR routine for single file system only checks a structure of a storage device accessed by the single file, a FSCR routine for DFS checks all of storage devices accessed by a plurality of servers. Especially, a structural consistency must be maintained not only data stored in an individual storage device but also between the storage devices. For example, if a structural consistency is broken when a file b of a storage B is stored in a directory a of a storage device A, the FSCR routine must find and recovery that a file b pointed by the directory a is disappeared, or a file b is disappeared from the directory a. Accordingly, objects of the FSCR routine for the DFS are the plurality of servers and storage devices.
Secondly, general techniques for single file system to reduce possibilities of defects and to correct the defects are not applicable to the DFS configured with a plurality of servers connected through a network. These general techniques are a synchronous update technique, a consistency check technique such as a scavenger and a journaling based consistency recover technique. The synchronous update technique is a technique recording data a predetermined order when more than two data are stored in a permanent storing device by considering a relationship between data for helping the scavenger type of the synchronous update technique to properly perform a consistency check when the DFS is failed. The scavenger type of the synchronous update technique is used jointly in combination with the synchronous update technique. The scavenger type of the synchronous update technique is a technique checking a relationship between metadata by reading all of metadata of a file system after the DFS is failed. The fsck of ext2 file system is one of representative scavenger type tool. The journaling based consistency recover technique is generally used in recently developed file systems such as an ext3, an xfs and a jfs. Such a journaling based consistency recover technique recovers a file system based on a logging data recorded in a predetermined location by logging a recently progressed file system computation in the predetermined location.
If the techniques for single file system are applied to the DFS, following problems may occur. At first, if the synchronous update technique is applied to the DFS, a system performance is degraded by excessive synchronization processes between servers. Secondly, tools of the scavenger type of the synchronous update technique are not suitable to DFS having an object to provide a mass storage because the tools of scavenger type of the synchronous update technique search entire file system for performing necessary operations. Therefore, a long time is consumed to search the entire file system. Thirdly, all operations of entire system must be logged to properly perform the journaling based consistency recover technique. Accordingly, it is almost impossible to embody the journaling based consistency recovery technique to the DFS where hundreds or thousands users actively access.
As described above, the FSCR routine for the DFS must be especially designed by considering characteristic factors of the DFS differently from the FSCR routine of the single file system. These considerations of the FSCR routine for the DFS are not limited to the OSDFS. These considerations are common to other file system having an asymmetric distributed file server structure. Systems having the asymmetric distributed file server structure are a PANASAS ActiveScale File System (panasas), Lustre (CLUSTER FILE SYSTEM, Inc), and StorageTank (IBM). Since the PANASAS ActiveScale File system and the Lustre use an object-based storage device, they may have similar routines compared to the present invention. These systems employing the asymmetric file server structure uses different methods to overcome the problems of FSCR routine for DFS. Hereinafter, FSCR routines of theses systems and a FSCR routine of the present invention are compared in a view of an object, a structure and an effect.
The PANASAS Active Scale File System provides not only a forward referencing from an Inode to an object but also a backward referencing from the object to the Inode. The PANASAS Active Scale File System reads each object of OSDs and checks whether a corresponding Inode of MDS properly refers to the read object. However, the PANASAS Active Scale File system uses mass amount of resources to perform such an operation on all of objects in the OSD. If the operation is not clearly performed, there is no way to access these objects through a normal path because of orphan object's characteristics. Accordingly, a space occupied by the orphan object cannot be used anymore.
The orphan object problem can be overcome by using a specially designed protocol between the MDS and the OSD during a file creation, a file deletion and a failure recovery. In case of Lustre, a log file is stored in each of the OSD and the MDS, and a specially defined interface and supplementary information are exchanged between them for tuning each operation in order to trace a recently generated object and a recently deleted Inode. Since the MDS and the OSD are especially developed for the Lustre, it is comparatively easy to add such an interface. However, the protocol used in the Lustre does not support a SCSI/OSD protocol which is recently standardized because the protocol is dedicatedly designed for the Lustre only.
Accordingly, the present invention is directed to a crash recovery system and method for distributed file server using object based storage, which substantially obviates one or more problems due to limitations and disadvantages of the related art.
It is an object of the present invention to provide a crash recovery system and method for a distributed file server using an object-based storage device for checking and recording a consistency of a file system using OSDs employing a SCSI/OSD protocol which is in a standardization progress.
It is another object of the present invention to provide a crash recovery system and method for a distributed file server using an object-based storage device for using all OSD devices employing a standard regardless of a manufacturer of the OSDs.
Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The objectives and other advantages of the invention may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, there is provided a crash recovery system for a distributed file server using an object-based storage device, the crash recovery system including: a client for accessing a file system using an object-based storage device (OSDFS), transmitting a command to an object-based storage device (OSD) and accessing a metadata server (MDS); a network for providing an interface and transferring data between the client, the metadata server and the object-based storage device; an object-based storage device for analyzing the command from the client and performing corresponding operations of the command; and a metadata server for storing and managing metadata controlling a direct access to a predetermined file from the client to the object based storage device in order to provide the metadata to the client, and checking and recovering a consistency of the stored and managed metadata when the OSDFS is malfunctioned.
In another aspect of the present invention, there is provided a crash recovery method in a distributed file server using an object-based storage device having a client, a metadata server (MDS) and an object-based stored device (OSD), which are connected through a network, the crash recovery method including the steps of: a) creating a collection in all of object-based storage devices registered at a metadata server for a crash recovery; b) creating or deleting a file using the created collection; c) performing a consistency recovery operation on each of a metadata server and object-based storage devices using file system crash recovery (FSCR) routines of a metadata server and an object-based storage device when the distributed file server is malfunctioned; d) identifying and recovering an orphan object based on a collection after completing the FSCR routine; and e) identifying a dead reference while reading files and managing the identified dead reference, and identifying a dead reference while reading files and recovering the identified dead reference.
It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. In order to clearly describe the present invention, unnecessary elements are omitted although the elements are existed with a file and a distributed file system. Also, although modules and functions of a distributed file system according to the present invention are embodied as a predetermined hardware, an operating system, a computer language, and a network device, they are basically identical to the present invention. Furthermore, although a performance of a distributed file system is improved by applying the present invention to a predetermined environment, it may be one of various embodiments of the present invention because there is no basic difference in each of modules and functions.
The accompanying drawings, which are included to provide a further understanding of the invention, are incorporated in and constitute a part of this application, illustrate embodiments of the invention and together with the description serve to explain the principle of the invention. In the drawings:
Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
As shown in
The OSDFS 10 has a unique structure different from a conventional network based storage system such as a network file system (NFS), a common internet file system (CIFS) or a network attached storage (NAS). Storage devices such as a hard-disk of the conventional network based storage system are physically connected to a predetermined server providing a network file service. Accordingly, all of clients must access a predetermined server having a target data through a network in order to access the target data stored in the storage device. Such an access mechanism causes a bottle neck problem since all service requests are concentrated to the predetermined server.
Differently from the conventional file system, the OSDFS 10 according to the present embodiment has an asymmetric distributed file server structure where the clients 11 directly communicate with the OSD 13 by using the MDS 12. In order to access target data from the client 11, the clients 11 access to the MDS 12 to obtain metadata of the target data. After obtaining, the clients 11 directly access to the OSD 13 by using an object identification stored in the metadata. The clients 11 does not require to access the MDS 12 after obtaining the metadata, and the client 11 directly read and record data from/to the OSD 13.
The clients 11 are hardware having a unique operating system connected through the network 14, such as a personal computer (PC), a workstation, a personal data assistant (PDA), and a mobile terminal. That is, the clients 11 are hardware having a Microsoft Windows or having a Linux operating system. Accordingly, client software for OSDFS in the clients 11 is software providing a standard file system interface by interoperating with the operating system.
The MDS 12 stores and manages various metadata used in the distributed file system. The MDS 12 includes various modules for processing metadata and storages for storing the metadata. The storage may be file systems ext2, ext3 and xfs, or a DBMS. These metadata storages must include a file system consistency check and recovery (FSCR) routine for recovering the consistency of metadata when the MDS fails.
The OSDs 13 are a plurality of physical storage devices connected through a network 14. The OSD 13 is one of an intelligent storage device which is recently developed. That is, the OSD 13 is an object based data storage device differently from a block based storage device which is a general storage device such as a hard disk for PC or a CD-ROM. The OSD 13 includes an input/output function and a recovery function for managing a plurality of objects in a storage space. Especially, the recovery function of the OSD 13 is a crash recovery method for internal metadata for managing objects. That is, the recovery function of the OSD 13 recovers a consistency of an object storing structure when the OSD 13 is crashed. In order to use the OSD 13, the OSD 13 includes an interface able to input/output objects instead of using an interface such as ATAPI, or SCSI protocol for a block based input/output. That is, the OSD 13 uses a SCSI/OSD protocol developed by expanding a conventional SCSI protocol by a storage network industry association (SNIA). The SCSI protocol manages data transaction not only in an internal system through a SCSI interface but also on an IP network through internet SCSI (iSCSI) interface. Furthermore, the SCSI protocol manages data transaction on a FC based SAN through a FC-SCSI interface device. The OSD 13 according to the present embodiment may use an iSCSI/OSD protocol.
The network 14 may be one of widely known communication networks such as a local area network (LAN), a wide area network (WAN), a storage area network (SAN) and a wireless network. The network 14 is used for communicating between the clients 1, the MDS 12 and the OSD 13.
As shown in
Each of the clients 21 is configured with a file system client module 21A, an iSCSI/OSD initiator module 21B, a remote procedure call (RPC) client 21C. The file system client module 21A provides a file system access interface to access the OSDFS 20 by integrating an operating system of the client's computer device. The iSCSI/OSD initiator module 21B manages input/output for enabling the client to directly access the OSD 24. The iSCSI module generates an iSCSI/OSD command through an IP network and transmits the generated command to the OSD. The RPC client 21C provides an interface enabling the client to access the MDS 22.
The MDS 22 includes an OSD managing module 22A, a storage managing module 22B, a crash recovery module 22C, a RPC server module 22D, an iSCSI/OSD initiator module 22E, and an ext3fs 22F.
The OSD managing module 22A manages a plurality of OSDs for recording file data. The file data may be stored by using single object in the OSDs or may be stored through a plurality of objects in a plurality of OSDs. Accordingly, the OSD managing module 22A provides a registering OSD function, a releasing OSD function, a resource state monitoring function and a load balancing function which are used to stored file data on single object or a plurality of objects. The OSD resource state monitoring function regularly monitors and manages operating states and resource usabilities of all registered OSDs. Information obtained by the OSD resource state monitoring function is used for an OSD load balancing function and a failed OSD discarding function. The OSD load balancing function is a function selecting an OSD having less load and sufficient resources among the OSDs when a file creation is requested. The OSD load balancing function distributes excessive load on single OSD to a plurality of the OSDs, which is caused by concentrating inputs/outputs to single OSD or using resources in single OSD. The failed OSD discarding function is a function automatically discarding a defected OSD among OSDs to be selected when a client request to create a new file. The failed OSD discarding function prevents malfunctioning of entire system although one of OSDs is failed.
The storage managing module 22B is a module for storing and managing all metadata used in the distributed file system, and provides functions for storing, modifying, searching, and deleting metadata such as fileset, namespace and inode. The fileset is a metadata for managing virtual single logic volume configured with a plurality of OSDs. The client creates one or more logical filesets and the created logical filesets may be mounted or unmounted (mount/umount) at the client to use the created filesets. The namespace is a metadata managing tree structure configured with all of directory names and file names in the fileset. The client must search a namespace belong to a target file to access the target file in a predetermined directory of a fileset. The mode is a metadata expressing properties of directories and files in namespace. The major properties to be managed are a logical size, an ownership, and an access right. It manages OSDs storing data of these files and identifications of each object.
Furthermore, the storage managing module 22B manages how to select objects for a corresponding OSD and how they are arranged. The storage managing module 22B may arrange objects to providing various levels of RAID function such as a stripping, a mirroring and a parity. According to the embodiments, priorities may be set based on files or directories. In this case, the number of used object-storages, each of object-identifications, information of RAID levels must be included in Inode. On contrary, a same RAID level and identical object-based storage devices may be used for files and directories in a same file set. Each of object-identifications must be included in the Inode.
The crash recovery module 22C provides a function recovering a file system consistency when the MDS or the OSD are failed. The crash recovery module 22C may be manually performed by a manager. Also, the crash recovery module 22C may be automatically performed when a system monitoring software detects a failure of the MDS or the OSD, or regularly and automatically performed within a predetermined period. The crash recovery module 22C may be embodied to interrupt access of all clients or allow access of all clients for improving a file system usability. The crash recovery module will be described in detail with reference to FIGS. 7 to 12.
The iSCSI mode 22E provides an interface to access OSDs connected to each manager of the MDS. The iSCSI mode generates iSCSI/OSD commands and transmits the generated iSCSI/OSD commands through an IP network.
The RPC server module 22D receives a request of accessing the MDS from the client and transfers the request to the managing modules. Also, the RPC server module 22D returns a result of processing the request to the client.
The ext3fs 22F is a file system storing all metadata managed by the MDS 22. A journaling based ext3 file system is used for the ext3f 22F.
The OSD 22 includes an OST 24A and an ext3fs 24B. The object storage target (OST) 24A receives a SCSI/OSD command from an iSCSI/OSD initiator module of the MDS and the client, and analyzes and processes the received SCSI/OSD command. The OST 24A uses the ext3fs 24B file system performing a journaling for object input/output.
The gigabit Ethernet switch 26 is a network for transferring the iSCSI/OSD commands and the RPC request from the clients to the MDS or the OSD.
Referring to
All objects in the OSD are uniquely identified in the entire system by using a number of an object-based storage device, a number of object partition in the object, and a number of the object. For an example of the object identification, the number of OSD, partition and object may be assigned as OSD=3, Partition=0, and OBJ=30213.
All objects 33 in the OSD provide a data area configured with bytes having variable length. Differently from a block based storage device, the OSD does not provide a block unit input/output interface. Objects in the OSD may be generated or deleted when it is required, and read and write computations are provided for a predetermined location within a predetermined range as a unit of byte in the object. The block based storage device may be used internally according to an embodiment of the OSD. However, the block based storage device used by only an object processor in the OSD, and the block based storage device cannot be access from an external device.
All objects in the OSD may have attributes. The OSD according to the present embodiment supports basic attributes basically provided from the OSD and extended attributes defined and used at application software. The basic attributes may be a generation time of an object, an accessing time, a modifying time, a collection belonging to an object, a size of an object data area. It is similar function of Posix extended attributes. The extended attributes are used for a backward reference to determine what file is allocated to a predetermined object in the OSDFS.
The OSD may manage similar objects by grouping the similar objects as a set through a collection 34 beside of the three-state hierarchical structure. The collection 34 is used for grouping the objects 33 in the partition 32, and one of the objects 33 may be freely included in more than one of collections 34. As an example of the object included in more than one of collections, an object335 is shown in
Referring to
The CREAT 41 is a function for generating a new object. The CREAT_COLLETION 42 is a function for creating a new collection. The CREATE_PARTITION 43 a function for creating a new partition. The FLUSH_OBJECT 44 a function for recording a modified object in a permanent storage device. The GET_ATTRIBUTES 45 is a function for obtaining predetermined attributes of an object. The LIST 46 is a function for obtaining all of partition identifications in an OSD or obtaining all of object identifications in a predetermined partition. The LIST_COLLECTION 47 is a function for obtaining all collection identifications in an OSD or obtaining all object identifications in a predetermined collection. The READ 48 is a function reading data in a predetermined area in a predetermined object. The REMOVE 49 is a function for deleting a predetermined object. The REMOVE_COLLECTION 4A is a function for deleting a predetermined collection. The REMOVE_PARTITION 4B is function for deleting a predetermined partition. The SET_ATTRIBUTES 4C is a function for setting predetermined attributes to a predetermined object. The WRITE 4D is a function for recording data on a predetermined area of a predetermined object.
Referring to
All of cross references in the OSDFS is configured with a cross reference for a namespace and a cross reference between file metadata and objects as shown in
Referring to
Under the request processing model shown in
1) File Generation: The file generation requires two steps of operations. A client generates objects in a space for storing data of corresponding files in an OSD, and then records identifications of the generated objects in an Inode of MDS. The orphan object is generated when a system is malfunctioned before recording the identification in the MDS. The reference error is generated when the OSD is malfunctioned with the generated object remained in a buffer after recording the identification of the generated object of the ODS in the Inode of the MDS.
2) File Deletion: The file deletion requires two steps of operations. Object of the OSD corresponding to a target file to be deleted is deleted at first, and then identifications of the deleted objects are deleted from the Inode of the MDS. The orphan object is generated when the OSD is malfunctioned before reflecting the object deletion of the OSD to a storage. The reference error is generated when the MDS is malfunctioned before reflecting the modification of the MDS to the storage.
If the cross reference error occurs as described above, a FSCR routine is performed for recovery the system to a stable state. In order to perform the FSCR routine in a real distributed file system, the entire file system must be checked in an allowable time. If the entire file system is checked by reading objects in a manner of one by one for the FSCR routine, it is very ineffective. Especially, a time for performing FSCR increases in proportional to a size of a file system. Accordingly, the FSCR routine is designed based on a method limiting a time for performing the FSCR routine in a predetermined time range.
The FSCR routine is mainly performed in a server side such as a MDS and an OSD. Also, the FSCR routine can be completely performed without participating of the client. Hundreds or thousands clients may access the OSDFS and the OSDFS may be an unstable since it cannot predict when the OSDFS is malfunctioned. After the OSDFS is malfunctioned, the client may be unable to participate to perform the FSCR routine or the client may not want to perform the FSCR routine. Therefore, the FSCR routine must be performed without participating of the clients for recovering the OSDFS from the crash. The FSCR routine according to the present invention is automatically performed without participating of the client. Therefore, the client can normally use the OSDFS by re-establishing a communication network between the servers and performing synchronizing processes after completing the FSCR routine according to the present invention. Clients, who does not participate the FSCR routine, may partially loss a recently modified data. But it can be maximally recovered through a proper synchronizing process.
A recovery method of the MDS and the OSD includes a consistency recovery for own storage managed by each of the MDS and the OSD, and a consistency recovery between the MDS and the OSD.
The crash recovery method of the MDS will be described at first. The MDS uses an existing namespace managing function of a file system. That is, the MDS includes a storage space for storing metadata, and manages an existing file system in the storage space. In order to create a new file in a predetermined directory in the OSDFS, a new file is created in a same directory of the MDS. File systems such as ext2, ext3, ReiserFS, SXFS, and JFS are used for the storage space of the MDS. The namespace managed by the MDS is managed on the file systems, and a consistency of the file system is recovered by the FSCR routine of the corresponding file system. Accordingly, a consistency of the namespace is recovered by performing the FSCR routine of the corresponding file system after the MDS is malfunctioned. That is, the FSCR routine of the corresponding file system does not modify an Inode of each stored file or each stored directory. Also, the FSCR routine of the file system eliminates an orphan file or an orphan direction, which are a file or a directory not referencing a parent direction, and a reference error (dead reference), which is generated when a parent director refers not-existing file or directory. However, a predetermined file system not supporting a transaction such as an ext2 file system may loss a portion of a namespace before the system is malfunctioned. It causes since the file system does not support the transaction, and the file system may not be reflected by a part of file or directory created or deleted before the system is malfunctioned. However, the file system can be used as normal although the above described errors may occur sine the FSCR routine guarantees not to generate wrongful reference from the parent directories. Theses problems can be eliminated by using file systems supporting a transaction such as an ext3, an xfs and a jfs file system as a file system for the metadata.
The crash recovery method of the OSD will be described hereinafter. The OSD may manage objects using an existing file system or may include a dedicated object manager for managing the objects according to an embodiment of real ODS. A recovery method similar to a FSCR routine of a file system is provided when the OSD is malfunctioned by any types of errors. Accordingly, the internal structural consistency of the OSD is recovered by the FSCR routine of the OSD when the OSD is reactivated after the malfunctioning of the OSD.
However, a cross reference between the MDS and the OSD is not recovered by the FSCR routine. That is, the above described FSCR routine is the individual recovery method for each of the MDS and the OSD. Therefore, the cross reference consistency cannot be recovered by the individual recovery methods for the MDS and the OSD. The cross reference consistency is broken by an orphan object problem and a dead reference problem between the MDS and the OSD. The orphan object problem is generated when objects existed in the OSD are not referred by Inodes of the MDS, and the dead reference problem is generated when Inode of the MDS refers un-existing objects in the OSD. The orphan object problem and the dead reference problem cannot be recovered by the individual recovery methods of the MDS and the OSD.
Detecting of the dead reference can be performed on all of Inodes of the MDS at once after re-operating the MDS. But it is very inefficient. It is sufficient to check the dead reference on only corresponding files. When a corresponding Inode is read for accessing a target file, the dead reference is checked for the target file. If the read Inode dose not refer any objects or refer an un-existing object, the recovery routine is performed by allocating a new object of the OSD and storing the identification of the new object in the Inode of the MDS. Accordingly, the OSDFS according to the present embodiment uses the later recovery method for the dead reference.
The recovery method for the orphan object is comparatively complicated. All of objects have an own backward reference pointing Inodes of the MDS referring themselves. In order to perform the recover method for the orphan object, all of objects in the OSD are read in one by one manner and an Inode of the read object is searched based on the backward reference of the read object. After finding the corresponding Inode, the corresponding Inode is check whether the corresponding Inode refers the read object or not. Since all of the objects are read to find the corresponding Inodes, it is very ineffective way to perform the recovery method. Although it is very ineffective, there is no any other way to access orphan objects through a normal path because of characteristics of the orphan objects. Therefore, storage spaces of the OSD occupied by the orphan objects cannot be use anymore if these spaces are not recovered.
The recover method for an orphan object is developed based on a function of a collection among the SCSI/OSD commands. As shown in
Hereinafter, a crash recovery method according to the present embodiment using the SCSI/OSD commands will be described in detail with reference to FIGS. 7 to 12.
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
As described above, the crash recovery system and method for a distributed file server using an object-based storage device according to the present invention includes the FSCR routine according to the present invention using the existing FSCR routines of a file system and the OSD for checking and recovering a consistency of own storage, which are included in the MDS and the OSD. Therefore, there is no need to newly develop related tools. That is, it requires developing of only tools for checking a consistency of a cross reference between the MDS and the OSD, which is not recovered by the existing FSCR routine. Furthermore, the crash recovery system and method according to the present invention can uses any OSD employing a standard.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2004-0105515 | Dec 2004 | KR | national |
| 2005-0047874 | Jun 2005 | KR | national |
