A collection of patches for pool recovery #4186
Conversation
|
I'm posting this for review and feedback. I was able to use this patch to recreate all the vdev labels on a pool given only its cache file so it could be recovered. I'm not entirely thrilled with overloading the -F argument like this, but I'm also not sure we to add yet another command line option. |
|
Given the way ZFS handles zpool.cache, the file is inherently transient and may or may not exist. If this PR works well, would it make sense to start storing older copies of the zpool.cache file (on analogy to log rotation) rather than just updating it (import of pool already in cache file), adding a pool to it (import of pool not in cache file), expunging a pool from it (export of pool with other pools remaining), or deleting it (export of pool with no other pools remaining) in place? I have for a while been keeping a zpool.cache.bak around which works fine for re-importing -c an exported pool when the real zpool.cache was either blown away or had the pool I want to import expunged from it due to export. If zpool.cache is useful for recovery scenarios, it seems it would be a shame not to have a recent copy or copies of it deliberately kept around just in case. |
|
Log rotating the cache file is a interesting idea. I think that could make a lot of sense. |
|
FWIW, it is common to implement the following in illumos:
The system default cachefile is really just a convenience and when it ceases to be convenient, it becomes hard to find a general-purpose solution. For example, /etc is node-specific, so /etc/zfs/* isn't general-purpose. That said, a directory of cachefiles approach is IMHO better than a single cachefile containing all pools. |
behlendorf
force-pushed
the
vdev-label-recovery
branch
from
2d339a1
to
efc9db7
Compare
behlendorf
changed the title
behlendorf
force-pushed
the
vdev-label-recovery
branch
from
efc9db7
to
9c1200e
Compare
The per-vdev nvlist configuration information can be automatically regenerated given a valid zpool.cache file. Extend the existing '-F' recovery option to add this behavior for missing or corrupt labels. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
This patch will disable the logic which prevents you from rolling back to an arbitrary txg. Normally a txg which is older than the last label update cannot be used for import. There is no way to know that the given txg is consistent with the current configuration. This should only be used as a last resort for pool recovery when you encounter the following failure mode. $ zpool import -o readonly=on -T 123456 tank cannot import 'tank': one or more devices is currently unavailable Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#2452
behlendorf
force-pushed
the
vdev-label-recovery
branch
from
9c1200e
to
27ea1e7
Compare
|
The consensus seems to be for dropping this in favor of Pavel Zakharov's pending work, as discussed in the "SPA import and pool recovery" lightning talk. |
|
Sounds good, I'm looking forward to Pavel's patch. Closing. |
|
where can we track progress for the mentioned work/patch? |
|
@mailinglists35 It's not published anywhere yet, as far as I know. It's mentioned here: |
The per-vdev nvlist configuration information can be automatically
regenerated given a valid zpool.cache file. Extend the existing
'-F' recovery option to add this behavior for missing or corrupt
labels.
Signed-off-by: Brian Behlendorf behlendorf1@llnl.gov