Maintenance of a file version set including read-only and read-write snapshot copies of a production file

• US 7,555,504 B2
• Filed: 09/23/2003
• Issued: 06/30/2009
• Est. Priority Date: 09/23/2003
• Status: Active Grant

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: EMC Corporation (Dell Technologies Inc.)
• Inventors: Zheng, Jiannan, Faibish, Sorin, Jiang, Xiaoye, Mullick, Sachin, Bixby, Peter
• Primary Examiner(s): LeRoux; Etienne P
• Assistant Examiner(s): Pyo; Monica M
• Application Number:
  US10/668,546
• Publication Number:
  US 20050065986A1
• Time in Patent Office: 2,107 Days
• Field of Search: 707/10, 707/203, 707/205, 711/162
• US Class Current: 1/1
• CPC Class Codes: G06F 16/128 Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion use of snapshots for error detection or correction G06F11/14, G06F11/16
• CPC Class Codes: Y10S 707/99953 Recoverability
• CPC Class Codes: Y10S 707/99954 Version management

Abstract

Read-only and read-write snapshot copies of a production file in a Unix-based file system are organized as a version set of file inodes and shared file blocks. Version pointers and branch pointers link the inodes. Initially the production file can have all its blocks preallocated or it can be a sparse file having only an inode and its last data block. A protocol is provided for creating read-only and read-write snapshots, deleting snapshots, restoring the production file with a specified snapshot, refreshing a specified snapshot, and naming the snapshots. Block pointers are marked with a flag indicating whether or not the pointed-to block is owned by the parent inode. A non-owner marking is inherited by all of the block'"'"'s descendants. The block ownership controls the copying of indirect blocks when writing to the production file, and also controls deallocation and passing of blocks when deleting a read-only snapshot.

Claims

1. A file server comprising:

storage containing a file system; and

a processor coupled to the storage for accessing the file system;

wherein the file system includes a production file, read-only snapshot copies of the production file, and at least one read-write snapshot copy of the production file;

wherein the production file and the snapshot copies of the production file are organized as a version set;

the version set including an inode for the production file and an inode for each snapshot copy of the production file, and a set of file blocks including data blocks and indirect blocks that are shared among the production file and the snapshot copies of the production file;

wherein the inodes in the version set include pointer fields, and wherein each pointer field includes a pointer to a block in the version set and a flag indicating whether or not the version of the production file of the inode is an oldest snapshot copy of the production file including an identical version of the block pointed to by the pointer in said each pointer field; and

wherein the file server is programmed to maintain for each block in each read-only snapshot copy of the production file an indication of whether or not said each snapshot copy of the production file is an oldest snapshot copy of the production file including an identical version of said each block by maintaining said flag indicating whether or not the version of the production file of the inode is an oldest snapshot copy of the production file including an identical version of the block pointed to by the pointer in said each pointer field.

2. The file server as claimed in claim 1, wherein each inode of each read-only snapshot copy of the production file is linked to a hierarchy of blocks included in said each read-only snapshot copy of the production file, the inode of said each read-only snapshot copy of the production file includes an indication of whether or not said each read-only snapshot copy of the production file is an oldest read-only snapshot copy of the production file including an identical version of each block that is a child of said each inode in the hierarchy of blocks included in said each read-only snapshot copy of the production file, and when said each read-only snapshot copy of the production file is not an oldest read-only snapshot copy of the production file including an identical version of said each block that is a child of said each inode in the hierarchy the of blocks, then said each read-only snapshot copy of the production file is not an oldest read-only snapshot copy of the production file including an identical version of each descendant of said each block that is a child of said each inode in the hierarchy of the blocks.

3. The file server as claimed in claim 1, which is programmed to delete a read-only snapshot copy of the production file, and when deleting the read-only snapshot copy of the production file, to keep each block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file including an identical version of said each block.

4. The file server as claimed in claim 3, wherein each inode of each read-only snapshot copy of the production file is linked to a hierarchy of blocks included in said each read-only snapshot copy of the production file, and wherein the file server is further programmed to keep all descendants of said each block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file including an identical version of said each block.

5. The file server as claimed in claim 1, which is programmed to delete a read-only snapshot copy of the production file, and when deleting the read-only snapshot copy of the production file, to keep each block for which the read-only snapshot copy of the production file is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next-most recent version of the production file is indicated as not being an oldest snapshot copy of the production file including an identical version of said each block.

6. The file server as claimed in claim 5, which is further programmed, upon deleting the read-only snapshot copy of the production file, to indicate that the next-most recent snapshot copy of the production file has become an oldest snapshot copy of the production file including an identical version of said each block for which the read-only snapshot copy of the production file is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next-most recent snapshot copy of the production file is indicated as not being an oldest snapshot copy of the production file including an identical version of said each block.

7. The file server as claimed in claim 1, which is programmed to delete a read-only snapshot copy of the production file by deallocating each block for which the read-only snapshot copy is indicated as an oldest read-only snapshot copy of the production file including an identical version of said each block and a next most recent read-only snapshot copy of the production file is also indicated as an oldest read-only snapshot copy of the production file including an identical version of a block corresponding to said each block, wherein said each block and the block corresponding to said each block are mapped to the same logical file addresses.

8. A file server comprising:

storage containing a file system; and

a processor coupled to the storage for accessing the file system;

wherein the file system includes a production file, and read-only snapshot copies of the production file;

wherein the production file and the read-only snapshot copies of the production file are organized as a version set;

the version set including an inode for the production file, an inode for each read-only snapshot copy of the production file, and a set of file blocks including data blocks and indirect blocks that are shared among the production file and the read-only snapshot copies of the production file;

wherein the inodes in the version set include pointer fields, and wherein each pointer field includes a pointer to a block in the version set and a flag indicating whether or not the version of the production file of the inode is an oldest snapshot copy of the production file including an identical version of the block pointed to by the pointer in said each pointer field;

wherein the file server is programmed to maintain for each block in each snapshot copy of the production file an indication of whether or not said each snapshot copy of the production file is an oldest snapshot copy of the production file including an identical version of said each block by maintaining said flag indicating whether or not the version of the production file of the inode is an oldest snapshot copy of the production file including an identical version of the block pointed to by the pointer in said each pointer field; and

wherein the file server is programmed to delete a read-only snapshot copy of the production file, and when deleting the read-only snapshot copy of the production file, to keep each block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file including an identical version of said each block.

9. The file server as claimed in claim 8, wherein each inode of each read-only snapshot copy of the production file is linked to a hierarchy of blocks included in said each read-only snapshot copy of the production file, and wherein the file server is further programmed, upon deleting the read-only snapshot copy of the production file, to keep all descendants of said each block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file including an identical version of said each block.

10. The file server as claimed in claim 8, which is further programmed, upon deleting the read-only snapshot copy of the production file, to keep each block for which the read-only snapshot is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next-most recent snapshot copy of the production file is indicated as not being an oldest snapshot copy of the production file including an identical version of said each block.

11. The file server as claimed in claim 10, which is further programmed, upon deleting the read-only snapshot copy of the production file, to indicate that the next-most recent snapshot copy of the production file has become an oldest snapshot copy of the production file including an identical version of said each block for which the read-only snapshot is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next-most recent snapshot copy of the production file is indicated as not being an oldest snapshot copy of the production file including an identical version of said each block.

12. The file server as claimed in claim 8, which is further programmed, upon deleting the read-only snapshot copy of the production file, to deallocate each block for which the read-only snapshot copy is indicated as an oldest snapshot copy of the production file including an identical version of said each block and a next most recent snapshot copy of the production file is also indicated as an oldest snapshot copy of the production file including an identical version of a block corresponding to said each block, wherein said each block and the block corresponding to said each block are mapped to the same logical file addresses.

13. A method of operating a file server;

the file server including storage containing a file system, and the file server also including a processor coupled to the storage for accessing the file system;

the file system including a production file and read-only snapshot copies of the production file;

the production file and the read-only snapshot copies of the production file being organized as a version set;

the version set including an inode for the production file, an inode for each read-only snapshot copy of the production file, and a set of file blocks including data blocks and indirect blocks that are shared among the production file and the read-only snapshot copies of the production file, said method comprising;

maintaining for each block in each snapshot copy of the production file an indication of whether or not said each snapshot copy of the production file is an oldest snapshot copy of the production file including an identical version of said each block; and

deleting a read-only snapshot copy of the production file, wherein the deleting of the read-only snapshot copy of the production file includes keeping each block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file including an identical version of said each block;

wherein the inodes in the version set include pointer fields, and each pointer field includes a pointer to a block in the version set and a flag indicating whether or not the version of the production file of the inode is an oldest snapshot copy of the production file including an identical version of the block pointed to by the pointer in said each pointer field, and wherein the step of maintaining for each block in each snapshot copy of the production file an indication of whether or not said each snapshot copy of the production file is an oldest snapshot copy of the production file including an identical version of said each block includes maintaining said flag to indicate whether or not the version of the production file of the inode is an oldest snapshot copy of the production file including an identical version of the block pointed to by the pointer in said each pointer field.

14. The method as claimed in claim 13, wherein each inode of each read-only snapshot copy of the production file is linked to a hierarchy of blocks included in said each read-only snapshot copy of the production file, and wherein the deleting of the read-only snapshot copy of the production file includes keeping all descendants of said each block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file including an identical version of said each block.

15. The method as claimed in claim 13, wherein the deleting of the read-only snapshot copy of the production file further includes keeping each block for which the read-only snapshot copy of the production file is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next-most recent snapshot copy of the production file is indicated as not being an oldest snapshot copy of the production file including an identical version of said each block.

16. The method as claimed in claim 15, which further includes, upon deleting the read-only snapshot copy of the production file, indicating that the next-most recent snapshot copy of the production file has become an oldest snapshot copy of the production file including an identical version of said each block for which the read-only snapshot copy of the production file is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next-most recent snapshot copy of the production file is indicated as not being an oldest snapshot copy of the production file including an identical version of said each block.

17. The method as claimed in claim 13, wherein the deleting of the read-only snapshot copy of the production file includes deallocating each block for which the read-only snapshot copy of the production file is indicated as being an oldest snapshot copy of the production file including an identical version of said each block and a next most recent snapshot copy of the production file is also indicated as being an oldest snapshot copy of the production file including an identical version of a block corresponding to said each block, wherein said each block and the block corresponding to said each block are mapped to the same logical file addresses.