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

• US 20020078244A1
• Filed: 12/18/2000
• Published: 06/20/2002
• 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.
• Granted Patent: US 7,730,213 B2
• Time in Patent Office: Days
• 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 comprising:

a non-volatile memory storing a first inode corresponding to a first file; 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 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.

2. The storage as recited in claim 1 wherein said non-volatile memory stores a journal comprising a list of committed inodes, and wherein said block manager is configured to record said second inode in said journal.

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

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

5. The storage as recited in claim 3 wherein said commit command comprises an fsync command.

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

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

9. The apparatus as recited in claim 6 wherein said commit command comprises a file close command.

10. The apparatus as recited in claim 6 wherein said commit command comprises an fsync command.

8. An apparatus comprising:

a 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 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 corresponding to said file to a second inode and to update pointers within said second inode corresponding 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.

11. A method comprising:

copying a first inode corresponding to a first file to a second inode;

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.

12. The method as recited in claim 11 wherein said establishing comprises storing said second inode in a journal stored in a nonvolatile memory.

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

14. The method as recited in claim 13 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.

15. The method as recited in claim 14 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.

16. The method as recited in claim 11 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 second inode within said block map to said second inode allocation bitmap subsequent to said modifying said second inode bitmap.

17. The method as recited in claim 16 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 third inode within said block map to said second block allocation bitmap subsequent to said modifying said second block allocation bitmap.

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

19. The method as recited in claim 18 wherein said commit command is a close file command.

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

21. A storage comprising:

a non-volatile memory storing a first inode corresponding to a first version of a file; 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 nonvolatile memory.

22. The storage as recited in claim 21 wherein said non-volatile memory stores a journal comprising a list of committed inodes, and wherein said block manager is configured to record said second inode in said journal.

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

24. The storage as recited in claim 23 wherein said commit command comprises a file close command.

25. The storage as recited in claim 23 wherein said commit command comprises an fsync command.

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

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

29. The method as recited in claim 28 wherein said establishing comprises storing said second inode in a journal stored in a nonvolatile memory.

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

31. The method as recited in claim 30 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.

32. The method as recited in claim 31 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.

33. The method as recited in claim 28 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 second inode within said block map to said second inode allocation bitmap subsequent to said modifying said second inode bitmap.

34. The method as recited in claim 33 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 third inode within said block map to said second block allocation bitmap subsequent to said modifying said second block allocation bitmap.

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

28. A method comprising:

copying a first inode corresponding to a first version of a file to a second inode;

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.