Hi. I hope the list is still there:) During ZFSv28 porting I the following panic: ddt_object_exists() at ddt_object_exists+0x2c ddt_object_prefetch() at ddt_object_prefetch+0x25 ddt_prefetch() at ddt_prefetch+0x9b dsl_dataset_block_freeable() at dsl_dataset_block_freeable+0x41 dmu_tx_hold_spill() at dmu_tx_hold_spill+0xb1 dmu_tx_hold_sa() at dmu_tx_hold_sa+0x1c7 zfs_setattr() at zfs_setattr+0x169a zfs_freebsd_setattr() at zfs_freebsd_setattr+0x4dc VOP_SETATTR_APV() at VOP_SETATTR_APV+0xd3 setfmode() at setfmode+0x10c kern_fchmodat() at kern_fchmodat+0xee syscallenter() at syscallenter+0x1cb syscall() at syscall+0x4c It seems like ddt->ddt_object was NULL. But the most interesting part is that deduplication was turned off. The problem was that ZFS is trying to use dn_spill without checking if we actually have valid blkptr_t in there, so we can sometimes have value which will return true on BP_GET_DEDUP(&dn->dn_spill). The following patch fixes the issue for me. Can someone confirm this is ok? http://people.freebsd.org/~pjd/patches/dmu_tx.c.patch -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20101118/98df9311/attachment.bin>
On 11/17/10 5:05 PM, Pawel Jakub Dawidek wrote:> Hi. > > I hope the list is still there:) > > During ZFSv28 porting I the following panic: > > ddt_object_exists() at ddt_object_exists+0x2c > ddt_object_prefetch() at ddt_object_prefetch+0x25 > ddt_prefetch() at ddt_prefetch+0x9b > dsl_dataset_block_freeable() at dsl_dataset_block_freeable+0x41 > dmu_tx_hold_spill() at dmu_tx_hold_spill+0xb1 > dmu_tx_hold_sa() at dmu_tx_hold_sa+0x1c7 > zfs_setattr() at zfs_setattr+0x169a > zfs_freebsd_setattr() at zfs_freebsd_setattr+0x4dc > VOP_SETATTR_APV() at VOP_SETATTR_APV+0xd3 > setfmode() at setfmode+0x10c > kern_fchmodat() at kern_fchmodat+0xee > syscallenter() at syscallenter+0x1cb > syscall() at syscall+0x4c > > It seems like ddt->ddt_object was NULL. > > But the most interesting part is that deduplication was turned off. >Don''t fix it that way. dn->dn_have_spill means you either have a spill or are about to get one This is more appropriate if (!(dn->dn_phys->dn_flags & DNODE_FLAG_SPILL_BLKPTR)) { ... } else { ... }> The problem was that ZFS is trying to use dn_spill without checking if > we actually have valid blkptr_t in there, so we can sometimes have value > which will return true on BP_GET_DEDUP(&dn->dn_spill). > > The following patch fixes the issue for me. Can someone confirm this is ok? > > http://people.freebsd.org/~pjd/patches/dmu_tx.c.patch > > > > > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code
On Wed, Nov 17, 2010 at 05:20:01PM -0700, Mark Shellenbaum wrote:> Don''t fix it that way. > > dn->dn_have_spill means you either have a spill or are about to get one > > This is more appropriate > > if (!(dn->dn_phys->dn_flags & DNODE_FLAG_SPILL_BLKPTR)) { > ... > } else { > ... > }I saw those two ways of checking this and was wondering what''s the difference. Now I know, thank you, Mark:) -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20101118/8168b491/attachment.bin>