US 11,740,976 B2
Crash-consistent clone generation in a distributed file system
Chetan Chandrakant Paithane, Bengaluru (IN); Sandip Agarwala, Cupertino, CA (US); Sandeep Kumar, Patna (IN); and Chandramouli Subramanian, Bengaluru (IN)
Assigned to Cisco Technology, Inc., San Jose, CA (US)
Filed by Cisco Technology, Inc., San Jose, CA (US)
Filed on Jul. 15, 2021, as Appl. No. 17/376,562.
Prior Publication US 2023/0018284 A1, Jan. 19, 2023
Int. Cl. G06F 11/14 (2006.01); G06F 16/178 (2019.01); G06F 16/182 (2019.01)
CPC G06F 11/1451 (2013.01) [G06F 16/178 (2019.01); G06F 16/182 (2019.01); G06F 2201/82 (2013.01)] 20 Claims
OG exemplary drawing
 
1. A method for generating a crash-consistent clone of a file associated with a virtual machine, the method comprising:
receiving, at a coordinator node of a distributed file system, a request to generate the crash-consistent clone of the file;
identifying, by the coordinator node, multiple storage nodes of the distributed file system that are storing different portions of data of the file, the multiple storage nodes including at least a first storage node storing a first portion of the data and a second storage node storing a second portion of the data;
sending, by the coordinator node, a first command to the multiple storage nodes, the first command configured to cause each one of the multiple storage nodes to:
quiesce the file,
wherein quiescing the file for the first storage node comprises:
waiting for a first index node (inode) associated with the first storage node to complete a first write operation that was acknowledged prior to receiving the first command, and
marking the first inode as quiesced based at least in part on a determination that the first write operation was completed,
wherein quiescing the file for the second storage node comprises:
waiting for a second inode associated with the second storage node to complete a second write operation that was acknowledged prior to receiving the first command, and
marking the second inode as quiesced based at least in part on a determination that the second write operation was completed; and
subsequent to each one of the multiple storage nodes quiescing the file, clone the different portions of the data to generate the crash-consistent clone of the file;
receiving, at the coordinator node and from the multiple storage nodes, a status associated with generating the crash-consistent clone of the file; and
based at least in part on the status, sending, by the coordinator node, a second command to the multiple storage nodes, the second command configured to cause each one of the multiple storage nodes to unquiesce the file.