recovery import (zpool import -F) issue with encrypted pool #6916
Assignees
Milestone
Comments
|
I'll try to get a USB drive on Monday and look into this. The error here is that the code is attempting to encrypt new data before you've loaded your keys. The |
|
I think I know what's going on. This should be a simple 1 line fix. Unfortunately, the problem is very hard for me to reproduce and I have not been able to test if it works yet. I will add it to #6864 |
|
That sounds good, thx for your work. I still have the original pool and also a dd backup of it, so I can test any patch you provide. |
|
If you have it and have some time to test it: https://pastebin.com/wBJV59a8 |
|
I will, but the disk is at work so it takes till tomorrow. |
|
Unfortunately I get the same Panic again with the patch applied: |
|
Hmmmm. And you're sure that you are using the new module? That's unfortunate. I was really pretty sure that this would have fixed the problem..... I'll try to come up with some steps to reproduce it. |
|
I just recompiled to make sure I was, but same result. I'm using the DKMS method and I verified that the |
|
Ok. And I'm assuming you re-inserted the module after installing. DKMS doesn't actually do this for you so you would still be running the old code. But if you rebooted it should load the (new) installed version. I will see if I can reproduce the issue locally. |
|
Yeah, I rebooted to make sure. |
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Dec 6, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Dec 21, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Dec 30, 2017
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 2, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 2, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 2, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 2, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 3, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 3, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 3, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 4, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 12, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 16, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 16, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
prometheanfire
pushed a commit
to prometheanfire/zfs
that referenced
this issue
Jan 17, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 17, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 19, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 24, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 24, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
Jan 25, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 26, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Jan 31, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Signed-off-by: Tom Caputi <tcaputi@datto.com>
|
I tested with the latest master version (v0.7.0-277_g0d23f5e) and unfortunately I still have the same issue: |
|
@phreaker0 Feel free to email me at tcaputi@datto.com as well. |
|
@tcaputi |
|
ISCSI will almost definitely not work over WAN. The only way I can think to do this is if you can plug the drive into a spare machine somewhere that you don't mind me having root access to (maybe passthrough to a VM). You could then expose the port over the WAN and privately email me ssh credentials to the VM so I can access it. I will need to be able to reboot this VM a few times to figure out what's going on. I understand if this is too much to ask. |
|
no problem, i will setup a vm and email you the details when ready |
|
Ok. I have found the cause of the issue and will be making a PR for it shortly. Basically, ZIL claiming was accidentally causing user accounting to occur even though the keys weren't loaded yet. Thanks for the help with this @phreaker0 . |
Nasf-Fan
pushed a commit
to Nasf-Fan/zfs
that referenced
this issue
Feb 13, 2018
When performing zil_claim() at pool import time, it is important that encrypted datasets set os_next_write_raw before writing to the zil_header_t. This prevents the code from attempting to re-authenticate the objset_phys_t when it writes it out, which is unnecessary because the zil_header_t is not protected by either objset MAC and impossible since the keys aren't loaded yet. Unfortunately, one of the code paths did not set this flag, which causes failed ASSERTs during 'zpool import -F'. This patch corrects this issue. Reviewed-by: Jorgen Lundman <lundman@lundman.net> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes openzfs#6864 Closes openzfs#6916
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Feb 13, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned. Fixes: openzfs#6916 Signed-off-by: Tom Caputi <tcaputi@datto.com>
13 tasks
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Feb 13, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned. Fixes: openzfs#6916 Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Feb 14, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned. Fixes: openzfs#6916 Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Feb 14, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned. Fixes: openzfs#6916 Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Feb 16, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned for write. As part of this work, the zfsvfs and zvol code was updated so that it no longer lies about owning objsets readonly. Fixes: openzfs#6916 Signed-off-by: Tom Caputi <tcaputi@datto.com>
tcaputi
pushed a commit
to datto/zfs
that referenced
this issue
Feb 20, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned for write. As part of this work, the zfsvfs and zvol code was updated so that it no longer lies about owning objsets readonly. Fixes: openzfs#6916 Signed-off-by: Tom Caputi <tcaputi@datto.com>
behlendorf
pushed a commit
that referenced
this issue
Feb 21, 2018
Currently, ZIL claiming dirties objsets which causes dsl_pool_sync() to attempt to perform user accounting on them. This causes problems for encrypted datasets that were raw received before the system went offline since they cannot perform user accounting until they have their keys loaded. This triggers an ASSERT in zio_encrypt(). Since encryption was added, the code now depends on the fact that data should only be written when objsets are owned. This patch adds a check in dmu_objset_do_userquota_updates() to ensure that useraccounting is only done when the objsets are actually owned for write. As part of this work, the zfsvfs and zvol code was updated so that it no longer lies about owning objsets readonly. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes #6916 Closes #7163
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Describe the problem you're observing
I'm using an ZFS pool on an external USB disk for backup and also for data. Everything
is encrypted by using a top level dataset with activated encryption (aes-256-gcm). Sometimes
the usb disk disconnects (because the cable loosens, ...), in that case the pool i/o will be suspended. After reconnecting the drive I can resume the pool by some zpool command (i think I always uses the zpool clear one). Until the last time it disconnected, i reconnected the drive and uses the command again to resume pool i/o, but it just hanged. After a day or so I rebooted the system (all the zfs/zpool commands were stuck at this point).
I tried to import the zfs pool but it couldn't because of corrupted metadata and suggested recovery import to rollback the last transactions. Attempting to do so freezes the import command and nothing is happening after some panics in the log. (I tried with the zfs_recover =1 option)
What worked is importing the pool in read only mount with recovery: zpool import -F -N -o readonly=on ext
I don't care about the broken pool, as I could send all the snapshots of the data in readonly mode to another pool and most of the backup data too (one dataset snapshot send/recv failed to complete, I don't know why). But maybe there is an issue with recovery code in case of encryption?
I always use the latest kernel and zfs master version on this machine (root filesystem is also on an ZFS SSD pool)
Describe how to reproduce the problem
not easily possible I guess
Include any warning/errors/backtraces from the system logs
The text was updated successfully, but these errors were encountered: