IP Library Granted Patent US 10,521,398
Granted Patent B1
US 10,521,398 · App. 15/197,055 · Granted Dec 31, 2019

Tracking version families in a file system

Inventors: Walter C. Forrester (Berkeley Heights, NJ); Ivan Bassov (Brookline, MA); Michal Marko (Fanwood, NJ); Ahsan Rashid (Edison, NJ)
Assignee: EMC IP Holding Company LLC
G06F16/162G06F16/137G06F16/2329
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,521,398
App. No.
15/197,055
Granted
Dec 31, 2019
Kind
B1
Abstract

A technique for facilitating file system operations in a data storage system provides multiple version family databases. Each version family database identifies members of a respective version family, i.e., a respective set of files in a file system that are related by file snapping. When a snap of a file is created, the file system updates a version family database for the version family that includes the file, such that the version family database identifies both the file and the snap.

Claims (69)

1. A method of facilitating file system operations in a data storage system, the method comprising:

storing a VFDB (version family database) for each of multiple version families in a file system of the data storage system, each VFDB including information pertaining to a respective version family, each version family including a respective set of files in the file system that are related to one another by file snapping; and

upon creation of a snap of a file that belongs to one of the version families, storing an identifier of the snap together with an identifier of the file in a VFDB of the version family to which the file belongs,

wherein storing the VFDB for each version family includes storing a list of identifiers of all files that belong to that version family, wherein storing the VFDB for each of the version families includes (i) storing a first record in the VFDB, the first record including information pertaining to the respective version family as a whole and (ii) storing an additional record in the VFDB for each file that belongs to that version family, and

wherein the method further comprises:

receiving a command to delete a file in the file system;

reading a version family identifier from an inode of the file to be deleted;

looking up a VFDB using the version family identifier;

identifying another file listed in the VFDB; and

transferring reference counts of a set of block pointers of the file to be deleted to reference counts of block pointers of the other file identified in the VFDB.

2. The method of claim 1 , wherein the file system provides an inode for each file in the file system that belongs to a version family, and wherein the method further comprises storing a version family identifier in the inode of each such file, the version family identifier identifying the version family to which the respective file belongs.

3. The method of claim 2 , wherein the method further comprises:

accessing an inode of a file in the file system;

retrieving a version family identifier from the inode of that file; and

locating the VFDB of the version family to which that file belongs based on the version family identifier.

4. The method of claim 3 , wherein each VFDB is stored in a respective file in the file system, and wherein locating the VFDB includes:

generating a file name based on the version family identifier; and

performing a directory lookup for the file name in the file system.

5. The method of claim 1 , wherein storing the VFDB for a version family includes storing a set of counts of blocks allocated to the set of files in that version family, and wherein the method further comprises:

accessing the VFDB to obtain the set of counts; and

generating a family liability value for the version family, the family liability value based at least in part on the set of counts accessed from the VFDB.

6. The method of claim 5 , wherein storing the first record in the VFDB includes storing a count of blocks allocated to all files in the version family, wherein generating the family liability value for the version family is based at least in part on the count of blocks allocated to all files in the version family.

7. The method of claim 1 , further comprising:

receiving a command to move contents of a block from a first location in the file system to a second location in the file system;

identifying an inode of a file in the file system that points to the block;

reading a version family identifier from the inode of the file that points to the block;

looking up a VFDB using the version family identifier; and

for each file identified in the VFDB, (i) testing whether that file points to the block at the first location and, (ii) if it does, redirecting that file to point to the block at the second location.

8. The method of claim 1 , wherein the data storage system includes a first storage processor and a second storage processor, wherein a VFDB for a version family is accessible by both the first storage processor and the second storage processor, and wherein the method further comprises:

providing host access to files of a version family by a set of software objects running on the first storage processor;

upon a failure of the first storage processor, populating the set of software objects on the second storage processor by (i) accessing information about each file in the version family from the VFDB and (ii) providing the accessed information to the set of software objects on the second storage processor; and

providing host access to the files of the version family by the set of software objects running on the second storage processor.

9. The method of claim 1 , further comprising, in response to the data storage system receiving an IO (input/output) request that specifies an allocating write to a file in a version family:

updating at least one counter of allocated blocks in an inode of the file; and

updating at least one counter of allocated blocks in a VFDB of the version family.

10. The method of claim 9 , wherein updating at least one counter of allocated blocks in the VFDB includes:

updating a count of blocks in the first record of the VFDB, the count of blocks in the first record of the VFSB counting blocks allocated to all files in the version family; and

updating a count of blocks in an additional record of the VFDB, the count of blocks in the additional record of the VFSB counting blocks allocated to the file.

11. The method of claim 1 , wherein storing the VFDB for a version family includes storing a set of counts of blocks allocated to the set of files in that version family, and wherein the method further comprises:

accessing the VFDB to obtain the set of counts;

generating a family liability value for the version family, the family liability value based at least in part on the set of counts accessed from the VFDB; and

obtaining insurance to cover the family liability value for the version family from a storage pool.

12. A computer program product including a set of non-transitory, computer-readable media having instructions which, when executed by control circuitry of a data storage system, cause the control circuitry to perform a method for managing storage space in a data storage system, the method comprising:

storing a VFDB (version family database) for each of multiple version families in a file system of the data storage system, each VFDB including information pertaining to a respective version family, each version family including a respective set of files in the file system that are related to one another by file snapping; and

upon creation of a snap of a file that belongs to one of the version families, storing an identifier of the snap together with an identifier of the file in a VFDB of the version family to which the file belongs,

wherein storing the VFDB for each version family includes (i) storing a list of identifiers of all files that belong to that version family, (ii) storing a first record in the VFDB, the first record including information pertaining to the respective version family as a whole and (iii) storing an additional record in the VFDB for each file that belongs to that version family,

wherein the file system provides an inode for each file in the file system that belongs to a version family, wherein the method further comprises storing a version family identifier in the inode of each such file, the version family identifier identifying the version family to which the respective file belongs; and

wherein storing the VFDB for a version family includes storing a set of counts of blocks allocated to the set of files in that version family, and wherein the method further comprises:

accessing the VFDB to obtain the set of counts; and

generating a family liability value for the version family, the family liability value based at least in part on the set of counts accessed from the VFDB.

13. The computer program product of claim 12 , wherein each VFDB is stored in a respective file in the file system, and wherein the method further comprises:

accessing an inode of a file in the file system;

retrieving a version family identifier from the inode of that file; and

locating the VFDB of the version family to which that file belongs based on the version family identifier,

wherein locating the VFDB includes generating a file name based on the version family identifier and performing a directory lookup for the file name in the file system.

14. The computer program product of claim 12 , wherein the method further comprises:

receiving a command to move contents of a block from a first location in the file system to a second location in the file system;

identifying an inode of a file in the file system that points to the block;

reading a version family identifier from the inode of the file that points to the block;

looking up a VFDB using the version family identifier; and

for each file identified in the VFDB, (i) testing whether that file points to the block at the first location and, (ii) if it does, redirecting that file to point to the block at the second location.

15. A computer program product including a set of non-transitory, computer-readable media having instructions which, when executed by control circuitry of a data storage system, cause the control circuitry to perform a method for managing storage space in a data storage system, the method comprising:

storing a VFDB (version family database) for each of multiple version families in a file system of the data storage system, each VFDB including information pertaining to a respective version family, each version family including a respective set of files in the file system that are related to one another by file snapping; and

upon creation of a snap of a file that belongs to one of the version families, storing an identifier of the snap together with an identifier of the file in a VFDB of the version family to which the file belongs,

wherein storing the VFDB for each version family includes (i) storing a list of identifiers of all files that belong to that version family, (ii) storing a first record in the VFDB, the first record including information pertaining to the respective version family as a whole and (iii) storing an additional record in the VFDB for each file that belongs to that version family,

wherein the file system provides an inode for each file in the file system that belongs to a version family, wherein the method further comprises storing a version family identifier in the inode of each such file, the version family identifier identifying the version family to which the respective file belongs; and

wherein the method further comprises, in response to the data storage system receiving an IO (input/output) request that specifies an allocating write to a file in a version family:

updating at least one counter of allocated blocks in an inode of the file; and

updating at least one counter of allocated blocks in a VFDB of the version family.

Assignments (8)
RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (053546/0001) Recorded Jun 23, 2022
From: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT
To: DELL MARKETING L.P. (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO CREDANT TECHNOLOGIES, INC.); DELL INTERNATIONAL L.L.C.; DELL PRODUCTS L.P.; DELL USA L.P.; EMC CORPORATION; DELL MARKETING CORPORATION (SUCCESSOR-IN-INTEREST TO FORCE10 NETWORKS, INC. AND WYSE TECHNOLOGY L.L.C.); EMC IP HOLDING COMPANY LLC
Reel/Frame 071642/0001 →
RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (052216/0758) Recorded Jun 23, 2022
From: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT
To: DELL PRODUCTS L.P.; EMC IP HOLDING COMPANY LLC
Reel/Frame 060438/0680 →
RELEASE OF SECURITY INTEREST AF REEL 052243 FRAME 0773 Recorded Nov 2, 2021
From: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH
To: DELL PRODUCTS L.P.; EMC IP HOLDING COMPANY LLC
Reel/Frame 058001/0152 →
SECURITY AGREEMENT Recorded Apr 22, 2020
From: CREDANT TECHNOLOGIES INC.; DELL INTERNATIONAL L.L.C.; DELL MARKETING L.P.; DELL PRODUCTS L.P.; DELL USA L.P.; EMC CORPORATION; FORCE10 NETWORKS, INC.; WYSE TECHNOLOGY L.L.C.; EMC IP HOLDING COMPANY LLC
To: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.
Reel/Frame 053546/0001 →
SECURITY AGREEMENT Recorded Mar 26, 2020
From: DELL PRODUCTS L.P.; EMC IP HOLDING COMPANY LLC
To: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH
Reel/Frame 052243/0773 →
PATENT SECURITY AGREEMENT (NOTES) Recorded Mar 24, 2020
From: DELL PRODUCTS L.P.; EMC IP HOLDING COMPANY LLC
To: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT
Reel/Frame 052216/0758 →
SECURITY AGREEMENT Recorded Mar 21, 2019
From: CREDANT TECHNOLOGIES, INC.; DELL INTERNATIONAL L.L.C.; DELL MARKETING L.P.; DELL PRODUCTS L.P.; DELL USA L.P.; EMC CORPORATION; FORCE10 NETWORKS, INC.; WYSE TECHNOLOGY L.L.C.; EMC IP HOLDING COMPANY LLC
To: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A.
Reel/Frame 049452/0223 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Feb 3, 2017
From: FORRESTER, WALTER C.; BASSOV, IVAN; MARKO, MICHAL; RASHID, AHSAN
To: EMC IP HOLDING COMPANY LLC
Reel/Frame 041170/0252 →