]> git.proxmox.com Git - mirror_zfs.git/blob - man/man8/zfs-program.8
OpenZFS 7431 - ZFS Channel Programs
[mirror_zfs.git] / man / man8 / zfs-program.8
1 .\" This file and its contents are supplied under the terms of the
2 .\" Common Development and Distribution License ("CDDL"), version 1.0.
3 .\" You may only use this file in accordance with the terms of version
4 .\" 1.0 of the CDDL.
5 .\"
6 .\" A full copy of the text of the CDDL should have accompanied this
7 .\" source. A copy of the CDDL is also available via the Internet at
8 .\" http://www.illumos.org/license/CDDL.
9 .\"
10 .\"
11 .\" Copyright (c) 2016 by Delphix. All Rights Reserved.
12 .\"
13 .Dd January 21, 2016
14 .Dt ZFS-PROGRAM 8
15 .Os
16 .Sh NAME
17 .Nm zfs program
18 .Nd executes ZFS channel programs
19 .Sh SYNOPSIS
20 .Cm zfs program
21 .Op Fl t Ar instruction-limit
22 .Op Fl m Ar memory-limit
23 .Ar pool
24 .Ar script
25 .\".Op Ar optional arguments to channel program
26 .Sh DESCRIPTION
27 The ZFS channel program interface allows ZFS administrative operations to be
28 run programmatically as a Lua script.
29 The entire script is executed atomically, with no other administrative
30 operations taking effect concurrently.
31 A library of ZFS calls is made available to channel program scripts.
32 Channel programs may only be run with root privileges.
33 .Pp
34 A modified version of the Lua 5.2 interpreter is used to run channel program
35 scripts.
36 The Lua 5.2 manual can be found at:
37 .Bd -centered -offset indent
38 .Lk http://www.lua.org/manual/5.2/
39 .Ed
40 .Pp
41 The channel program given by
42 .Ar script
43 will be run on
44 .Ar pool ,
45 and any attempts to access or modify other pools will cause an error.
46 .Sh OPTIONS
47 .Bl -tag -width "-t"
48 .It Fl t Ar instruction-limit
49 Execution time limit, in number of Lua instructions to execute.
50 If a channel program executes more than the specified number of instructions,
51 it will be stopped and an error will be returned.
52 The default limit is 10 million instructions, and it can be set to a maximum of
53 100 million instructions.
54 .It Fl m Ar memory-limit
55 Memory limit, in bytes.
56 If a channel program attempts to allocate more memory than the given limit, it
57 will be stopped and an error returned.
58 The default memory limit is 10 MB, and can be set to a maximum of 100 MB.
59 .El
60 .Pp
61 All remaining argument strings will be passed directly to the Lua script as
62 described in the
63 .Sx LUA INTERFACE
64 section below.
65 .Sh LUA INTERFACE
66 A channel program can be invoked either from the command line, or via a library
67 call to
68 .Fn lzc_channel_program .
69 .Ss Arguments
70 Arguments passed to the channel program are converted to a Lua table.
71 If invoked from the command line, extra arguments to the Lua script will be
72 accessible as an array stored in the argument table with the key 'argv':
73 .Bd -literal -offset indent
74 args = ...
75 argv = args["argv"]
76 -- argv == {1="arg1", 2="arg2", ...}
77 .Ed
78 .Pp
79 If invoked from the libZFS interface, an arbitrary argument list can be
80 passed to the channel program, which is accessible via the same
81 "..." syntax in Lua:
82 .Bd -literal -offset indent
83 args = ...
84 -- args == {"foo"="bar", "baz"={...}, ...}
85 .Ed
86 .Pp
87 Note that because Lua arrays are 1-indexed, arrays passed to Lua from the
88 libZFS interface will have their indices incremented by 1.
89 That is, the element
90 in
91 .Va arr[0]
92 in a C array passed to a channel program will be stored in
93 .Va arr[1]
94 when accessed from Lua.
95 .Ss Return Values
96 Lua return statements take the form:
97 .Bd -literal -offset indent
98 return ret0, ret1, ret2, ...
99 .Ed
100 .Pp
101 Return statements returning multiple values are permitted internally in a
102 channel program script, but attempting to return more than one value from the
103 top level of the channel program is not permitted and will throw an error.
104 However, tables containing multiple values can still be returned.
105 If invoked from the command line, a return statement:
106 .Bd -literal -offset indent
107 a = {foo="bar", baz=2}
108 return a
109 .Ed
110 .Pp
111 Will be output formatted as:
112 .Bd -literal -offset indent
113 Channel program fully executed with return value:
114 return:
115 baz: 2
116 foo: 'bar'
117 .Ed
118 .Ss Fatal Errors
119 If the channel program encounters a fatal error while running, a non-zero exit
120 status will be returned.
121 If more information about the error is available, a singleton list will be
122 returned detailing the error:
123 .Bd -literal -offset indent
124 error: "error string, including Lua stack trace"
125 .Ed
126 .Pp
127 If a fatal error is returned, the channel program may have not executed at all,
128 may have partially executed, or may have fully executed but failed to pass a
129 return value back to userland.
130 .Pp
131 If the channel program exhausts an instruction or memory limit, a fatal error
132 will be generated and the program will be stopped, leaving the program partially
133 executed.
134 No attempt is made to reverse or undo any operations already performed.
135 Note that because both the instruction count and amount of memory used by a
136 channel program are deterministic when run against the same inputs and
137 filesystem state, as long as a channel program has run successfully once, you
138 can guarantee that it will finish successfully against a similar size system.
139 .Pp
140 If a channel program attempts to return too large a value, the program will
141 fully execute but exit with a nonzero status code and no return value.
142 .Pp
143 .Em Note:
144 ZFS API functions do not generate Fatal Errors when correctly invoked, they
145 return an error code and the channel program continues executing.
146 See the
147 .Sx ZFS API
148 section below for function-specific details on error return codes.
149 .Ss Lua to C Value Conversion
150 When invoking a channel program via the libZFS interface, it is necessary to
151 translate arguments and return values from Lua values to their C equivalents,
152 and vice-versa.
153 .Pp
154 There is a correspondence between nvlist values in C and Lua tables.
155 A Lua table which is returned from the channel program will be recursively
156 converted to an nvlist, with table values converted to their natural
157 equivalents:
158 .Bd -literal -offset indent
159 string -> string
160 number -> int64
161 boolean -> boolean_value
162 nil -> boolean (no value)
163 table -> nvlist
164 .Ed
165 .Pp
166 Likewise, table keys are replaced by string equivalents as follows:
167 .Bd -literal -offset indent
168 string -> no change
169 number -> signed decimal string ("%lld")
170 boolean -> "true" | "false"
171 .Ed
172 .Pp
173 Any collision of table key strings (for example, the string "true" and a
174 true boolean value) will cause a fatal error.
175 .Pp
176 Lua numbers are represented internally as signed 64-bit integers.
177 .Sh LUA STANDARD LIBRARY
178 The following Lua built-in base library functions are available:
179 .Bd -literal -offset indent
180 assert rawlen
181 collectgarbage rawget
182 error rawset
183 getmetatable select
184 ipairs setmetatable
185 next tonumber
186 pairs tostring
187 rawequal type
188 .Ed
189 .Pp
190 All functions in the
191 .Em coroutine ,
192 .Em string ,
193 and
194 .Em table
195 built-in submodules are also available.
196 A complete list and documentation of these modules is available in the Lua
197 manual.
198 .Pp
199 The following functions base library functions have been disabled and are
200 not available for use in channel programs:
201 .Bd -literal -offset indent
202 dofile
203 loadfile
204 load
205 pcall
206 print
207 xpcall
208 .Ed
209 .Sh ZFS API
210 .Ss Function Arguments
211 Each API function takes a fixed set of required positional arguments and
212 optional keyword arguments.
213 For example, the destroy function takes a single positional string argument
214 (the name of the dataset to destroy) and an optional "defer" keyword boolean
215 argument.
216 When using parentheses to specify the arguments to a Lua function, only
217 positional arguments can be used:
218 .Bd -literal -offset indent
219 zfs.sync.destroy("rpool@snap")
220 .Ed
221 .Pp
222 To use keyword arguments, functions must be called with a single argument that
223 is a Lua table containing entries mapping integers to positional arguments and
224 strings to keyword arguments:
225 .Bd -literal -offset indent
226 zfs.sync.destroy({1="rpool@snap", defer=true})
227 .Ed
228 .Pp
229 The Lua language allows curly braces to be used in place of parenthesis as
230 syntactic sugar for this calling convention:
231 .Bd -literal -offset indent
232 zfs.sync.snapshot{"rpool@snap", defer=true}
233 .Ed
234 .Ss Function Return Values
235 If an API function succeeds, it returns 0.
236 If it fails, it returns an error code and the channel program continues
237 executing.
238 API functions do not generate Fatal Errors except in the case of an
239 unrecoverable internal file system error.
240 .Pp
241 In addition to returning an error code, some functions also return extra
242 details describing what caused the error.
243 This extra description is given as a second return value, and will always be a
244 Lua table, or Nil if no error details were returned.
245 Different keys will exist in the error details table depending on the function
246 and error case.
247 Any such function may be called expecting a single return value:
248 .Bd -literal -offset indent
249 errno = zfs.sync.promote(dataset)
250 .Ed
251 .Pp
252 Or, the error details can be retrieved:
253 .Bd -literal -offset indent
254 errno, details = zfs.sync.promote(dataset)
255 if (errno == EEXIST) then
256 assert(details ~= Nil)
257 list_of_conflicting_snapshots = details
258 end
259 .Ed
260 .Pp
261 The following global aliases for API function error return codes are defined
262 for use in channel programs:
263 .Bd -literal -offset indent
264 EPERM ECHILD ENODEV ENOSPC
265 ENOENT EAGAIN ENOTDIR ESPIPE
266 ESRCH ENOMEM EISDIR EROFS
267 EINTR EACCES EINVAL EMLINK
268 EIO EFAULT ENFILE EPIPE
269 ENXIO ENOTBLK EMFILE EDOM
270 E2BIG EBUSY ENOTTY ERANGE
271 ENOEXEC EEXIST ETXTBSY EDQUOT
272 EBADF EXDEV EFBIG
273 .Ed
274 .Ss API Functions
275 For detailed descriptions of the exact behavior of any zfs administrative
276 operations, see the main
277 .Xr zfs 1
278 manual page.
279 .Bl -tag -width "xx"
280 .It Em zfs.debug(msg)
281 Record a debug message in the zfs_dbgmsg log.
282 A log of these messages can be printed via mdb's "::zfs_dbgmsg" command, or
283 can be monitored live by running:
284 .Bd -literal -offset indent
285 dtrace -n 'zfs-dbgmsg{trace(stringof(arg0))}'
286 .Ed
287 .Pp
288 msg (string)
289 .Bd -ragged -compact -offset "xxxx"
290 Debug message to be printed.
291 .Ed
292 .It Em zfs.get_prop(dataset, property)
293 Returns two values.
294 First, a string, number or table containing the property value for the given
295 dataset.
296 Second, a string containing the source of the property (i.e. the name of the
297 dataset in which it was set or nil if it is readonly).
298 Throws a Lua error if the dataset is invalid or the property doesn't exist.
299 Note that Lua only supports int64 number types whereas ZFS number properties
300 are uint64.
301 This means very large values (like guid) may wrap around and appear negative.
302 .Pp
303 dataset (string)
304 .Bd -ragged -compact -offset "xxxx"
305 Filesystem or snapshot path to retrieve properties from.
306 .Ed
307 .Pp
308 property (string)
309 .Bd -ragged -compact -offset "xxxx"
310 Name of property to retrieve.
311 All filesystem, snapshot and volume properties are supported except
312 for 'mounted' and 'iscsioptions.'
313 Also supports the 'written@snap' and 'written#bookmark' properties and
314 the '<user|group><quota|used>@id' properties, though the id must be in numeric
315 form.
316 .Ed
317 .El
318 .Bl -tag -width "xx"
319 .It Sy zfs.sync submodule
320 The sync submodule contains functions that modify the on-disk state.
321 They are executed in "syncing context".
322 .Pp
323 The available sync submodule functions are as follows:
324 .Bl -tag -width "xx"
325 .It Em zfs.sync.destroy(dataset, [defer=true|false])
326 Destroy the given dataset.
327 Returns 0 on successful destroy, or a nonzero error code if the dataset could
328 not be destroyed (for example, if the dataset has any active children or
329 clones).
330 .Pp
331 dataset (string)
332 .Bd -ragged -compact -offset "xxxx"
333 Filesystem or snapshot to be destroyed.
334 .Ed
335 .Pp
336 [optional] defer (boolean)
337 .Bd -ragged -compact -offset "xxxx"
338 Valid only for destroying snapshots.
339 If set to true, and the snapshot has holds or clones, allows the snapshot to be
340 marked for deferred deletion rather than failing.
341 .Ed
342 .It Em zfs.sync.promote(dataset)
343 Promote the given clone to a filesystem.
344 Returns 0 on successful promotion, or a nonzero error code otherwise.
345 If EEXIST is returned, the second return value will be an array of the clone's
346 snapshots whose names collide with snapshots of the parent filesystem.
347 .Pp
348 dataset (string)
349 .Bd -ragged -compact -offset "xxxx"
350 Clone to be promoted.
351 .Ed
352 .El
353 .It Sy zfs.check submodule
354 For each function in the zfs.sync submodule, there is a corresponding zfs.check
355 function which performs a "dry run" of the same operation.
356 Each takes the same arguments as its zfs.sync counterpart and returns 0 if the
357 operation would succeed, or a non-zero error code if it would fail, along with
358 any other error details.
359 That is, each has the same behavior as the corresponding sync function except
360 for actually executing the requested change.
361 For example,
362 .Em zfs.check.destroy("fs")
363 returns 0 if
364 .Em zfs.sync.destroy("fs")
365 would successfully destroy the dataset.
366 .Pp
367 The available zfs.check functions are:
368 .Bl -tag -width "xx"
369 .It Em zfs.check.destroy(dataset, [defer=true|false])
370 .It Em zfs.check.promote(dataset)
371 .El
372 .It Sy zfs.list submodule
373 The zfs.list submodule provides functions for iterating over datasets and
374 properties.
375 Rather than returning tables, these functions act as Lua iterators, and are
376 generally used as follows:
377 .Bd -literal -offset indent
378 for child in zfs.list.children("rpool") do
379 ...
380 end
381 .Ed
382 .Pp
383 The available zfs.list functions are:
384 .Bl -tag -width "xx"
385 .It Em zfs.list.clones(snapshot)
386 Iterate through all clones of the given snapshot.
387 .Pp
388 snapshot (string)
389 .Bd -ragged -compact -offset "xxxx"
390 Must be a valid snapshot path in the current pool.
391 .Ed
392 .It Em zfs.list.snapshots(dataset)
393 Iterate through all snapshots of the given dataset.
394 Each snapshot is returned as a string containing the full dataset name, e.g.
395 "pool/fs@snap".
396 .Pp
397 dataset (string)
398 .Bd -ragged -compact -offset "xxxx"
399 Must be a valid filesystem or volume.
400 .Ed
401 .It Em zfs.list.children(dataset)
402 Iterate through all direct children of the given dataset.
403 Each child is returned as a string containing the full dataset name, e.g.
404 "pool/fs/child".
405 .Pp
406 dataset (string)
407 .Bd -ragged -compact -offset "xxxx"
408 Must be a valid filesystem or volume.
409 .Ed
410 .It Em zfs.list.properties(dataset)
411 Iterate through all user properties for the given dataset.
412 .Pp
413 dataset (string)
414 .Bd -ragged -compact -offset "xxxx"
415 Must be a valid filesystem, snapshot, or volume.
416 .Ed
417 .It Em zfs.list.system_properties(dataset)
418 Returns an array of strings, the names of the valid system (non-user defined)
419 properties for the given dataset.
420 Throws a Lua error if the dataset is invalid.
421 .Pp
422 dataset (string)
423 .Bd -ragged -compact -offset "xxxx"
424 Must be a valid filesystem, snapshot or volume.
425 .Ed
426 .El
427 .El
428 .Sh EXAMPLES
429 .Ss Example 1
430 The following channel program recursively destroys a filesystem and all its
431 snapshots and children in a naive manner.
432 Note that this does not involve any error handling or reporting.
433 .Bd -literal -offset indent
434 function destroy_recursive(root)
435 for child in zfs.list.children(root) do
436 destroy_recursive(child)
437 end
438 for snap in zfs.list.snapshots(root) do
439 zfs.sync.destroy(snap)
440 end
441 zfs.sync.destroy(root)
442 end
443 destroy_recursive("pool/somefs")
444 .Ed
445 .Ss Example 2
446 A more verbose and robust version of the same channel program, which
447 properly detects and reports errors, and also takes the dataset to destroy
448 as a command line argument, would be as follows:
449 .Bd -literal -offset indent
450 succeeded = {}
451 failed = {}
452
453 function destroy_recursive(root)
454 for child in zfs.list.children(root) do
455 destroy_recursive(child)
456 end
457 for snap in zfs.list.snapshots(root) do
458 err = zfs.sync.destroy(snap)
459 if (err ~= 0) then
460 failed[snap] = err
461 else
462 succeeded[snap] = err
463 end
464 end
465 err = zfs.sync.destroy(root)
466 if (err ~= 0) then
467 failed[root] = err
468 else
469 succeeded[root] = err
470 end
471 end
472
473 args = ...
474 argv = args["argv"]
475
476 destroy_recursive(argv[1])
477
478 results = {}
479 results["succeeded"] = succeeded
480 results["failed"] = failed
481 return results
482 .Ed
483 .Ss Example 3
484 The following function performs a forced promote operation by attempting to
485 promote the given clone and destroying any conflicting snapshots.
486 .Bd -literal -offset indent
487 function force_promote(ds)
488 errno, details = zfs.check.promote(ds)
489 if (errno == EEXIST) then
490 assert(details ~= Nil)
491 for i, snap in ipairs(details) do
492 zfs.sync.destroy(ds .. "@" .. snap)
493 end
494 elseif (errno ~= 0) then
495 return errno
496 end
497 return zfs.sync.promote(ds)
498 end
499 .Ed