@lundman pushed 1 commit.
3972768 Do not call dmu_objset_disown twice
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/openzfs/openzfs/pull/489/files/6f85552ff7a285fef0af14f31d322cc82bebd07c..3972768dc18f2f6b4b2c3c90ac9ce516f8e1cf99
Closed #652 via ed81aacb0d0fcbf7e0c0745ea4556655050c26bf.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/652#event-1751355888
--
openzfs:
@Ahrens glad to help a bit getting this forward, but the credit belongs to you,
Tom, Jorgen and all the others who keep on pushing on with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
mav pointed out something to me: dmu_objset_disown() is called in both
zfsvfs_create() and zfsvfs_create_impl() in case of error. At the end of
zfsvfs_create(), remove the if after
`error = zfsvfs_create_impl(zfvp, zfsvfs, os);`
--
You are receiving this because you are subscribed to this
@GernotS That's great to hear! It makes sense that the "Refactor
arc_hdr_realloc_crypt()" commit would address the panics that you were seeing
when using L2ARC + encryption. I think that the other bug (causing an
incorrect MAC on the target when doing encrypted send, causing some panics due
We have a small RAIDZ2 pool:
root@p1c3:/small/test/rs1m# zpool list small
NAMESIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH
ALTROOT
small 2.92T 2.83T 93.5G- - 1%96% 1.00x ONLINE -
root@p1c3:/small/test/rs1m# zfs list -r small
NAME
Change looks good to me, thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/667#issuecomment-407479667
--
openzfs: openzfs-developer
rmustacc commented on this pull request.
> if (strcmp(strval, "") == 0)
error = ENOENT;
}
break;
+ }
Yes, this is correct and generally how we structure it when you have a scope
inside of the case
Reviewed by: Serapheim Dimitropoulos
Reviewed by: Sara Hartse
Reviewed by: Pavel Zakharov
Reviewed by: Matt Ahrens
after running "zfstest" and then using "reboot -d" and "::findleaks", there's a
couple of leaks like the following:
kmem_alloc_8 leak: 2 buffers, 8 bytes each, 16 bytes total
Woo, I contributed! \o/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/489#issuecomment-407324973
--
openzfs: openzfs-developer
Permalink:
so far no further crashes on my side :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/489#issuecomment-407324688
--
openzfs:
11 matches
Mail list logo
