You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because of #6177 and #7304, ZFS datasets associated with zones never get destroyed. (This applies to both transient zone root filesystems and durable datasets.) Separately, we have the constraint that there can be at most one dataset of a given kind on a given ZFS pool. (See #7214.) This doesn't really matter for transient zone root filesystems because their "kind" is always unique. But it does matter for durable datasets. It means that if you have a zone like CockroachDB whose durable dataset is on a pool, and then you expunge the zone, and you want to put another CockroachDB zone on the same sled, we must not try to use the same ZFS pool because the first zone's dataset will still be there. See #7311 for what happens if we do.
Until we fix #6177 and #7304 (and probably #7309), we may want to have the planner avoid re-using the same pool that's holding an expunged zone's durable dataset. (I'm honestly not sure if this is worth doing or if we should just accept this problem until those issues are fixed.)
The text was updated successfully, but these errors were encountered:
Because of #6177 and #7304, ZFS datasets associated with zones never get destroyed. (This applies to both transient zone root filesystems and durable datasets.) Separately, we have the constraint that there can be at most one dataset of a given kind on a given ZFS pool. (See #7214.) This doesn't really matter for transient zone root filesystems because their "kind" is always unique. But it does matter for durable datasets. It means that if you have a zone like CockroachDB whose durable dataset is on a pool, and then you expunge the zone, and you want to put another CockroachDB zone on the same sled, we must not try to use the same ZFS pool because the first zone's dataset will still be there. See #7311 for what happens if we do.
Until we fix #6177 and #7304 (and probably #7309), we may want to have the planner avoid re-using the same pool that's holding an expunged zone's durable dataset. (I'm honestly not sure if this is worth doing or if we should just accept this problem until those issues are fixed.)
The text was updated successfully, but these errors were encountered: