Crash recovery system and method for distributed file server using object based storage

• US 20060129614A1
• Filed: 09/20/2005
• Published: 06/15/2006
• Est. Priority Date: 12/14/2004
• Status: Abandoned Application

• Current Assignee: Electronics and Telecommunications Research Institute
• Original Assignee: Electronics and Telecommunications Research Institute
• Inventors: Kim, Young Chul, Kim, Young Kyun, Kim, Myung Joon, Kim, Hong Yeon, Lee, Mi Young, Jin, Ki Sung
• Application Number:
  US11/231,158
• Publication Number:
  US 20060129614A1
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1435 using file system or storage system metadata
• CPC Class Codes: G06F 11/1448 Management of the data involved in backup or backup restore
• CPC Class Codes: G06F 11/1451 by selection of backup contents
• CPC Class Codes: G06F 11/1464 for networked environments
• CPC Class Codes: G06F 11/1469 Backup restoration techniques

Abstract

A crash recovery system and method for distributed file server using object based storage are provided. The system includes: 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.

Claims

1. A crash recovery system for a distributed file server using an object-based storage device, the crash recovery system comprising:

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.

2. The crash recovery system of claim 1, wherein the client includes:

a client module for providing an file system access interface for accessing a file system using an object-based storage device by being integrated with an own operating system of the client;

an iSCSI/OSD initiator module for controlling an input/output operation to directly access an object-based storage device from the client; and

a RPC client for interfacing to access a metadata from a client.

3. The crash recovery system of claim 1, wherein the object-based storage device uses an ext3fs file system performing a journaling for an object input/output.

4. The crash recovery system of claim 1, wherein the metadata server includes:

an OSD managing module for managing a plurality of object-based storage devices for recording file data;

a storage managing module for storing, modifying, searching and deleting metadata including a fileset, a namespace, and an inode used in a distributed file system, and storing and managing objects by arranging a predetermined object in a predetermined object-based storage device for storing files;

a crash recovering module for allowing or prohibiting an access of a client when performing a crash recovery routine, and recovering a file system consistency of a client, a metadata server and an object-based storage device when the OSDFS is malfunctioned;

an iSCSI module for generating an iSCSI/OSD command through an IP network, and performing an interface for accessing object-based storage devices connected to each of managers of a metadata server through a network;

a RPC server module for receiving a request to access a metadata from a client, transferring the request to a corresponding module and returning a result of processing the request to a client; and

an ext3fs file system for storing all metadata managed by a metadata server.

5. 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 comprising 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.

6. The method of claim 5, wherein the step a) includes the steps of:

a-1) creating an UNSTABLE collection in all of object-based storage devices using a CREATE_COLLECTION command which is a SCSI/OSD command; and

a-2) registering collection identifications created according to the object-based storage devices in an UNSTABLE[ ] array of a metadata server.

7. The method of claim 5, wherein the creating of file in the step b) includes the steps of:

obtaining an identification of UNSTABLE collection in an object-based storage device where a file object is created;

obtaining a new Inode by requesting a file creation to a metadata server;

creating a new object in recommended object-based storage devices using a CREATE command which is a SCSI/OSD command, adopting the created object in an UNSTABLE collection, setting a InodeID as an object attribute for a backward reference, and receiving an identification of the created object;

transferring an identification of the created object to a metadata server by including the identification in an Inode; and

reflecting the Inode transferred to a metadata to a storage, and deleting a corresponding object from an UNSTABLE collection.

8. The crash recovery method of claim 5, wherein the deleting of the file in the step b) includes the steps of:

obtaining an UNSTABLE collection identification of a file object to be deleted from a metadata server;

adopting an object to be deleted to an UNSTABLE collection using a SET_ATTRIBUTE command which is a SCSI/OSD command;

requesting a file deletion to a metadata server;

deleting a corresponding file from a main memory device at a metadata server;

informing completion of deleting a corresponding file to a client; and

reflecting contents of deleted Inode to a metadata storage, and deleting a corresponding object from an object-based storage device using a REMOVE which is a SCSI/OSD command.

9. The crash recovery method of claim 5, wherein the step d) includes the steps of:

reading objects included in an UNSTABLE collection using a LIST_COLLECTION command which is a SCSI/OSD command from all of object-based storage devices;

reading an InodeID attribute stored in the read object using a GET_ATTRIBUTES command which is a SCSI/OSD command;

deleting a corresponding object using a REMOVE which is a SCSI/OSD command when it is unable to find a corresponding Inode;

deleting a corresponding object using a REMOVE which is a SCSI/OSD command when a corresponding Inode does not refer a corresponding object; and

deleting an UNSTABLE collection using a SET_ATTRIBUTES command which is a SCSI/OSD command when a cross reference between a metadata server and an object storage device is confirmed.

10. The crash recovery method of claim 5, wherein the managing of a dead reference in the step e) includes the steps of:

e-1) obtaining an Inode of a file to be read from a metadata server;

e-2) obtaining identifications of objects corresponding to a file area assigned by a user from an object identification list in the read Inode;

e-3) determining a validity of an identification before reading each object;

e-4) transferring a request of reading an object to an object-based storage device using a READ command which is a SCSI/OSD command;

e-5) copying contents of a read object in a user buffer when the requested object is successfully read, and repeatedly performing the steps of e-1) to e-4); and

e-6) considering ‘

0’

as data of a corresponding area when the requested object is unsuccessfully read because an un-existing object is referred.

11. The crash recovery method of claim 5, wherein the recovering in the step e) includes the steps of:

obtaining an Inode of a file to be read from a metadata server;

determining whether a corresponding object is already created in a target recording area through an object identification list in an Inode;

allocating new objects using a CREATE command which is a SCSI/OSD command when there is a space not allocated after determining, setting an InodeID as an object attribute for a backward reference, adopting to an UNSTABLE collection and recording identifications of created objects in an Inode;

transferring a request of recording to an object-based storage device using a WRITE command of a SCSI/OSD command to each object; and

continuously recording a next object when a recording request is successful, and allocating new objects using a CREATE command which is a SCSI/OSD command when a recording request is failed, setting an InodeID as an object attribute for a backward reference, adopting created objects in an UNSTABLE collection, recording identifications of created object in an Inode and requesting a recording of previous object.