[Gluster-devel] few queries regarding file snapshot feature in gluster

Vijay Bellur vbellur at redhat.com
Thu Dec 24 15:39:54 UTC 2015

On 12/23/2015 01:17 AM, Prasanna Kumar Kalever wrote:
> On Wednesday, December 23, 2015 5:20:09 AM, Vijay Bellur wrote:
>> On 12/21/2015 06:47 AM, Prasanna Kumar Kalever wrote:
>>> Hi Team,
>>> I have few queries regarding file snapshot feature in gluster
>>> what are the limitations of Block device translator and qemu-block
>>> translator ?
>>> Are we using them some where ?
>>> Do we have plans to improve them ?
>>> Or someone have a design to implement file snapshot feature ?
>> I have not heard much feedback about these two translators. The
>> qemu-block functionality can be handy for exposing virtual block devices
>> and due to features like native snapshotting, it could be quite
>> interesting in use cases that require virtual block devices.
>> The qemu-block translator has not been tested of late. A few months back
>> I tried mkfs.xfs after attaching the block device and it failed. I did
>> not find more time to look into that further.
> XFS does not provide direct support for snapshots, as it expects the
> snapshot process to be implemented by the volume manager. Taking a
> snapshot of an XFS filesystem involves temporarily halting I/O ...
> More @ https://en.wikipedia.org/wiki/XFS#Snapshots

I think we are talking different things here. I mentioned about a 
failure in formatting the attached qemu block device with xfs. xfs not 
providing support for snapshots natively is irrelevant to this part of 
the discussion.

> In my opinion BTRFS and ZFS are the file systems that provide direct
> snapshots but may not be production ready at this state. And we should
> not wait for them.
We have community deployments on zfs and btrfs. If there are 
improvements in gluster that leverage the capabilities of these file 
systems, I think there would be interest in using such features.

>> file snapshotting could be a possibility with dht2 but I don't think
>> much work has happened in that direction.
>> The other possibilities for file snapshotting include reflinks and
>> overlay. Given that reflinks support is most probably going to land
>> sometime in xfs, we might be able to leverage this feature and explore
>> the possibility of providing snapshots with backend filesystems that are
>> reflink capable (btrfs, xfs etc.).
>>> I am really thankful if some one gives more details about qemu-block
>>> xlator,
>>> I don't see enough documentation regarding this :(
>> qemu-block xlator provides the ability to snapshot files by relying on
>> qcow2/qed image formats. what specific details are you looking for?
> I am just investigating, are this features enough from the customer
> perspective. One of the limitation could be file should be in QCOW2 or QED

Yes, that could be one. However for virtual block storage use cases, the 
file format should not be a deterrent.

> My thought is using rsnapshot mechanism for file snapshots in gluster,
> rsnapshot is a utility (stable) that uses rsync in the backend
> http://rsnapshot.org
> Similar utilities: http://www.nongnu.org/rdiff-backup/

Once you have more thoughts on this approach, please feel free to drop a 
rfc here with more details.


More information about the Gluster-devel mailing list