summaryrefslogtreecommitdiffstats
path: root/done/GlusterFS 3.5/Exposing Volume Capabilities.md
blob: 0f72fbccaa43c534eccd96292fea190e3af61b72 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
Feature
-------

Provide a capability to:

-   Probe the type (posix or bd) of volume.
-   Provide list of capabilities of a xlator/volume. For example posix
    xlator could support zerofill, BD xlator could support offloaded
    copy, thin provisioning etc

Summary
-------

With multiple storage translators (posix and bd) being supported in
GlusterFS, it becomes necessary to know the volume type so that user can
issue appropriate calls that are relevant only to the a given volume
type. Hence there needs to be a way to expose the type of the storage
translator of the volume to the user.

BD xlator is capable of providing server offloaded file copy,
server/storage offloaded zeroing of a file etc. This capabilities should
be visible to the client/user, so that these features can be exploited.

Owners
------

M. Mohan Kumar  
Bharata B Rao.

Current status
--------------

BD xlator exports capability information through gluster volume info
(and --xml) output. For eg:

*snip of gluster volume info output for a BD based volume*

        Xlator 1: BD
        Capability 1: thin

*snip of gluster volume info --xml output for a BD based volume*

        <xlators>
          <xlator>
            <name>BD</name>
            <capabilities>
              <capability>thin</capability>
            </capabilities>
          </xlator>
        </xlators>

But this capability information should also exposed through some other
means so that a host which is not part of Gluster peer could also avail
this capabilities.

Exposing about type of volume (ie posix or BD) is still in conceptual
state currently and needs discussion.

Detailed Description
--------------------

1.  Type
-  BD translator supports both regular files and block device,
i,e., one can create files on GlusterFS volume backed by BD
translator and this file could end up as regular posix file or a
logical volume (block device) based on the user's choice. User
can do a setxattr on the created file to convert it to a logical
volume.
-  Users of BD backed volume like QEMU would like to know that it
is working with BD type of volume so that it can issue an
additional setxattr call after creating a VM image on GlusterFS
backend. This is necessary to ensure that the created VM image
is backed by LV instead of file.
-  There are different ways to expose this information (BD type of
volume) to user. One way is to export it via a getxattr call.

2.  Capabilities
-  BD xlator supports new features such as server offloaded file
copy, thin provisioned VM images etc (there is a patch posted to
Gerrit to add server offloaded file zeroing in posix xlator).
There is no standard way of exploiting these features from
client side (such as syscall to exploit server offloaded copy).
So these features need to be exported to the client so that they
can be used. BD xlator V2 patch exports these capabilities
information through gluster volume info (and --xml) output. But
if a client is not part of GlusterFS peer it can't run volume
info command to get the list of capabilities of a given
GlusterFS volume. Also GlusterFS block driver in qemu need to
get the capability list so that these features are used.

Benefit to GlusterFS
--------------------

Enables proper consumption of BD xlator and client exploits new features
added in both posix and BD xlator.

### Scope

Nature of proposed change
-------------------------

-   Quickest way to expose volume type to a client can be achieved by
    using getxattr fop. When a client issues getxattr("volume\_type") on
    a root gfid, bd xlator will return 1 implying its BD xlator. But
    posix xlator will return ENODATA and client code can interpret this
    as posix xlator.

-   Also capability list can be returned via getxattr("caps") for root
    gfid.

Implications on manageability
-----------------------------

None.

Implications on presentation layer
----------------------------------

N/A

Implications on persistence layer
---------------------------------

N/A

Implications on 'GlusterFS' backend
-----------------------------------

N/A

Modification to GlusterFS metadata
----------------------------------

N/A

Implications on 'glusterd'
--------------------------

N/A

How To Test
-----------

User Experience
---------------

Dependencies
------------

Documentation
-------------

Status
------

Patch : <http://review.gluster.org/#/c/4809/>

Status : Merged

Comments and Discussion
-----------------------