Open FransUrbo opened 10 years ago
Looks like the assert is stale, relying on old style. You can comment it out, or figure out which of the tests fail.
Adding some printk()'s, I get (numerous times - all identical):
ZIO_CHECKSUM_OFF=2, ZIO_CHECKSUM_FUNCTIONS=11, ZIO_COMPRESS_OFF=2, ZIO_COMPRESS_FUNCTIONS=16, ZIO_CRYPT_OFF=2, ZIO_CRYPT_FUNCTIONS=10, DMU_OT_NUMTYPES=55
And just before the SPL Panic:
zp->zp_checksum=7, zp->zp_compress=3, zp->zp_crypt=2, zp->zp_type=196, zp->zp_level=0, zp->zp_copies=3
Full log at http://bayour.com/misc/SPLError.txt.
Changing the way I debug a couple of times, I get this:
zp->zp_type(196) < DMU_OT_NUMTYPES(55)
So somehow/somewhere zp_type is set to an unvalid number. I'm going to take this up on the ZoL issue tracker as well. Just in case...
Ignore for now.
Can't say for certain if this is a ZoL issue or ZFS-Crypto one (can't test without crypto since I have the encryption feature enable on my pool).
Trying to create a filesystem with DEBUG enabled on both spl and zfs gives:
Doing a git blame on zio.c gives:
Commit b128c09f, b4192bb9, 428870ff are all ancient (Dec 3 2008, Dec 13 2012 and May 28 2010 respectivly), 03c6040b is quite new (May 10 2013) and then there's the zfs-crypto one...
After the SPLEerror, zfs hangs. Creating a filesystem without DEBUG enabled works (or did work a few days ago when I was running without it - have cherry-picked some commits since).