Skip to content

Commit 27012e5

Browse files
dsh2dshproblame
dsh2dsh
and
problame
authored
Allow same root_fs for different jobs: sinks and so on (#752)
Because some jobs add client identity to root_fs and other jobs don't do that, we can't reliable detect overlapping of filesystems. And and the same time we need an ability to use equal or overlapped root_fs for different jobs. For instance see this config: ``` - name: "zdisk" type: "sink" root_fs: "zdisk/zrepl" serve: type: "local" listener_name: "zdisk" ``` and ``` - name: "remote-to-zdisk" type: "pull" connect: type: "tls" root_fs: "zdisk/zrepl/remote" ``` As you can see, two jobs have overlapped root_fs, but actually datasets are not overlapped, because job `zdisk` save everything under `zdisk/zrepl/localhost`, because it adds client identity. So they actually use two different filesystems: `zdisk/zrepl/localhost` and `zdisk/zrepl/remote`. And we can't detect this situation during config check. So let's just remove this check, because it's admin's duty to configure correct root_fs's. --------- Co-authored-by: Christian Schwarz <[email protected]>
1 parent 30faaec commit 27012e5

2 files changed

Lines changed: 4 additions & 16 deletions

File tree

‎daemon/job/build_jobs.go‎

Lines changed: 0 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -24,21 +24,6 @@ func JobsFromConfig(c *config.Config, parseFlags config.ParseFlags) ([]Job, erro
2424
js[i] = j
2525
}
2626

27-
// receiving-side root filesystems must not overlap
28-
{
29-
rfss := make([]string, 0, len(js))
30-
for _, j := range js {
31-
jrfs, ok := j.OwnedDatasetSubtreeRoot()
32-
if !ok {
33-
continue
34-
}
35-
rfss = append(rfss, jrfs.ToString())
36-
}
37-
if err := validateReceivingSidesDoNotOverlap(rfss); err != nil {
38-
return nil, err
39-
}
40-
}
41-
4227
return js, nil
4328
}
4429

‎docs/configuration/overview.rst‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -130,7 +130,7 @@ The following high-level steps take place during replication and can be monitore
130130
* Move the **replication cursor** bookmark on the sending side (see below).
131131
* Move the **last-received-hold** on the receiving side (see below).
132132
* Release the send-side step-holds.
133-
133+
134134
The idea behind the execution order of replication steps is that if the sender snapshots all filesystems simultaneously at fixed intervals, the receiver will have all filesystems snapshotted at time ``T1`` before the first snapshot at ``T2 = T1 + $interval`` is replicated.
135135

136136
ZFS Background Knowledge
@@ -258,6 +258,9 @@ On your setup, ensure that
258258

259259
* all ``filesystems`` filter specifications are disjoint
260260
* no ``root_fs`` is a prefix or equal to another ``root_fs``
261+
262+
* For ``sink`` jobs, consider all possible ``root_fs/${client_identity}``.
263+
261264
* no ``filesystems`` filter matches any ``root_fs``
262265

263266
**Exceptions to the rule**:

0 commit comments

Comments
 (0)