Snapshot consistency if snapshotting multiple datasets within a single non-recursive 'zfs snapshot' CLI call

[whoschek]

Here is a question around snapshot consistency if snapshotting multiple datasets within a single non-recursive 'zfs snapshot' CLI call:

If the user is executing a recursive snapshot like 'zfs snapshot -r a001@foo a002@foo' then all snapshots will have identical createtxg. So far so good.

Now, what if the user takes a non-recursive snapshot on multiple datasets by omitting the '-r' flag, all within the same CLI invocation, like so: 'zfs snapshot a001@foo a002@foo ... a999@foo' with one thousand snapshots within the same single CLI invocation. Will all the resulting snapshots have identical createtxg a) sometimes, or b) always, or c) never?

[filip-paczynski]

I don't think one can do that.... zfs snapshot allows only one dataset@snapshot param.

[Gendra13]

Yet it does indeed work if you pass multiple arguments, as long as the all belong to the same pool.

[filip-paczynski]

Thanks, might be handy in some scenarios.

[Gendra13]

Will all the resulting snapshots have identical createtxg a) sometimes, or b) always, or c) never?

I don't know the internals so my answer is only based on my experience, but on my system with a limited number (~20) of arguments, all snapshots had the same txg, so I do believe it's b).
However I don't know if this holds true, when you are trying to create thousand of snapshots at once.

[amotin]

As I see, all the snapshot you specify on one command line will always be created at one TXG. If you need to create more than you pass to the command line, you might use channel programs, designed specifically for that purpose.

[whoschek]

Ah, cool. I think that's fine - I can't quite image a good use case for requiring this level of consistency with more than a thousand datasets, which still fits into a command line per SC_ARG_MAX.

Follow up question: What kind of locks, if any, are held during such a long-running operation, and for what other operations could this cause temporary "dataset is busy" errors, if any?

[amotin]

Obviously any long running operations in sync context will block any pool writes after accumulating some dirty data, or any operations requiring immediate transaction commit. But I don't think it should create any explicit errors, other than obvious attempt to destroy something that is referenced, etc.