<div dir="ltr"><div><div>hi,<br></div>       Doing file-snapshots is becoming important in the context of providing virtual block in containers so that we can take a snapshot of the block device and switch to different snapshots etc. So there have been some attempts at the design for such solutions. This is a very early look at some of the solutions proposed so far. Please let us know what you think about these and feel free to add any more solutions you may have for this problem.<br><br>Assumptions:<br>
- Snap a single <span class="gmail-il">file</span><br>
- <span class="gmail-il">File</span> is accessed by a single client (VM images, block store for container etc.)<br>As there is a single client that accesses the <span class="gmail-il">file</span>/image, the <span class="gmail-il">file</span> read/write (or other modification FOPs) can act on a version number of the <span class="gmail-il">file</span> (read as a part of lookup say, and communicated to other FOPs as a part of the xdata). <br><br>1) Doing file snapshot using shards: (This is suggested by shyam, tried to keep the text as is)<br>If a block for such a <span class="gmail-il">file</span>
 is written to with a higher version then the brick xlators can perform a
 block copy and then change the new block to the new version, and let 
the older version be as is.<br>
<br>
This means, to snap such a <span class="gmail-il">file</span>, just the first shard needs a higher version # and the client that is operating on this <span class="gmail-il">file</span>
 needs to be updated with this version (mostly the client would be the 
one that is taking the snap, but even other wise). To update the client 
we can leverage the granted lease, by revoking the same, and forcing the
 client to reacquire the lease by visiting the first shard (if we need 
to coordinate the client writes post the snap this maybe sort of a 
must).<br>
<br>
Anyway, bottom line is, a shard does not know a snap is taken, rather 
when a data modification operation is sent to the shard, it then acts on
 preserving the older block.<br>
<br>
This leaves blocks with various versions on disk, and when a older snap 
(version) is deleted, then the corresponding blocks are freed.<br>
<br>
A sparse block for a version never exists in this method, i.e when 
taking a snap, if a shard did not exist, then there is no version for it
 that is preserved, and hence it remains a empty/sparse block etc.<br><br></div><div>Pros: good distribution of the shards across different servers and efficient usage of the space available<br></div><div>Cons: Difficult to give data locality for the applications that may demand it.<br></div><div><br></div>2) Doing a file snapshot using sparse files:<br clear="all"><div><div><div><div><div>This is sort of inspired from granular data self-heal idea we wanted to implement in afr, where we logically represent each block/shard used in the file by a bitmap stored either as an xattr or written to a metafile. So there is no physical division of the file into different shards. When a snapshot is taken, a new sparsefile is created of same size as before, new writes on the file are redirected to this file instead of the original file, thus preserving the old file. When a write is performed on this file, we mark which block is going to be written, copy out this block from older shard, overwrite the buffer and then write to the new version and mark the block as used either in xattr/metafile.<br></div><div><br>Pros: Easier to give data locality for the applications that may demand it.<br><div>Cons: in-efficient usage of the space available, we may end up with uneven usage among different servers in the cluster.<br></div><div><br></div><div>3) Doing filesnapshots by using reflink functionality given by the underlying FS:<br></div><div>When a snapshot request comes, we just do a reflink of the earlier file to the latest version and new writes are redirected to this new version of the file.<br><br></div><div>Pros: Easiest to implement among all the three, easier to give data locality for the applications that may demand it.</div><div>Cons: FS specific, i.e. not going to work on disk Filesystems that don&#39;t support file-snapshots, this too has the same problem as we have in 2) above i.e. in-efficient usage of the space available, we may end up with uneven usage among different servers in the cluster.<br><br></div></div><div>-- <br><div class="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div></div></div></div></div>