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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
# Release notes for Gluster 3.11.0
This is a major Gluster release that includes some substantial changes. The
features revolve around, improvements to small file workloads, Halo replication
enhancement from Facebook, some usability and performance improvements, among
other bug fixes.
The most notable features and changes are documented on this page. A full list
of bugs that has been addressed is included further below.
## Major changes and features
### Switched to storhaug for ganesha and samba high availability
*Notes for users:*
*Limitations:*
*Known Issues:*
### Added SELinux support for Gluster Volumes
*Notes for users:*
*Limitations:*
*Known Issues:*
### Several memory leaks are fixed in gfapi during graph switches
*Notes for users:*
*Limitations:*
*Known Issues:*
### get-state CLI is enhanced to provide client and brick capacity related information
*Notes for users:*
The get-state CLI output now optionally accommodates client related information
corresponding locally running bricks as obtained from
`gluster volume status <volname>|all clients`. Getting the client details is a
is a relatively more costly operation and these details will only be added to
the output if the get-state command is invoked with the 'detail' option. The
following is the updated usage for the get-state command:
```bash
# gluster get-state [<daemon>] [[odir </path/to/output/dir/>] [file <filename>]] [detail]
```
Other than client details, capacity related information for respective local
bricks as obtained from `gluster volume status <volname>|all detail` has also
been added to the get-state output.
*Limitations:*
Information for non-local bricks and clients connected to non-local bricks
won't be available. This is a known limitation of the get-state command, since
get-state command doesn't provide information on non-local bricks.
*Known Issues:*
### Ability to serve negative lookups from cache has been added
*Notes for users:*
*Limitations:*
*Known Issues:*
### New xlator to help developers detecting resource leaks has been added
*Notes for users:*
*Limitations:*
*Known Issues:*
### Feature for metadata-caching/small file performance is production ready
*Notes for users:*
*Limitations:*
*Known Issues:*
### "Parallel Readdir" feature is production ready
*Notes for users:*
*Limitations:*
*Known Issues:*
### Object versioning is enabled only if bitrot is enabled
*Notes for users:*
*Limitations:*
*Known Issues:*
### Distribute layer provides more robust transactions during directory namespace operations
*Notes for users:*
*Limitations:*
*Known Issues:*
### gfapi extended readdirplus API has been added
*Notes for users:*
An extended readdirplus API `glfs_xreaddirplus` is added to get extra information along
with readdirplus results on demand. This is useful for the applications (like NFS-Ganesha
which needs handles) to retrieve more information along with stat in a single call, thus
improving performance of work-loads involving directory listing.
The API syntax and usage can be found in
[`glfs.h`](https://github.com/gluster/glusterfs/blob/v3.11.0rc1/api/src/glfs.h#L810)
header file.
*Limitations:*
This API currently has support to only return stat and handles (`glfs_object`) for each dirent
of the directory, but can be extended in the future.
*Known Issues:*
None.
### Improved adoption of standard refcounting functions across the code
*Notes for users:*
*Limitations:*
*Known Issues:*
### Performance improvements to rebalance have been made
*Notes for users:*
Both crawling and migration improvement has been done in rebalance.
The crawler is optimized now to split the migration load across replica and ec nodes.
e.g. in case the replicating bricks are distributed over two nodes, then only one node used
to do the migration. With the new optimization both the nodes divide the load among each
other giving boost to migration performance. And also there have been some optimization
to avoid redundant network fops.
File migration now avoids syncop framework and is managed entirely by rebalance threads giving
performance boost.
There is a change to throttle settings in rebalance. Earlier user could set three values to
rebalance which were "lazy", "normal", "aggressive", which was not flexible enough. To overcome
that we have introduced number based throttle settings. User now can set numbers which is indication
of the number of threads rebalance process will work with ultimately translating to the number of
parallel migration.
*Limitations:*
*Known Issues:*
### Halo Replication feature in AFR has been introduced
*Notes for users:*
Halo Geo-replication is a feature which allows Gluster or NFS clients to write
locally to their region (as defined by a latency "halo" or threshold if you
like), and have their writes asynchronously propagate from their origin to the
rest of the cluster. Clients can also write synchronously to the cluster
simply by specifying a halo-latency which is very large (e.g. 10seconds) which
will include all bricks.
To enable halo feature execute the following commands:
```bash
# gluster volume set cluster.halo-enabled yes
```
You may have to set the following following options to change defaults.
`cluster.halo-shd-latency`: The threshold below which self-heal daemons will
consider children (bricks) connected.
`cluster.halo-nfsd-latency`: The threshold below which NFS daemons will consider
children (bricks) connected.
`cluster.halo-latency`: The threshold below which all other clients will
consider children (bricks) connected.
`cluster.halo-min-replicas`: The minimum number of replicas which are to
be enforced regardless of latency specified in the above 3 options.
If the number of children falls below this threshold the next
best (chosen by latency) shall be swapped in.
*Limitations:*
None
*Known Issues:*
None
### FALLOCATE support with EC
Notes for users:
Support for FALLOCATE file operation on EC volume is added with this release.
EC volumes can now support basic FALLOCATE functionality.
*Limitations:*
*Known Issues:*
## Bugs addressed
Bugs addressed since release-3.10 are listed below.
<<TO DO>>
|
