Hello, Block Device (BD) xlator v2 (http://review.gluster.com/#/c/4809/) is hybrid xlator that handles both posix and block bricks. BD xlator leverages existing posix fops for most of the calls and it sits above the posix xlator. BD xlator overloads setxattr fop to create a Logical Volume (LV) and map it to an existing posix file. Also BD xlator supports non-standard features such as server offloaded file copy, snapshot, creating thin provisioned LV instead of linear LV etc. All these capabilities are listed as part of gluster volume info (and xml) CLI output. But still clients that are not part of peer can't run gluster volume info to get list of capabilities to start exploiting them. Also consumers of libgfapi also need some kind of interface to get these capabilities and volume type. qemu-img command is used to create VM images in KVM environment. qemu-img already supports gluster protocol to create a VM image backed in a GlusterFS volume. GlusterFS block driver in QEMU needs to know type of GlusterFS volume so that it can decide if it should send additional glfs_fsetxattr command to create a LV and map it to the posix file. Without user.glusterfs.bd xattr, LV will not be created and BD xlator is not exploited. There is a need for an interface providing type of Gluster volume and capabilities of it. Client/libgfapi applications can use this interface and start exploiting the features accordingly. IMHO getxattr FOP can be used to inform type and capabilities of volume. ie when getxattr is received for root gfid with xattr names "glusterfs.type" or "glusterfs.caps" type or list of capabilities (in integer format) can be returned. Is there any other better approach to inform the type of volume and capabilities it other than getxattr interface? Note: Wiki page for this feature http://www.gluster.org/community/documentation/index.php/Features/exposing-volume-capabilities
