Object-based storage device with improved reliability and fast crash recovery

• US 7,730,213 B2
• Filed: 12/18/2000
• Issued: 06/01/2010
• Est. Priority Date: 12/18/2000
• Status: Active Grant

• Current Assignee: Oracle America, Inc. (Oracle Corporation), United Microelectronics Corporation
• Original Assignee: Oracle America, Inc. (Oracle Corporation)
• Inventors: Howard, John H.
• Primary Examiner(s): Dharia; Rupal D
• Assistant Examiner(s): Duong; Thomas
• Application Number:
  US09/739,618
• Publication Number:
  US 20020078244A1
• Time in Patent Office: 3,452 Days
• Field of Search: 709/212, 709/248
• US Class Current: 709/248
• CPC Class Codes: G06F 16/1865 Transactional file systems

Abstract

An object-based storage may employ a transactional interface and a copy on write protocol. The inode for the file (which is identified by the I-number and indicates one or more blocks storing the file data) may be copied to a working copy of the inode, and the working copy may be updated to indicate the newly allocated blocks. In response to a file commit (e.g. a file close or a file synchronization command), the working copy of the inode may be atomically written to a non-volatile storage. In this manner, the updates performed during the transaction may be atomically committed to the file. The inode itself may be stored in a file (referred to as the inode file), and the storage may perform updates to the inode file atomically as well. The inode file may be modified using the copy on write protocol described above, and the master inode (mapping the blocks of the inode file) may be atomically written to non-volatile storage to atomically update the inode file. In one particular embodiment, the storage employs a journal technique for updates to the inode file.

Claims

1. A storage including a non-volatile computer readable storage medium, the storage comprising:

a non-volatile memory storing a first mode locating a first file in said storage and also storing a journal comprising a list of committed inodes; and

a block manager configured to copy said first mode to a second inode, wherein said block manager is configured to change said second inode in response to updates to said first file, and wherein said block manager is configured to atomically update said first file in response to a commit of said first file by writing said second inode to said non-volatile memory, whereby said second inode locates said first file in said storage, and wherein said block manager is configured to record said second inode in said journal.

2. The storage as recited in claim 1 wherein said commit of said first file comprises a commit command received from an external source which updates said first file.

3. The storage as recited in claim 2 wherein said commit command comprises a file close command.

4. The storage as recited in claim 2 wherein said commit command comprises an fsync command.

5. The storage as recited in claim 1 wherein said journal further includes a checkpoint record including a description of an inode file, a block allocation bitmap, and an inode allocation bitmap.

6. The storage as recited in claim 5 wherein the description comprises inodes for each of said inode file, said block allocation bitmap, and said inode allocation bitmap.

7. An apparatus comprising:

a computing node comprising at least one computer system, the computing node configured to perform one or more write commands to a file and a commit command committing the one or more write commands to said file; and

a storage including a non-volatile computer readable storage medium, the storage coupled to receive said one or more write commands and said commit command, wherein said storage is configured to copy one or more blocks of said file to a copied one or more blocks, said one or more blocks updated by said one or more write commands, and wherein said storage is configured to update said copied one or more blocks with write data corresponding to said one or more write commands, and wherein said storage is configured to copy a first inode locating said file in said storage to a second inode and to update pointers within said second inode pointing to said one or more blocks to point to said copied one or more blocks, and wherein said storage is configured to atomically update said file by writing said second inode responsive to said commit command, and wherein said first inode is stored in an inode file, and wherein said inode file is identified by a master inode, and wherein said inode file is atomically updated with said second inode by writing said master inode subsequent to said commit command.

8. The apparatus as recited in claim 7 wherein said commit command comprises a file close command.

9. The apparatus as recited in claim 7 wherein said commit command comprises an fsync command.

10. A method comprising:

copying a first inode to a second inode, wherein said first inode locates a first file in a storage;

modifying said second inode in response to one or more changes to said first file; and

atomically updating said first file by establishing said second inode as the inode for said first file, wherein said establishing comprises storing said second inode in a journal stored in a nonvolatile memory.

11. The method as recited in claim 10 further comprising writing a master inode corresponding to an inode file including said second inode to a checkpoint record in said journal.

12. The method as recited in claim 11 wherein recovering from a system failure comprises:

scanning said journal to locate a most recent checkpoint record and zero or more inodes subsequent to said most recent checkpoint record within said journal;

copying said master inode from said most recent checkpoint record to a volatile memory; and

updating an inode file corresponding to said master inode with said one or more inodes subsequent to said most recent checkpoint record.

13. The method as recited in claim 12 wherein said updating said inode file comprises:

copying one or more blocks of said inode file storing said one or more inodes to a copied one or more blocks; and

updating said master inode in said volatile memory to point to said copied one or more blocks.

14. The method as recited in claim 10 wherein said block map further comprises a first inode allocation bitmap indicating which inodes within said first inode file are allocated to files, the method further comprising:

copying said first inode allocation bitmap to a second inode allocation bitmap;

modifying said second inode allocation bitmap to reflect one or more inodes allocated to new files; and

establishing a third inode within said block map to said second inode allocation bitmap subsequent to said modifying said second inode bitmap.

15. The method as recited in claim 14 wherein said block map further comprises a first block allocation bitmap indicating which blocks within a storage including said block map are allocated to files, the method further comprising:

copying said first block allocation bitmap to a second block allocation bitmap;

modifying said second block allocation bitmap to reflect one or more blocks allocated to files; and

establishing a fourth inode within said block map to said second block allocation bitmap subsequent to said modifying said second block allocation bitmap.

16. The method as recited in claim 10 wherein said establishing said second inode is performed in response to a commit command.

17. The method as recited in claim 16 wherein said commit command is a close file command.

18. The method as recited in claim 16 wherein said commit command is an fsync command.

19. A storage including a non-volatile computer readable storage medium, the storage comprising:

a non-volatile memory storing a first inode locating a first version of a file in said storage and also storing a journal comprising a list of committed inodes; and

a block manager configured to copy said first inode to a second inode, wherein said block manager is configured to change said second inode in response to updates to the file, and wherein said block manager is configured to atomically update the file, producing a second version of the file, in response to a commit of the file by writing said second inode to said non-volatile memory, wherein said second inode locates said second version of said file in said storage, and wherein said block manager is configured to record said second inode in said journal.

20. The storage as recited in claim 19 wherein said commit of the file comprises a commit command received from an external source which updates the file.

21. The storage as recited in claim 20 wherein said commit command comprises a file close command.

22. The storage as recited in claim 20 wherein said commit command comprises an fsync command.

23. The storage as recited in claim 19 wherein said journal further includes a checkpoint record including a description of an inode file, a block allocation bitmap, and an inode allocation bitmap.

24. The storage as recited in claim 23 wherein the description comprises inodes for each of said inode file, said block allocation bitmap, and said inode allocation bitmap.

25. A method comprising:

copying a first inode to a second inode, wherein said first inode locates a first version of a file in a storage;

modifying said second inode in response to one or more changes to the file, creating a second version of the file; and

atomically updating the file to the second version by establishing said second inode as the inode for the file, wherein said establishing comprises storing said second inode in a journal stored in a nonvolatile memory.

26. The method as recited in claim 25 further comprising writing a master inode corresponding to an inode file including said second inode to a checkpoint record in said journal.

27. The method as recited in claim 26 wherein recovering from a system failure comprises:

scanning said journal to locate a most recent checkpoint record and zero or more inodes subsequent to said most recent checkpoint record within said journal;

copying said master inode from said most recent checkpoint record to a volatile memory; and

updating an inode file corresponding to said master inode with said one or more inodes subsequent to said most recent checkpoint record.

28. The method as recited in claim 27 wherein said updating said inode file comprises:

copying one or more blocks of said inode file storing said one or more inodes to a copied one or more blocks; and

updating said master inode in said volatile memory to point to said copied one or more blocks.

29. The method as recited in claim 25 wherein said block map further comprises a first inode allocation bitmap indicating which inodes within said first inode file are allocated to files, the method further comprising:

copying said first inode allocation bitmap to a second inode allocation bitmap;

modifying said second inode allocation bitmap to reflect one or more inodes allocated to new files; and

establishing a third inode within said block map to said second inode allocation bitmap subsequent to said modifying said second inode bitmap.

30. The method as recited in claim 29 wherein said block map further comprises a first block allocation bitmap indicating which blocks within a storage including said block map are allocated to files, the method further comprising:

copying said first block allocation bitmap to a second block allocation bitmap;

modifying said second block allocation bitmap to reflect one or more blocks allocated to files; and

establishing a fourth inode within said block map to said second block allocation bitmap subsequent to said modifying said second block allocation bitmap.

31. The method as recited in claim 25 wherein said establishing said second inode is performed in response to a commit command.