1
00:00:05,839 --> 00:00:08,839
so

2
00:00:16,480 --> 00:00:21,119
welcome back to the colonel miniconf i

3
00:00:18,160 --> 00:00:24,320
hope everyone had a good lunch break

4
00:00:21,119 --> 00:00:26,480
um next up we have steven french

5
00:00:24,320 --> 00:00:28,320
who is a principal software engineer at

6
00:00:26,480 --> 00:00:30,080
microsoft azure storage

7
00:00:28,320 --> 00:00:33,280
and the original author and maintainer

8
00:00:30,080 --> 00:00:35,120
of the linux cifs smb3 client and he is

9
00:00:33,280 --> 00:00:37,200
a member of the samba team

10
00:00:35,120 --> 00:00:39,280
um he'll be talking to us today about

11
00:00:37,200 --> 00:00:42,480
the uh implementation of new features

12
00:00:39,280 --> 00:00:44,480
from the smb 3.1.1 protocol please

13
00:00:42,480 --> 00:00:45,760
welcome steve

14
00:00:44,480 --> 00:00:47,440
yes thank you

15
00:00:45,760 --> 00:00:49,760
uh hopefully my volume is okay for you

16
00:00:47,440 --> 00:00:51,360
guys and i'm looking forward to sharing

17
00:00:49,760 --> 00:00:53,360
with you some exciting things it's been

18
00:00:51,360 --> 00:00:55,280
a very interesting year not just because

19
00:00:53,360 --> 00:00:58,399
of all the uh the lockdown but more

20
00:00:55,280 --> 00:01:00,160
importantly because of a lot of progress

21
00:00:58,399 --> 00:01:02,320
in the smb protocol and its

22
00:01:00,160 --> 00:01:05,040
implementations on linux and as a member

23
00:01:02,320 --> 00:01:06,000
of the samba team you know i also um

24
00:01:05,040 --> 00:01:07,439
you know i'm not going to be talking a

25
00:01:06,000 --> 00:01:09,439
lot about samba but i also want to

26
00:01:07,439 --> 00:01:10,799
encourage you guys to keep up on the on

27
00:01:09,439 --> 00:01:14,080
some of the exciting updates there as

28
00:01:10,799 --> 00:01:16,560
well especially given its its history

29
00:01:14,080 --> 00:01:18,960
and its origins on australia

30
00:01:16,560 --> 00:01:20,960
so uh just the normal legal reminder

31
00:01:18,960 --> 00:01:22,799
that although i work for microsoft may

32
00:01:20,960 --> 00:01:24,400
not always be microsoft's opinion here

33
00:01:22,799 --> 00:01:26,960
but i think in general it's been very

34
00:01:24,400 --> 00:01:29,040
interesting working on trying to make

35
00:01:26,960 --> 00:01:31,840
linux the experience of accessing the

36
00:01:29,040 --> 00:01:35,200
smallest devices to the largest devices

37
00:01:31,840 --> 00:01:37,600
fantastic secure fast

38
00:01:35,200 --> 00:01:39,040
i'm the maintainer of the linux kernel

39
00:01:37,600 --> 00:01:40,479
client one of the most active file

40
00:01:39,040 --> 00:01:41,840
systems in linux

41
00:01:40,479 --> 00:01:43,119
and

42
00:01:41,840 --> 00:01:44,640
i'm also a member of the sama team i

43
00:01:43,119 --> 00:01:46,640
wrote something about the original

44
00:01:44,640 --> 00:01:48,799
original net utility with uh jim

45
00:01:46,640 --> 00:01:51,840
mcdonough at susa

46
00:01:48,799 --> 00:01:53,520
and i work for microsoft now

47
00:01:51,840 --> 00:01:56,159
okay so i'm going to talk a little bit

48
00:01:53,520 --> 00:01:59,280
about some general status of linux the

49
00:01:56,159 --> 00:02:01,520
file system generally and then dive into

50
00:01:59,280 --> 00:02:03,840
things relating to smb 311 the new

51
00:02:01,520 --> 00:02:05,360
kernel server okay smbd

52
00:02:03,840 --> 00:02:07,600
uh and then the client improvements and

53
00:02:05,360 --> 00:02:09,039
then what we're expecting with the tools

54
00:02:07,600 --> 00:02:12,560
and with the

55
00:02:09,039 --> 00:02:14,080
what we can look forward to as we um

56
00:02:12,560 --> 00:02:15,360
as we progress

57
00:02:14,080 --> 00:02:17,520
like i said this has been a very

58
00:02:15,360 --> 00:02:20,400
exciting time with lots going on so as

59
00:02:17,520 --> 00:02:25,680
you guys know very recently we released

60
00:02:20,400 --> 00:02:28,000
a turkey linux 516 gobble gobble

61
00:02:25,680 --> 00:02:28,879
um i love lenas of strange names for

62
00:02:28,000 --> 00:02:30,560
things

63
00:02:28,879 --> 00:02:32,480
a year ago we were talking about linux

64
00:02:30,560 --> 00:02:34,480
510 some

65
00:02:32,480 --> 00:02:35,760
thieving octopus

66
00:02:34,480 --> 00:02:37,519
so what's driving a lot of these

67
00:02:35,760 --> 00:02:40,400
discussions as you guys probably know

68
00:02:37,519 --> 00:02:42,239
matthew wilcox and dave howells and

69
00:02:40,400 --> 00:02:43,599
amir and many of the people driving some

70
00:02:42,239 --> 00:02:44,560
of the general activity what are they

71
00:02:43,599 --> 00:02:45,360
looking at

72
00:02:44,560 --> 00:02:47,120
uh

73
00:02:45,360 --> 00:02:48,560
a lot of changes to memory management

74
00:02:47,120 --> 00:02:50,879
yesterday

75
00:02:48,560 --> 00:02:53,280
we just had a big pull request from dave

76
00:02:50,879 --> 00:02:55,680
howells changing the offline caching

77
00:02:53,280 --> 00:02:57,920
infrastructure uh and also some changes

78
00:02:55,680 --> 00:02:59,840
that netfs are coming

79
00:02:57,920 --> 00:03:03,360
um we see changes to containers

80
00:02:59,840 --> 00:03:04,800
especially in the 512 and 513 releases

81
00:03:03,360 --> 00:03:06,560
and then we see a lot of discussion

82
00:03:04,800 --> 00:03:08,239
about quick apparently a large

83
00:03:06,560 --> 00:03:10,159
percentage of the

84
00:03:08,239 --> 00:03:12,560
the internet traffic especially um

85
00:03:10,159 --> 00:03:15,440
google related is over this new

86
00:03:12,560 --> 00:03:18,720
udp-based protocol instead of tcp and

87
00:03:15,440 --> 00:03:20,239
windows now supports for smb windows is

88
00:03:18,720 --> 00:03:22,080
the first

89
00:03:20,239 --> 00:03:23,760
client and server that support this

90
00:03:22,080 --> 00:03:25,440
supports quick and there's a great

91
00:03:23,760 --> 00:03:26,959
presentation if you guys are curious at

92
00:03:25,440 --> 00:03:29,599
the storage developer conference last

93
00:03:26,959 --> 00:03:30,959
year last fall on that

94
00:03:29,599 --> 00:03:34,000
this is very exciting for all kinds of

95
00:03:30,959 --> 00:03:35,760
reasons that we can talk about later but

96
00:03:34,000 --> 00:03:38,239
this is driving a lot of discussion

97
00:03:35,760 --> 00:03:40,400
between the nfs guys the smb guys afs

98
00:03:38,239 --> 00:03:42,480
team others about how we could get this

99
00:03:40,400 --> 00:03:43,760
in kernel

100
00:03:42,480 --> 00:03:45,360
there's a discussion about faster

101
00:03:43,760 --> 00:03:46,799
encryption there are government

102
00:03:45,360 --> 00:03:49,920
requirements for this and obviously a

103
00:03:46,799 --> 00:03:51,519
lot of security paranoia but adding new

104
00:03:49,920 --> 00:03:53,599
security features relating to better

105
00:03:51,519 --> 00:03:56,480
encryption and also just the normal

106
00:03:53,599 --> 00:03:58,159
stuff we have faster network rdma cards

107
00:03:56,480 --> 00:04:00,799
are getting common

108
00:03:58,159 --> 00:04:02,799
nvme it's getting faster

109
00:04:00,799 --> 00:04:04,239
and then we have this whole new async i

110
00:04:02,799 --> 00:04:05,280
o infrastructure in linux i don't know

111
00:04:04,239 --> 00:04:07,920
how many you guys

112
00:04:05,280 --> 00:04:10,640
are kernel geeks following this but iou

113
00:04:07,920 --> 00:04:11,840
ring is the way as matthew wilcox would

114
00:04:10,640 --> 00:04:14,480
say

115
00:04:11,840 --> 00:04:15,439
everything async i o is dead iou ring is

116
00:04:14,480 --> 00:04:18,400
the thing

117
00:04:15,439 --> 00:04:19,680
right aio is not the thing iou ring is

118
00:04:18,400 --> 00:04:22,320
and of course then we have the other

119
00:04:19,680 --> 00:04:25,199
thing i work in azure azure has very

120
00:04:22,320 --> 00:04:26,240
slow vms very fast vms

121
00:04:25,199 --> 00:04:29,040
i

122
00:04:26,240 --> 00:04:30,720
could be mounting to

123
00:04:29,040 --> 00:04:32,560
northern europe i could be mounting to

124
00:04:30,720 --> 00:04:35,040
central us and san antonio i could be

125
00:04:32,560 --> 00:04:36,479
mounting to

126
00:04:35,040 --> 00:04:38,000
data centers

127
00:04:36,479 --> 00:04:40,639
in australia

128
00:04:38,000 --> 00:04:42,639
the latencies are radically different

129
00:04:40,639 --> 00:04:45,120
the speed of the vms can differ a

130
00:04:42,639 --> 00:04:47,280
hundred fold this is a

131
00:04:45,120 --> 00:04:49,280
real game changer for file system

132
00:04:47,280 --> 00:04:51,759
features okay so let's briefly talk

133
00:04:49,280 --> 00:04:53,400
about file system status

134
00:04:51,759 --> 00:04:56,639
off of the year

135
00:04:53,400 --> 00:04:59,199
5936 kernel change sets

136
00:04:56,639 --> 00:05:01,199
similar that seven percent

137
00:04:59,199 --> 00:05:02,479
of the overall kernel changes are file

138
00:05:01,199 --> 00:05:03,919
system related which is pretty

139
00:05:02,479 --> 00:05:06,880
impressive given

140
00:05:03,919 --> 00:05:08,720
um the enormous number of drivers that

141
00:05:06,880 --> 00:05:10,639
uh that occupy the vast majority of it

142
00:05:08,720 --> 00:05:12,880
file systems matter

143
00:05:10,639 --> 00:05:14,960
in linux and the kernel is huge right 21

144
00:05:12,880 --> 00:05:17,520
million lines of code i measured that

145
00:05:14,960 --> 00:05:19,199
yesterday actually

146
00:05:17,520 --> 00:05:20,720
there are over 60 file systems but it's

147
00:05:19,199 --> 00:05:22,840
interesting in linux

148
00:05:20,720 --> 00:05:25,840
a relatively small number

149
00:05:22,840 --> 00:05:27,680
btrfs sifs xfs just a small number of

150
00:05:25,840 --> 00:05:29,759
file systems drive three quarters of the

151
00:05:27,680 --> 00:05:31,360
activity in the file system layer

152
00:05:29,759 --> 00:05:32,720
um

153
00:05:31,360 --> 00:05:34,720
so the stuff i work on is one of the

154
00:05:32,720 --> 00:05:36,080
more active file systems file systems

155
00:05:34,720 --> 00:05:37,919
represent about five percent of source

156
00:05:36,080 --> 00:05:39,600
code about a million lines of code now

157
00:05:37,919 --> 00:05:42,720
to give you some comparison working at

158
00:05:39,600 --> 00:05:44,000
ibm their client was

159
00:05:42,720 --> 00:05:46,240
a hundred

160
00:05:44,000 --> 00:05:47,199
ish thousand lines of code in one file

161
00:05:46,240 --> 00:05:50,080
system

162
00:05:47,199 --> 00:05:50,840
these file systems are very carefully

163
00:05:50,080 --> 00:05:53,919
uh

164
00:05:50,840 --> 00:05:56,479
optimized the code is stripped and

165
00:05:53,919 --> 00:05:59,120
rewritten frequently so that million

166
00:05:56,479 --> 00:06:01,120
lines of code is very dense and very uh

167
00:05:59,120 --> 00:06:03,600
carefully reviewed very carefully

168
00:06:01,120 --> 00:06:05,280
watched for most file systems

169
00:06:03,600 --> 00:06:08,080
now recently the file system was the

170
00:06:05,280 --> 00:06:09,440
fourth most active 356 change sets

171
00:06:08,080 --> 00:06:10,400
actually might have been third i need to

172
00:06:09,440 --> 00:06:11,680
check that

173
00:06:10,400 --> 00:06:13,120
um

174
00:06:11,680 --> 00:06:14,800
so i've got the numbers on the next

175
00:06:13,120 --> 00:06:17,600
slide we can talk about that

176
00:06:14,800 --> 00:06:19,199
um it's about 60 000 lines of code

177
00:06:17,600 --> 00:06:20,479
it's up significantly in the last year

178
00:06:19,199 --> 00:06:22,240
and that doesn't count the user space

179
00:06:20,479 --> 00:06:24,560
utilities and tools and various samba

180
00:06:22,240 --> 00:06:24,560
things

181
00:06:24,639 --> 00:06:27,680
but the tools have grown a lot as well

182
00:06:26,319 --> 00:06:29,759
and of course the samba tools are

183
00:06:27,680 --> 00:06:31,919
enormous compared with all that

184
00:06:29,759 --> 00:06:33,600
and interestingly the kernel server at

185
00:06:31,919 --> 00:06:35,840
its current pace will also be one of the

186
00:06:33,600 --> 00:06:36,880
most active components it was merged

187
00:06:35,840 --> 00:06:38,400
recently

188
00:06:36,880 --> 00:06:40,319
so let's talk about some overall file

189
00:06:38,400 --> 00:06:42,720
system details before we dive into the

190
00:06:40,319 --> 00:06:44,240
smb world

191
00:06:42,720 --> 00:06:46,400
does anybody know what the most active

192
00:06:44,240 --> 00:06:48,479
file system is

193
00:06:46,400 --> 00:06:51,199
probably should btrfs

194
00:06:48,479 --> 00:06:53,039
and xfs is number two the file system

195
00:06:51,199 --> 00:06:54,960
mapping layer itself though

196
00:06:53,039 --> 00:06:56,960
um has been generating over the last few

197
00:06:54,960 --> 00:06:58,479
years more activity than you might think

198
00:06:56,960 --> 00:07:00,560
it's not just dave howells and matthew

199
00:06:58,479 --> 00:07:02,960
wilcox making changes but there have

200
00:07:00,560 --> 00:07:04,800
been a lot of optimizations uh going

201
00:07:02,960 --> 00:07:05,680
into the mapping layer the vfs layer

202
00:07:04,800 --> 00:07:07,919
itself

203
00:07:05,680 --> 00:07:10,720
1300 change sets since last

204
00:07:07,919 --> 00:07:12,080
since 510 a little over a year ago

205
00:07:10,720 --> 00:07:13,759
um

206
00:07:12,080 --> 00:07:18,960
so

207
00:07:13,759 --> 00:07:18,960
sifs was 356 nfs was 299 change sets

208
00:07:19,120 --> 00:07:22,479
but as you can see the the sets client

209
00:07:21,039 --> 00:07:24,479
is is

210
00:07:22,479 --> 00:07:26,720
the most active of these network uh

211
00:07:24,479 --> 00:07:28,080
cluster file systems and for obvious

212
00:07:26,720 --> 00:07:29,759
reasons if you want to get to your max

213
00:07:28,080 --> 00:07:31,759
if you want to get to azure you want to

214
00:07:29,759 --> 00:07:33,360
get to the cloud if you want to get to a

215
00:07:31,759 --> 00:07:35,199
low end embedded device if you want to

216
00:07:33,360 --> 00:07:36,400
get to windows if you want to get to

217
00:07:35,199 --> 00:07:38,000
samba

218
00:07:36,400 --> 00:07:40,000
now what about servers

219
00:07:38,000 --> 00:07:42,080
now linux

220
00:07:40,000 --> 00:07:44,560
has multiple servers now right we have

221
00:07:42,080 --> 00:07:45,680
three and a half million lines of code

222
00:07:44,560 --> 00:07:48,160
in samba

223
00:07:45,680 --> 00:07:50,000
it's enormous

224
00:07:48,160 --> 00:07:52,879
orders of magnitude almost 100 times

225
00:07:50,000 --> 00:07:55,039
bigger than than the nfs server

226
00:07:52,879 --> 00:07:57,039
but now we have a kernel server

227
00:07:55,039 --> 00:07:58,639
yeah so it's an interesting thing i'll

228
00:07:57,039 --> 00:08:00,160
talk about the kernel server in a minute

229
00:07:58,639 --> 00:08:02,160
and i think that's an exciting thing

230
00:08:00,160 --> 00:08:03,840
that many of you may not uh may not be

231
00:08:02,160 --> 00:08:06,240
aware of or may

232
00:08:03,840 --> 00:08:07,759
uh you know may be curious about but i

233
00:08:06,240 --> 00:08:09,840
also want to remind you guys that

234
00:08:07,759 --> 00:08:12,160
writing file systems isn't easy

235
00:08:09,840 --> 00:08:15,360
a lot of people maybe get buried in

236
00:08:12,160 --> 00:08:17,759
really cool stuff going on in

237
00:08:15,360 --> 00:08:19,759
analytics or in big data

238
00:08:17,759 --> 00:08:21,520
but file systems you know they keep

239
00:08:19,759 --> 00:08:22,960
growing and the amount of data that we

240
00:08:21,520 --> 00:08:24,720
have to deal with is growing but also

241
00:08:22,960 --> 00:08:27,280
the number of syscalls people think

242
00:08:24,720 --> 00:08:30,240
about posix right well posix is a

243
00:08:27,280 --> 00:08:33,279
fraction of the syscalls that

244
00:08:30,240 --> 00:08:35,440
are exported for file system

245
00:08:33,279 --> 00:08:36,800
apis these days just

246
00:08:35,440 --> 00:08:38,240
you know over the last year we've added

247
00:08:36,800 --> 00:08:40,560
these three

248
00:08:38,240 --> 00:08:43,279
right so the number of syscalls keeps

249
00:08:40,560 --> 00:08:45,120
growing file systems have over 200

250
00:08:43,279 --> 00:08:46,080
syscalls

251
00:08:45,120 --> 00:08:48,160
currently

252
00:08:46,080 --> 00:08:50,080
so linux is not posix it's a much bigger

253
00:08:48,160 --> 00:08:52,000
thing and we as file systems always have

254
00:08:50,080 --> 00:08:54,399
to do that so what do i care about i

255
00:08:52,000 --> 00:08:56,800
want smb to be this sort of

256
00:08:54,399 --> 00:08:58,240
lingua franca this this commodity layer

257
00:08:56,800 --> 00:09:00,000
that you can use to access your cluster

258
00:08:58,240 --> 00:09:01,519
file system

259
00:09:00,000 --> 00:09:03,920
running on linux

260
00:09:01,519 --> 00:09:08,480
access the cloud and azure if you want

261
00:09:03,920 --> 00:09:11,200
access your macs access a tiny embedded

262
00:09:08,480 --> 00:09:13,040
device running samba or ksmbd

263
00:09:11,200 --> 00:09:15,600
running some third-party camera you want

264
00:09:13,040 --> 00:09:17,839
to download stuff from

265
00:09:15,600 --> 00:09:19,760
so this is we want it to be the most

266
00:09:17,839 --> 00:09:22,240
secure

267
00:09:19,760 --> 00:09:23,680
general purpose way to get it file data

268
00:09:22,240 --> 00:09:25,440
whether it's local

269
00:09:23,680 --> 00:09:27,360
or whether it's in the cloud

270
00:09:25,440 --> 00:09:29,360
and as linux evolves we need to keep

271
00:09:27,360 --> 00:09:31,440
adding features to kernel client to

272
00:09:29,360 --> 00:09:33,120
samba to ksmbd

273
00:09:31,440 --> 00:09:35,360
and also to the protocol

274
00:09:33,120 --> 00:09:37,680
to take advantage of these

275
00:09:35,360 --> 00:09:38,560
okay so what about servers so i told you

276
00:09:37,680 --> 00:09:40,320
i was going to talk a little bit about

277
00:09:38,560 --> 00:09:42,800
the kernel server but first i want to

278
00:09:40,320 --> 00:09:44,720
mention samba samba has these incredible

279
00:09:42,800 --> 00:09:47,120
australian roots and i'm sure you've

280
00:09:44,720 --> 00:09:48,720
seen andrew trigel and heard

281
00:09:47,120 --> 00:09:51,600
very interesting stories about it it's

282
00:09:48,720 --> 00:09:53,680
huge it's full function uh sombexp is

283
00:09:51,600 --> 00:09:55,680
coming up

284
00:09:53,680 --> 00:09:58,240
in about five months so you know keep

285
00:09:55,680 --> 00:09:59,839
your eye out for that um

286
00:09:58,240 --> 00:10:01,760
but there's now also a kernel server

287
00:09:59,839 --> 00:10:03,920
which can help on some workloads like

288
00:10:01,760 --> 00:10:06,079
rdma smb direct and can be easier to

289
00:10:03,920 --> 00:10:08,240
optimize in some cases

290
00:10:06,079 --> 00:10:09,839
and it's also been incredibly valuable

291
00:10:08,240 --> 00:10:12,560
for me on the client because it's

292
00:10:09,839 --> 00:10:14,160
allowed me to do more testing and more

293
00:10:12,560 --> 00:10:15,920
prototyping of things like the posix

294
00:10:14,160 --> 00:10:17,920
extension changes and also more

295
00:10:15,920 --> 00:10:19,920
debugging quicker

296
00:10:17,920 --> 00:10:21,839
it's been incredibly helpful now there

297
00:10:19,920 --> 00:10:22,959
was a talk last year by nam j at samba

298
00:10:21,839 --> 00:10:24,560
xp

299
00:10:22,959 --> 00:10:27,440
but more recently he's provided me some

300
00:10:24,560 --> 00:10:29,120
slides that i can explain

301
00:10:27,440 --> 00:10:31,120
some of the recent progress for you guys

302
00:10:29,120 --> 00:10:33,920
so i'd like to switch gears briefly and

303
00:10:31,120 --> 00:10:35,360
talk about the kernel server progress so

304
00:10:33,920 --> 00:10:37,839
you guys get a feeling for this kind of

305
00:10:35,360 --> 00:10:39,519
exciting thing that

306
00:10:37,839 --> 00:10:41,680
may be used on everything from very

307
00:10:39,519 --> 00:10:44,959
small embedded devices because it's tiny

308
00:10:41,680 --> 00:10:48,160
footprint compared with alternatives

309
00:10:44,959 --> 00:10:51,519
and also it supports rdma in very fast

310
00:10:48,160 --> 00:10:53,360
um very fast network transports

311
00:10:51,519 --> 00:10:54,800
and also supports multi-channel so there

312
00:10:53,360 --> 00:10:56,560
are certain workloads where it's going

313
00:10:54,800 --> 00:10:58,160
to be incredibly fast and there are

314
00:10:56,560 --> 00:10:59,680
other workloads where its small

315
00:10:58,160 --> 00:11:02,240
footprint will help

316
00:10:59,680 --> 00:11:03,360
but what i like about it is it's easy to

317
00:11:02,240 --> 00:11:04,640
update

318
00:11:03,360 --> 00:11:06,880
and

319
00:11:04,640 --> 00:11:08,720
in some cases it's easier to understand

320
00:11:06,880 --> 00:11:10,480
some is very large

321
00:11:08,720 --> 00:11:13,440
but back to this so it was merged into

322
00:11:10,480 --> 00:11:15,519
the 515 kernel not that long ago right

323
00:11:13,440 --> 00:11:17,040
last three or four months so merged

324
00:11:15,519 --> 00:11:19,279
august 31st

325
00:11:17,040 --> 00:11:21,040
so it sat for five months in linux next

326
00:11:19,279 --> 00:11:22,880
as it got various reviews and most of

327
00:11:21,040 --> 00:11:25,440
these reviews function

328
00:11:22,880 --> 00:11:27,440
focused on functional testing

329
00:11:25,440 --> 00:11:29,360
and some very high profile developers

330
00:11:27,440 --> 00:11:32,560
reviewed it that was thank you very much

331
00:11:29,360 --> 00:11:34,480
um we changed i one thing i i pushed

332
00:11:32,560 --> 00:11:36,320
strongly on was to make sure we try not

333
00:11:34,480 --> 00:11:38,000
to use the word sifs

334
00:11:36,320 --> 00:11:40,160
right because the common internet file

335
00:11:38,000 --> 00:11:42,000
system from the late 90s

336
00:11:40,160 --> 00:11:44,560
has been associated with some some major

337
00:11:42,000 --> 00:11:46,079
security breaches and the current

338
00:11:44,560 --> 00:11:49,519
dialect

339
00:11:46,079 --> 00:11:51,920
smb311 doesn't have the

340
00:11:49,519 --> 00:11:53,760
common internet file system cifs it's

341
00:11:51,920 --> 00:11:58,639
server message block smb

342
00:11:53,760 --> 00:12:00,000
so that name smb is easier to um

343
00:11:58,639 --> 00:12:01,920
to associate because it matches the

344
00:12:00,000 --> 00:12:04,000
dialect that's actually

345
00:12:01,920 --> 00:12:06,639
included the the kernel server doesn't

346
00:12:04,000 --> 00:12:08,399
support smb1 uh it's not supposed to

347
00:12:06,639 --> 00:12:10,720
we're not trying to encourage insecure

348
00:12:08,399 --> 00:12:12,720
dialects here so one of the things i

349
00:12:10,720 --> 00:12:13,839
want to remind people though is that we

350
00:12:12,720 --> 00:12:16,800
want to make sure also we don't get

351
00:12:13,839 --> 00:12:19,440
confused with samba so ksmbd

352
00:12:16,800 --> 00:12:22,160
is the kernel server's background demons

353
00:12:19,440 --> 00:12:24,000
smbd is samba's background demon we want

354
00:12:22,160 --> 00:12:26,480
to be careful not to collide between the

355
00:12:24,000 --> 00:12:28,480
two and the common code has been moved

356
00:12:26,480 --> 00:12:30,000
so we're trying to move over time more

357
00:12:28,480 --> 00:12:31,920
and more common code between client and

358
00:12:30,000 --> 00:12:33,200
server to lower the main main uh

359
00:12:31,920 --> 00:12:35,040
maintenance cost

360
00:12:33,200 --> 00:12:37,279
for this in the kernel and to make it

361
00:12:35,040 --> 00:12:39,760
easier to review so common code has been

362
00:12:37,279 --> 00:12:41,519
moving into this smb fs common directory

363
00:12:39,760 --> 00:12:42,720
and it's providing some optimizations

364
00:12:41,519 --> 00:12:44,399
for us

365
00:12:42,720 --> 00:12:46,959
later we're going to rename the sorts

366
00:12:44,399 --> 00:12:48,800
directory to smbfs client and you can

367
00:12:46,959 --> 00:12:51,600
already by the way build

368
00:12:48,800 --> 00:12:53,200
the sith driver

369
00:12:51,600 --> 00:12:54,639
and mount

370
00:12:53,200 --> 00:12:57,600
it as

371
00:12:54,639 --> 00:12:59,360
smb3 instead of mounting it as sifs so

372
00:12:57,600 --> 00:13:02,240
we're trying to get away from using that

373
00:12:59,360 --> 00:13:04,399
old deprecated term cifs because it

374
00:13:02,240 --> 00:13:05,600
implies less security but you know the

375
00:13:04,399 --> 00:13:07,920
modern clients all default to

376
00:13:05,600 --> 00:13:10,240
negotiating smb 311 which is highly

377
00:13:07,920 --> 00:13:13,040
secure and very fast

378
00:13:10,240 --> 00:13:14,720
so some some cool features um the kernel

379
00:13:13,040 --> 00:13:16,399
server just like the kernel client has

380
00:13:14,720 --> 00:13:18,240
added support for what some people

381
00:13:16,399 --> 00:13:20,880
nicknamed military grade encryption the

382
00:13:18,240 --> 00:13:22,240
strongest encryption model aes256 is now

383
00:13:20,880 --> 00:13:25,120
an option

384
00:13:22,240 --> 00:13:27,920
and notice the improved performance

385
00:13:25,120 --> 00:13:30,720
because the kernel server can use the uh

386
00:13:27,920 --> 00:13:33,120
the aes and i support in kernel notice

387
00:13:30,720 --> 00:13:34,959
the megabytes per second improvement by

388
00:13:33,120 --> 00:13:36,959
using the kernel drivers here provides

389
00:13:34,959 --> 00:13:38,560
significant benefit to us but here you

390
00:13:36,959 --> 00:13:42,000
also have the option of using the

391
00:13:38,560 --> 00:13:43,440
strongest encryption available aes256

392
00:13:42,000 --> 00:13:45,199
not just on the client but on the server

393
00:13:43,440 --> 00:13:47,279
that will alter we can negotiate this

394
00:13:45,199 --> 00:13:49,360
now

395
00:13:47,279 --> 00:13:52,079
kerberos support so you want stronger

396
00:13:49,360 --> 00:13:54,560
authentication um ksmb transmits the

397
00:13:52,079 --> 00:13:56,959
kerberos up calls to the ksmd mount d

398
00:13:54,560 --> 00:13:59,279
and uses libcare b5 for this

399
00:13:56,959 --> 00:14:02,560
duplicate extents duplicate extense is a

400
00:13:59,279 --> 00:14:04,720
fantastic feature uh ruffling and if

401
00:14:02,560 --> 00:14:07,040
you're on a file system like btrfs that

402
00:14:04,720 --> 00:14:08,480
supports reflect the linux client will

403
00:14:07,040 --> 00:14:10,399
use duplicate extents for some f

404
00:14:08,480 --> 00:14:12,480
allocate related operations like insert

405
00:14:10,399 --> 00:14:15,040
range and the server can support it when

406
00:14:12,480 --> 00:14:16,959
it's running on a file system like btrfs

407
00:14:15,040 --> 00:14:18,800
that supports reflect

408
00:14:16,959 --> 00:14:20,720
and fortunately the nice thing about

409
00:14:18,800 --> 00:14:21,920
ksmbd is because it's in kernel it

410
00:14:20,720 --> 00:14:23,680
doesn't have to deal with the sort of

411
00:14:21,920 --> 00:14:25,440
vfs mapping mess

412
00:14:23,680 --> 00:14:26,800
that that samba has to where it has to

413
00:14:25,440 --> 00:14:28,720
have different plug-in modules for

414
00:14:26,800 --> 00:14:31,360
various file system types

415
00:14:28,720 --> 00:14:33,440
so it supports this transparently and

416
00:14:31,360 --> 00:14:35,440
it's an example of a feature that was

417
00:14:33,440 --> 00:14:37,199
kind of easier to do in the kernel

418
00:14:35,440 --> 00:14:39,920
so multi-channel multi-channel is

419
00:14:37,199 --> 00:14:41,920
extremely important for performance it

420
00:14:39,920 --> 00:14:44,399
allows it's a feature that windows has

421
00:14:41,920 --> 00:14:46,160
had for years and it's a feature that is

422
00:14:44,399 --> 00:14:48,399
of incredible benefit if you put a

423
00:14:46,160 --> 00:14:50,399
network adapter in a machine

424
00:14:48,399 --> 00:14:52,480
the windows client and server dynam or

425
00:14:50,399 --> 00:14:54,240
the windows client dynamically notices

426
00:14:52,480 --> 00:14:56,480
the new adapter

427
00:14:54,240 --> 00:14:58,560
and connects to it automatically so you

428
00:14:56,480 --> 00:15:00,000
if you put a network adapter in

429
00:14:58,560 --> 00:15:01,920
whether it's rdma or regular your

430
00:15:00,000 --> 00:15:03,519
performance could double just by putting

431
00:15:01,920 --> 00:15:05,120
one adapter in without doing anything

432
00:15:03,519 --> 00:15:06,160
right there's no configuration needed

433
00:15:05,120 --> 00:15:07,600
there's no

434
00:15:06,160 --> 00:15:10,000
no magic needed you just put your

435
00:15:07,600 --> 00:15:12,480
network adapter in and the protocol

436
00:15:10,000 --> 00:15:14,560
supports advertising that

437
00:15:12,480 --> 00:15:17,519
via the witness protocol

438
00:15:14,560 --> 00:15:18,720
and some clients also poll for this but

439
00:15:17,519 --> 00:15:20,079
the performance benefits of

440
00:15:18,720 --> 00:15:21,839
multi-channel are huge because you're

441
00:15:20,079 --> 00:15:25,199
able to distribute io

442
00:15:21,839 --> 00:15:27,040
across many network cards

443
00:15:25,199 --> 00:15:29,199
on the client in cases where you have

444
00:15:27,040 --> 00:15:31,759
multiple network adapters or network

445
00:15:29,199 --> 00:15:34,560
interfaces and it allows you to spread

446
00:15:31,759 --> 00:15:34,560
io out

447
00:15:35,040 --> 00:15:40,160
when your network bottlenecked

448
00:15:38,079 --> 00:15:41,519
so they added the do replay retry

449
00:15:40,160 --> 00:15:43,360
features as well on the kernel servers

450
00:15:41,519 --> 00:15:45,839
this is another example where the kernel

451
00:15:43,360 --> 00:15:48,320
server um is just some features are

452
00:15:45,839 --> 00:15:50,240
easier to do in the kernel um so here is

453
00:15:48,320 --> 00:15:51,839
how how it works

454
00:15:50,240 --> 00:15:53,199
the client is sent the network

455
00:15:51,839 --> 00:15:55,600
interfaces here you see two network

456
00:15:53,199 --> 00:15:57,519
interfaces being advertised the query

457
00:15:55,600 --> 00:15:59,440
network interface call sends that and

458
00:15:57,519 --> 00:16:00,959
then you do a session binding request to

459
00:15:59,440 --> 00:16:03,680
those sessions

460
00:16:00,959 --> 00:16:05,759
then you now look at the blue versus the

461
00:16:03,680 --> 00:16:07,839
yellow if you look at the blue versus

462
00:16:05,759 --> 00:16:12,079
the yellow you can see that it's

463
00:16:07,839 --> 00:16:12,079
interleaving requests over multiple

464
00:16:12,639 --> 00:16:16,959
multiple interfaces so we're able to

465
00:16:15,120 --> 00:16:18,800
spread i o out to avoid network

466
00:16:16,959 --> 00:16:20,240
bottlenecks so what kind of features are

467
00:16:18,800 --> 00:16:23,639
working now that are exciting some of

468
00:16:20,240 --> 00:16:23,639
the things like smbdirect

469
00:16:24,320 --> 00:16:27,360
there are patches and performance for

470
00:16:25,759 --> 00:16:28,959
various performance improvements for the

471
00:16:27,360 --> 00:16:31,759
windows client

472
00:16:28,959 --> 00:16:34,079
smb direct works from both linux thank

473
00:16:31,759 --> 00:16:35,759
you to longley

474
00:16:34,079 --> 00:16:38,000
a couple years ago for his work he did

475
00:16:35,759 --> 00:16:39,759
adding it to the support for

476
00:16:38,000 --> 00:16:42,079
smb over rdma

477
00:16:39,759 --> 00:16:43,680
um a few years ago to linux

478
00:16:42,079 --> 00:16:46,240
but sme direct from linux and windows

479
00:16:43,680 --> 00:16:48,839
works support for direct releases

480
00:16:46,240 --> 00:16:51,199
works direct releases allow you to cache

481
00:16:48,839 --> 00:16:53,600
metadata safely

482
00:16:51,199 --> 00:16:56,000
this isn't like a timer this is just a

483
00:16:53,600 --> 00:16:57,839
this is a way of safely caching metadata

484
00:16:56,000 --> 00:16:59,600
and change notify which allows you to

485
00:16:57,839 --> 00:17:01,120
watch

486
00:16:59,600 --> 00:17:02,880
for changes in tree for example when i

487
00:17:01,120 --> 00:17:05,519
if i went to a windows box or a linux

488
00:17:02,880 --> 00:17:05,519
box and opened

489
00:17:05,760 --> 00:17:08,720
especially on windows and mac when you

490
00:17:07,199 --> 00:17:10,720
open a

491
00:17:08,720 --> 00:17:12,079
explorer window

492
00:17:10,720 --> 00:17:13,679
and you add a file from a different

493
00:17:12,079 --> 00:17:15,919
client you'll automatically see it show

494
00:17:13,679 --> 00:17:18,079
up in your window on the other clients

495
00:17:15,919 --> 00:17:20,160
because change notify will have notified

496
00:17:18,079 --> 00:17:22,240
you about the new file

497
00:17:20,160 --> 00:17:24,079
linux unfortunately the i notify call is

498
00:17:22,240 --> 00:17:25,439
local only file systems i notify isn't

499
00:17:24,079 --> 00:17:26,959
supported across

500
00:17:25,439 --> 00:17:28,319
network file systems but that's

501
00:17:26,959 --> 00:17:30,640
something that amir and others have been

502
00:17:28,319 --> 00:17:33,200
discussing fixing

503
00:17:30,640 --> 00:17:35,039
adding support for rss rsf receive side

504
00:17:33,200 --> 00:17:36,240
scaling allows network adapters to

505
00:17:35,039 --> 00:17:38,400
offload

506
00:17:36,240 --> 00:17:39,360
um

507
00:17:38,400 --> 00:17:42,720
i o

508
00:17:39,360 --> 00:17:44,799
for better performance um sort of

509
00:17:42,720 --> 00:17:46,320
and you can see the support

510
00:17:44,799 --> 00:17:47,760
the kernel server can help again here

511
00:17:46,320 --> 00:17:49,039
you can see the very large performance

512
00:17:47,760 --> 00:17:50,640
improvements compared to sama so there

513
00:17:49,039 --> 00:17:52,480
are certain workloads where they're very

514
00:17:50,640 --> 00:17:53,919
helpful um

515
00:17:52,480 --> 00:17:55,679
and um

516
00:17:53,919 --> 00:17:56,880
you know this smb direct improvements is

517
00:17:55,679 --> 00:17:58,160
fantastic

518
00:17:56,880 --> 00:18:00,720
um

519
00:17:58,160 --> 00:18:02,320
so just another quick comment i wanted

520
00:18:00,720 --> 00:18:03,919
to make about ksmd initially there were

521
00:18:02,320 --> 00:18:05,679
some major security problems found

522
00:18:03,919 --> 00:18:07,679
immediately after it was merged so in

523
00:18:05,679 --> 00:18:09,520
the 515 and 516 kernel there are

524
00:18:07,679 --> 00:18:11,919
significant number of security fixes

525
00:18:09,520 --> 00:18:14,000
that got merged into ksmb to address

526
00:18:11,919 --> 00:18:16,080
those and it was marked experimental and

527
00:18:14,000 --> 00:18:19,440
disabled by default as a result

528
00:18:16,080 --> 00:18:19,440
now over the next

529
00:18:19,919 --> 00:18:23,440
over the the 515 release window things

530
00:18:21,840 --> 00:18:25,200
improved dramatically but we are

531
00:18:23,440 --> 00:18:26,880
tracking these security issues carefully

532
00:18:25,200 --> 00:18:29,679
so if you have additional reviews or

533
00:18:26,880 --> 00:18:31,360
comments about security please uh you

534
00:18:29,679 --> 00:18:32,799
know contact the mailing list

535
00:18:31,360 --> 00:18:34,400
and also

536
00:18:32,799 --> 00:18:37,520
we have a wiki page to track some of

537
00:18:34,400 --> 00:18:39,840
this i'm helping nam jay maintain this

538
00:18:37,520 --> 00:18:41,520
co-maintaining it but nom j

539
00:18:39,840 --> 00:18:43,280
and a team of four or five guys is doing

540
00:18:41,520 --> 00:18:44,880
most of the work here it's a very

541
00:18:43,280 --> 00:18:47,120
exciting time on the server so let's

542
00:18:44,880 --> 00:18:49,520
switch gears to the client on the client

543
00:18:47,120 --> 00:18:50,960
we have lots of cool progress but i

544
00:18:49,520 --> 00:18:52,559
wanted to start out by mentioning that

545
00:18:50,960 --> 00:18:54,000
in the smb world unlike sort of the

546
00:18:52,559 --> 00:18:56,080
posix world you're used to there are

547
00:18:54,000 --> 00:18:58,640
three security models you have a model

548
00:18:56,080 --> 00:19:00,799
that's cheap where everyone just gets a

549
00:18:58,640 --> 00:19:02,720
default owner or default group you have

550
00:19:00,799 --> 00:19:05,360
an example where

551
00:19:02,720 --> 00:19:05,360
you're pulling

552
00:19:05,520 --> 00:19:07,679
the

553
00:19:06,400 --> 00:19:11,520
mode bits

554
00:19:07,679 --> 00:19:12,720
in a way that matches

555
00:19:11,520 --> 00:19:14,400
what the

556
00:19:12,720 --> 00:19:16,320
server is going to enforce

557
00:19:14,400 --> 00:19:18,000
heckles and you also have a case where

558
00:19:16,320 --> 00:19:19,200
you want the exact mode bits on the

559
00:19:18,000 --> 00:19:20,799
client

560
00:19:19,200 --> 00:19:23,679
but on the server they don't need to

561
00:19:20,799 --> 00:19:25,600
enforce those that's mode from sid those

562
00:19:23,679 --> 00:19:27,360
three cases you have to deal with all of

563
00:19:25,600 --> 00:19:29,120
those

564
00:19:27,360 --> 00:19:32,400
um you have to deal with all those use

565
00:19:29,120 --> 00:19:33,840
cases uh in our smb world a default case

566
00:19:32,400 --> 00:19:35,840
it's cheap

567
00:19:33,840 --> 00:19:38,240
an ackle world where apples and mode

568
00:19:35,840 --> 00:19:39,919
bits have to coexist and a third case

569
00:19:38,240 --> 00:19:42,320
where the mode bits are perfect but the

570
00:19:39,919 --> 00:19:43,360
client's enforcing it not the server

571
00:19:42,320 --> 00:19:44,720
okay

572
00:19:43,360 --> 00:19:46,000
so

573
00:19:44,720 --> 00:19:47,840
a couple people

574
00:19:46,000 --> 00:19:49,200
forwarded questions here and i want to

575
00:19:47,840 --> 00:19:50,960
address those before we go too much

576
00:19:49,200 --> 00:19:53,520
farther one of them was about rss

577
00:19:50,960 --> 00:19:56,880
offload so there are network adapters

578
00:19:53,520 --> 00:20:00,160
that have the capability of

579
00:19:56,880 --> 00:20:03,600
copying directly to the network adapter

580
00:20:00,160 --> 00:20:06,640
to avoid some of the cpu penalty so for

581
00:20:03,600 --> 00:20:09,280
example um

582
00:20:06,640 --> 00:20:11,360
their um

583
00:20:09,280 --> 00:20:13,520
i mean a good example is we can pat in

584
00:20:11,360 --> 00:20:15,840
the kernel we can pass an array of

585
00:20:13,520 --> 00:20:18,080
pointers to a socket right call that

586
00:20:15,840 --> 00:20:20,240
gets passed all the way down an rss

587
00:20:18,080 --> 00:20:21,760
adapter what happens today in windows

588
00:20:20,240 --> 00:20:23,919
for example when the windows client

589
00:20:21,760 --> 00:20:26,640
detects that the server

590
00:20:23,919 --> 00:20:30,159
adapter is rss it automatically sets up

591
00:20:26,640 --> 00:20:32,960
two sockets so the rss capability is a

592
00:20:30,159 --> 00:20:34,960
hint to the client that the server's

593
00:20:32,960 --> 00:20:37,120
adapter is fast enough that it's worth

594
00:20:34,960 --> 00:20:38,640
the trouble to set up two sockets not

595
00:20:37,120 --> 00:20:40,640
just one

596
00:20:38,640 --> 00:20:42,960
to allow for more parallelism on the

597
00:20:40,640 --> 00:20:42,960
wire

598
00:20:43,280 --> 00:20:48,559
now the constraints around i notify so

599
00:20:46,720 --> 00:20:49,440
somebody asked about i notify so this is

600
00:20:48,559 --> 00:20:51,120
a

601
00:20:49,440 --> 00:20:53,440
something that amir goldstein and others

602
00:20:51,120 --> 00:20:55,520
have uh have been discussing

603
00:20:53,440 --> 00:20:57,520
one of the problems is that the i notify

604
00:20:55,520 --> 00:20:59,600
api never calls into the network file

605
00:20:57,520 --> 00:21:00,480
system to tell it

606
00:20:59,600 --> 00:21:03,360
that

607
00:21:00,480 --> 00:21:05,280
we're waiting on um

608
00:21:03,360 --> 00:21:07,440
a notification event the network file

609
00:21:05,280 --> 00:21:10,240
system has no problem notifying but it

610
00:21:07,440 --> 00:21:12,640
isn't notified it isn't told there's no

611
00:21:10,240 --> 00:21:13,360
sys the syscall doesn't make it down to

612
00:21:12,640 --> 00:21:15,120
the

613
00:21:13,360 --> 00:21:17,600
uh the file system itself it stops at

614
00:21:15,120 --> 00:21:19,520
the vfs mapping layer so there's no way

615
00:21:17,600 --> 00:21:22,159
for the file system to know

616
00:21:19,520 --> 00:21:24,080
to notify the kernel on a callback that

617
00:21:22,159 --> 00:21:25,760
a file has changed or directory has

618
00:21:24,080 --> 00:21:28,240
changed

619
00:21:25,760 --> 00:21:30,480
that's relatively easy to fix but it

620
00:21:28,240 --> 00:21:31,840
brought up a larger discussion about you

621
00:21:30,480 --> 00:21:33,360
know which features should be included

622
00:21:31,840 --> 00:21:37,280
because as you might guess the smb

623
00:21:33,360 --> 00:21:39,120
protocol includes more notify features

624
00:21:37,280 --> 00:21:40,080
so the protocol has more features than

625
00:21:39,120 --> 00:21:42,080
linux

626
00:21:40,080 --> 00:21:44,159
currently advertises so is it worth

627
00:21:42,080 --> 00:21:46,159
adding additional flags to linux notify

628
00:21:44,159 --> 00:21:46,960
mechanism for example

629
00:21:46,159 --> 00:21:49,280
you know

630
00:21:46,960 --> 00:21:52,000
every client except for linux sends

631
00:21:49,280 --> 00:21:54,240
notify across the network for smb

632
00:21:52,000 --> 00:21:56,960
so you can see windows

633
00:21:54,240 --> 00:21:58,320
being updated automatically when a file

634
00:21:56,960 --> 00:21:59,679
is dropped in from another client the

635
00:21:58,320 --> 00:22:00,960
directory listing changes the little

636
00:21:59,679 --> 00:22:02,640
icons change

637
00:22:00,960 --> 00:22:03,360
okay anyway the

638
00:22:02,640 --> 00:22:04,720
the

639
00:22:03,360 --> 00:22:06,240
the point i was getting out here though

640
00:22:04,720 --> 00:22:07,679
about notify is these are these are

641
00:22:06,240 --> 00:22:09,520
patches that have been discussed there's

642
00:22:07,679 --> 00:22:12,240
no technical problem in implementing

643
00:22:09,520 --> 00:22:14,640
them um but right now notify is a local

644
00:22:12,240 --> 00:22:16,720
only event on linux um the server can

645
00:22:14,640 --> 00:22:18,559
advertise it to remote clients but uh

646
00:22:16,720 --> 00:22:19,520
there's no way for nfs or smb or

647
00:22:18,559 --> 00:22:20,960
actually nfs doesn't really have

648
00:22:19,520 --> 00:22:22,880
notified that way but there's no way for

649
00:22:20,960 --> 00:22:24,320
smb to a

650
00:22:22,880 --> 00:22:25,760
client to um

651
00:22:24,320 --> 00:22:27,840
to request a notification from the

652
00:22:25,760 --> 00:22:29,120
server we do have an ioctal though for

653
00:22:27,840 --> 00:22:30,720
that so if you want to do this an

654
00:22:29,120 --> 00:22:32,559
application can call specifically into

655
00:22:30,720 --> 00:22:34,159
the cya octal on the on the linux client

656
00:22:32,559 --> 00:22:38,000
to get that same feature

657
00:22:34,159 --> 00:22:38,000
okay and then the other one was um

658
00:22:38,720 --> 00:22:44,000
so there was a question generally about

659
00:22:40,880 --> 00:22:45,520
uh performance and feature sets um

660
00:22:44,000 --> 00:22:47,200
file servers

661
00:22:45,520 --> 00:22:48,880
linux versus windows i think it's an

662
00:22:47,200 --> 00:22:51,840
interesting thing is that there are many

663
00:22:48,880 --> 00:22:53,280
cases where we expect that uh that linux

664
00:22:51,840 --> 00:22:55,600
could actually be faster in some cases

665
00:22:53,280 --> 00:22:57,280
than windows but let's come back to that

666
00:22:55,600 --> 00:22:58,400
question about performance

667
00:22:57,280 --> 00:23:01,440
um

668
00:22:58,400 --> 00:23:03,039
but uh in terms of rdma i think that

669
00:23:01,440 --> 00:23:06,640
what the platforms that you can take

670
00:23:03,039 --> 00:23:06,640
advantage of for rdma today are

671
00:23:06,880 --> 00:23:10,000
linux client

672
00:23:08,480 --> 00:23:12,159
when you mount from linux though you

673
00:23:10,000 --> 00:23:15,039
have to specifically request rdma on the

674
00:23:12,159 --> 00:23:17,360
mount line so ask for rdma

675
00:23:15,039 --> 00:23:18,159
when windows it automatically detects it

676
00:23:17,360 --> 00:23:19,520
so

677
00:23:18,159 --> 00:23:20,880
there are slight differences but both

678
00:23:19,520 --> 00:23:23,360
windows and linux can take advantage of

679
00:23:20,880 --> 00:23:24,559
it but the windows part has recently

680
00:23:23,360 --> 00:23:26,720
added and there's some performance

681
00:23:24,559 --> 00:23:29,360
optimizations being worked on right now

682
00:23:26,720 --> 00:23:30,559
so good question to come back to so

683
00:23:29,360 --> 00:23:32,000
lots of security improvements on the

684
00:23:30,559 --> 00:23:33,120
client let's get back to the client here

685
00:23:32,000 --> 00:23:34,080
because we're running a little bit low

686
00:23:33,120 --> 00:23:35,600
on time

687
00:23:34,080 --> 00:23:38,480
improvements to authentication thank you

688
00:23:35,600 --> 00:23:39,840
to cheyenne there's some um the gcm

689
00:23:38,480 --> 00:23:41,520
encryption now added on the client the

690
00:23:39,840 --> 00:23:44,000
strongest form of encryption

691
00:23:41,520 --> 00:23:46,240
uh very exciting azure for example

692
00:23:44,000 --> 00:23:48,000
windows ks mbd all supported this is

693
00:23:46,240 --> 00:23:50,480
fantastic you know to the cloud to have

694
00:23:48,000 --> 00:23:52,080
the strongest encryption

695
00:23:50,480 --> 00:23:54,320
now here's a trace if you want to look

696
00:23:52,080 --> 00:23:55,840
at a wireshark example of using that

697
00:23:54,320 --> 00:23:58,320
multi-channel we talked about on the

698
00:23:55,840 --> 00:24:00,080
client is is much improved right at this

699
00:23:58,320 --> 00:24:01,760
moment literally like

700
00:24:00,080 --> 00:24:03,279
before this talk started i was working

701
00:24:01,760 --> 00:24:05,520
on some

702
00:24:03,279 --> 00:24:08,320
reviewing some multi-channel page

703
00:24:05,520 --> 00:24:09,600
improvements for reconnect from cheyenne

704
00:24:08,320 --> 00:24:11,360
now let's look at some performance

705
00:24:09,600 --> 00:24:12,240
improvements we have some really cool

706
00:24:11,360 --> 00:24:14,000
import

707
00:24:12,240 --> 00:24:16,320
performance improvements notice that

708
00:24:14,000 --> 00:24:20,240
going from the old defaults of smb3 just

709
00:24:16,320 --> 00:24:21,279
smb311 got me 41 faster adding multiple

710
00:24:20,240 --> 00:24:23,520
channels

711
00:24:21,279 --> 00:24:25,440
uh and this new rs size we got three

712
00:24:23,520 --> 00:24:26,799
times faster for something as simple as

713
00:24:25,440 --> 00:24:28,799
copying a file

714
00:24:26,799 --> 00:24:30,720
copying a 10 gig file got three times

715
00:24:28,799 --> 00:24:32,400
faster really cool performance

716
00:24:30,720 --> 00:24:33,360
improvements

717
00:24:32,400 --> 00:24:34,640
so

718
00:24:33,360 --> 00:24:36,400
um the other thing i wanted to mention

719
00:24:34,640 --> 00:24:38,559
was there's a fantastic feature thanks

720
00:24:36,400 --> 00:24:40,400
to row heath added in 513 for deferred

721
00:24:38,559 --> 00:24:42,640
close this allows you to do something

722
00:24:40,400 --> 00:24:45,120
like open create a temp file write to it

723
00:24:42,640 --> 00:24:46,559
close open read the temp file and you

724
00:24:45,120 --> 00:24:48,960
you don't end up sending any of those

725
00:24:46,559 --> 00:24:50,799
reads because the file is briefly

726
00:24:48,960 --> 00:24:52,480
deferred the close

727
00:24:50,799 --> 00:24:54,240
uh and then when sees the re the second

728
00:24:52,480 --> 00:24:56,240
open it doesn't have to to re-read the

729
00:24:54,240 --> 00:24:57,919
same network as you can see this is you

730
00:24:56,240 --> 00:25:00,640
know three times faster for something as

731
00:24:57,919 --> 00:25:02,880
simple as you know create a file write

732
00:25:00,640 --> 00:25:05,200
it read it close it read it

733
00:25:02,880 --> 00:25:07,440
so this is really cool also metadata

734
00:25:05,200 --> 00:25:09,279
caching is much more granular now it's

735
00:25:07,440 --> 00:25:11,360
possible to separate the metadata

736
00:25:09,279 --> 00:25:13,679
caching for directories and files we

737
00:25:11,360 --> 00:25:16,480
have much better debugging we have

738
00:25:13,679 --> 00:25:18,159
dynamic trace points ebpf is the thing

739
00:25:16,480 --> 00:25:19,679
you know i think you saw microsoft and

740
00:25:18,159 --> 00:25:22,000
many others are joining together to try

741
00:25:19,679 --> 00:25:23,760
to make ebpf even better but i'm trying

742
00:25:22,000 --> 00:25:26,400
to add events to make it easier to debug

743
00:25:23,760 --> 00:25:28,720
and optimize 87 of them now we added the

744
00:25:26,400 --> 00:25:30,480
shutdown support in 513. now for you

745
00:25:28,720 --> 00:25:32,640
guys to look at later i've included a

746
00:25:30,480 --> 00:25:33,760
pretty detailed list of all of the

747
00:25:32,640 --> 00:25:35,200
features

748
00:25:33,760 --> 00:25:37,039
by release

749
00:25:35,200 --> 00:25:39,120
so if you guys want to review that later

750
00:25:37,039 --> 00:25:40,880
you can see you know each kernel now red

751
00:25:39,120 --> 00:25:43,120
hat and sousa and others have been very

752
00:25:40,880 --> 00:25:44,480
aggressive about backboarding this some

753
00:25:43,120 --> 00:25:45,679
of the ubuntu kernels have also

754
00:25:44,480 --> 00:25:46,799
backported

755
00:25:45,679 --> 00:25:49,840
but i think what you're going to see

756
00:25:46,799 --> 00:25:51,360
here is lots of cool fixes and if you're

757
00:25:49,840 --> 00:25:53,919
you know want to go through release by

758
00:25:51,360 --> 00:25:55,440
release you can see what's been added

759
00:25:53,919 --> 00:25:56,960
you know by downloading the slides after

760
00:25:55,440 --> 00:25:58,159
the presentation

761
00:25:56,960 --> 00:26:01,279
so

762
00:25:58,159 --> 00:26:02,720
i was very excited in 514 about some f

763
00:26:01,279 --> 00:26:04,400
allocate

764
00:26:02,720 --> 00:26:05,360
improvements to be able to

765
00:26:04,400 --> 00:26:08,159
handle

766
00:26:05,360 --> 00:26:10,480
sparse files and to be able to handle

767
00:26:08,159 --> 00:26:11,440
some new tests uh some new features of

768
00:26:10,480 --> 00:26:13,360
uh

769
00:26:11,440 --> 00:26:15,520
uh f allocate that uh that were not

770
00:26:13,360 --> 00:26:17,200
supported before thanks to ronnie at uh

771
00:26:15,520 --> 00:26:18,720
some of his work at red hat we also in

772
00:26:17,200 --> 00:26:20,159
the 515 kernel had a kind of

773
00:26:18,720 --> 00:26:22,559
controversial thing we removed the

774
00:26:20,159 --> 00:26:23,279
weakest forms of authentication ntlmv1

775
00:26:22,559 --> 00:26:26,000
from

776
00:26:23,279 --> 00:26:27,440
you know 1996 and land man from the

777
00:26:26,000 --> 00:26:29,679
early 90s

778
00:26:27,440 --> 00:26:32,159
which has provoked some controversy

779
00:26:29,679 --> 00:26:34,799
removing these very old

780
00:26:32,159 --> 00:26:36,799
uh very very old security algorithms

781
00:26:34,799 --> 00:26:38,400
obviously ntlmv2 has been around since

782
00:26:36,799 --> 00:26:40,159
the late 90s

783
00:26:38,400 --> 00:26:42,480
and it's much stronger but

784
00:26:40,159 --> 00:26:44,240
you know it breaks some very old devices

785
00:26:42,480 --> 00:26:46,159
and smb has worked for years with some

786
00:26:44,240 --> 00:26:47,520
devices that are 30 years old 25 years

787
00:26:46,159 --> 00:26:48,799
old

788
00:26:47,520 --> 00:26:50,159
the 516

789
00:26:48,799 --> 00:26:52,400
had some really cool improvements for

790
00:26:50,159 --> 00:26:54,480
compounding some reconnect improvements

791
00:26:52,400 --> 00:26:56,880
and now what are we dealing with we're

792
00:26:54,480 --> 00:26:58,960
dealing with a big patch set for fs

793
00:26:56,880 --> 00:27:01,039
cache and for offline caching and nfs

794
00:26:58,960 --> 00:27:02,559
and some multi-channel patches but what

795
00:27:01,039 --> 00:27:04,840
i'm most excited about is looking

796
00:27:02,559 --> 00:27:07,520
forward things like

797
00:27:04,840 --> 00:27:10,000
quick and

798
00:27:07,520 --> 00:27:11,919
because quick solves many problems but

799
00:27:10,000 --> 00:27:15,120
it also gives you another choice for

800
00:27:11,919 --> 00:27:17,200
encryption to work around the port 445

801
00:27:15,120 --> 00:27:19,120
problem for example i wasn't able to

802
00:27:17,200 --> 00:27:21,679
save my presentation as easily into the

803
00:27:19,120 --> 00:27:24,159
cloud because port 445 is blocked by my

804
00:27:21,679 --> 00:27:26,000
provider but isn't blocked by the

805
00:27:24,159 --> 00:27:28,320
provider

806
00:27:26,000 --> 00:27:30,640
in the next city over from me

807
00:27:28,320 --> 00:27:32,159
so quick avoids that problem giving you

808
00:27:30,640 --> 00:27:34,000
encrypted traffic

809
00:27:32,159 --> 00:27:36,320
but it also has some neat parallelism

810
00:27:34,000 --> 00:27:39,120
features um also i want to add

811
00:27:36,320 --> 00:27:40,880
compression support for smb1 311 we've

812
00:27:39,120 --> 00:27:43,279
made a start at that

813
00:27:40,880 --> 00:27:44,880
and also um there is uh some work to

814
00:27:43,279 --> 00:27:47,600
improve metadata performance by more

815
00:27:44,880 --> 00:27:49,120
generally allowing using direct releases

816
00:27:47,600 --> 00:27:51,919
the windows client does a much better

817
00:27:49,120 --> 00:27:53,200
job than linux the mac client does metro

818
00:27:51,919 --> 00:27:55,039
the linux client is much worse than

819
00:27:53,200 --> 00:27:56,640
windows the mac client

820
00:27:55,039 --> 00:27:58,640
does much better than linux as well in

821
00:27:56,640 --> 00:28:00,559
some of these areas and these are areas

822
00:27:58,640 --> 00:28:02,080
that we can really improve

823
00:28:00,559 --> 00:28:03,600
also we need to improve id mapping

824
00:28:02,080 --> 00:28:07,039
choices there are many cases where we

825
00:28:03,600 --> 00:28:08,480
can't use rfc 2307 um

826
00:28:07,039 --> 00:28:10,399
also invented by an australian by the

827
00:28:08,480 --> 00:28:12,159
way

828
00:28:10,399 --> 00:28:15,039
where we need other id mapping choices

829
00:28:12,159 --> 00:28:16,960
to be able to map sanely a global

830
00:28:15,039 --> 00:28:20,640
identity to a local uid

831
00:28:16,960 --> 00:28:21,919
okay we're running fairly low on on time

832
00:28:20,640 --> 00:28:24,399
and

833
00:28:21,919 --> 00:28:26,399
i don't want to overrun my presentation

834
00:28:24,399 --> 00:28:27,919
too much here but i want to remind you

835
00:28:26,399 --> 00:28:29,600
there's some great tooling improvements

836
00:28:27,919 --> 00:28:31,520
in the user space tools you can now view

837
00:28:29,600 --> 00:28:33,279
alternative data streams for example

838
00:28:31,520 --> 00:28:35,840
and we have some general configuration

839
00:28:33,279 --> 00:28:37,919
advice on the later slides here

840
00:28:35,840 --> 00:28:39,760
but i also want to say our biggest focus

841
00:28:37,919 --> 00:28:41,520
right now is preventing regressions and

842
00:28:39,760 --> 00:28:42,960
improving testing we added more than 40

843
00:28:41,520 --> 00:28:44,880
tests to our test group we have this

844
00:28:42,960 --> 00:28:45,840
automated thing called the buildbot

845
00:28:44,880 --> 00:28:47,679
um

846
00:28:45,840 --> 00:28:50,640
thanks to work by ronnie and irelian and

847
00:28:47,679 --> 00:28:51,919
others and every single pull request we

848
00:28:50,640 --> 00:28:54,399
send

849
00:28:51,919 --> 00:28:56,320
we make sure that we run the buildbot on

850
00:28:54,399 --> 00:28:57,919
and that has improved the quality

851
00:28:56,320 --> 00:29:00,080
enormously so if you have additional

852
00:28:57,919 --> 00:29:02,000
tests you want to include these leverage

853
00:29:00,080 --> 00:29:03,760
xfs tests in many cases but they also

854
00:29:02,000 --> 00:29:05,520
run things like the get functional test

855
00:29:03,760 --> 00:29:07,679
please send them to us please work with

856
00:29:05,520 --> 00:29:10,159
us on improving test coverage we want to

857
00:29:07,679 --> 00:29:11,600
make these releases the most stable ever

858
00:29:10,159 --> 00:29:14,559
and every single pull request we're

859
00:29:11,600 --> 00:29:16,480
running an exhaustive huge set of tests

860
00:29:14,559 --> 00:29:17,360
anyway i thank you very much for your

861
00:29:16,480 --> 00:29:19,120
time

862
00:29:17,360 --> 00:29:20,720
and uh you know if we have time for any

863
00:29:19,120 --> 00:29:21,760
last you know one minute of questions

864
00:29:20,720 --> 00:29:24,080
that's great

865
00:29:21,760 --> 00:29:26,320
um but otherwise feel free to contact me

866
00:29:24,080 --> 00:29:28,720
at some french at gmail or on the linux

867
00:29:26,320 --> 00:29:31,120
sift's mailing list

868
00:29:28,720 --> 00:29:34,399
the linux mailing list you can see on

869
00:29:31,120 --> 00:29:34,399
one of these slides here at the end

870
00:29:34,640 --> 00:29:36,880
okay

871
00:29:37,279 --> 00:29:40,880
thank you very much steve um

872
00:29:39,200 --> 00:29:42,480
unfortunately we have reached the end of

873
00:29:40,880 --> 00:29:46,080
the time slot so if you've got further

874
00:29:42,480 --> 00:29:48,159
questions um you can contact steve uh

875
00:29:46,080 --> 00:29:50,240
outside of this session and i'm sure

876
00:29:48,159 --> 00:29:54,240
he'll be happy to answer questions

877
00:29:50,240 --> 00:29:56,320
yeah very much so thank you very much

878
00:29:54,240 --> 00:29:56,320
you