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.
Regards,
Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
