Summary: | Use of redaction bookmarks or redacted datasets on a boot pool renders the pool unbootable | ||
---|---|---|---|
Product: | Base System | Reporter: | Eugene M. Kim <astralblue> |
Component: | bin | Assignee: | freebsd-fs (Nobody) <fs> |
Status: | Open --- | ||
Severity: | Affects Only Me | CC: | allanjude, chris, grahamperrin, markj, tsoome |
Priority: | --- | ||
Version: | 13.1-STABLE | ||
Hardware: | Any | ||
OS: | Any |
Description
Eugene M. Kim
2022-05-23 10:51:38 UTC
I haven't yet attempted to reproduce this, but the described behaviour of enabling a read-only-incompatible feature upon receiving a dataset sounds quite wrong. I do see the following in recv_begin_check_feature_flags_impl(): 543 /* 544 * Receiving redacted streams requires that redacted datasets are 545 * enabled. 546 */ 547 if ((featureflags & DMU_BACKUP_FEATURE_REDACTED) && 548 !spa_feature_is_enabled(spa, SPA_FEATURE_REDACTED_DATASETS)) 549 return (SET_ERROR(ENOTSUP)); so it seems that we are indeed checking this. Perhaps that's not sufficient somehow. Of course, ideally we could handle these features in the loader. (In reply to Mark Johnston from comment #1) Feature flags are tri-state: * disabled - the feature cannot be used in the pool. * enabled (but inactive) - the feature can be used, but is not currently in use. * active (implies enabled) - the feature can be used, and is in use. The quoted piece of code prevents pools with redacted_datasets feature disabled from receiving redacted streams, whereas the bug is about receiving redacted streams in a pool with the feature already enabled (but inactive), resulting in the feature state transitioning from enabled to active. The boot loader rejects the pool if a non-whitelisted read-only-incompatible feature is active; enabled is fine. (In reply to Eugene M. Kim from comment #2) > Feature flags are tri-state: I meant feature properties (of zpool), not feature flags (of zstream). Sorry for the confusion! |