Pawel Jakub Dawidek wrote: > For some time now I'm watching onnv-notify at opensolaris.org. I'm mostly > interested in ZFS changes, so I 'hg export <revision>' on my downloaded > repository to take a look. The problem is that it is often really hard > to tell what the change really does. Let me give an example: > > Repository: /hg/onnv/onnv-gate > Latest revision: 24fbf2d7a5d7d3a91e33eeff0360a238569231bd > Total changesets: 1 > Log message: > PSARC 2007/197 ZFS hotplug > PSARC 2007/283 FMA for ZFS Phase 2 > 6401126 ZFS DE should verify that diagnosis is still valid before solving > cases > 6500545 ZFS does not handle changes in devids > 6508521 zpool online should warn when it is being used incorrectly > 6509807 ZFS checksum ereports are not being posted > 6514712 zfs_nicenum() doesn't work with perfectly-sized buffers > 6520510 media state doesn't get updated properly on device removal > 6520513 ZFS should have better support for device removal > 6520514 vdev state should be controlled through a single ioctl() > 6520519 ZFS should diagnose faulty devices > 6520947 ZFS DE should close cases which no longer apply > 6521393 ZFS case timeout should be FMD_TYPE_TIME > 6521624 fmd_hash_walk() can dump core when given a bad address > 6521946 ZFS DE needlessly subscribes to faults > 6522085 ZFS dictionary files contain spelling errors > 6523185 vdev_reopen() doesn't correctly propagate state > 6523555 'zpool online' should be less chatty unless something goes wrong > 6527379 zpool(1M) should not try to open faulted devices > 6527700 ZFS should post a sysevent when topology changes > 6528194 lofi should support force unmap and DKIO_DEV_GONE > 6528732 ZFS should store physical device path in addition to /dev path > 6532635 ZFS keeps devices open unnecessarily > 6532979 bad argument to ZFS_IOC_VDEV_ATTACH can panic system > 6567983 deadlock with spa_scrub_thread() and spa_namespace_lock > > There is huge number of changes here. Now I'm trying to take only > "6532635 ZFS keeps devices open unnecessarily" part for inclusion in > FreeBSD 7.0-RELEASE. I looked at the patch, I read explanation for > 6532635, I know part of this change is vdev_set_state() modification, > but is it the only function modified within this single bug? > > Another example. I spent a lot of time trying to track down a lock leak. > This was a lock leak in zap_micro.c. After I found it, I realized that > it is already fixed in OpenSolaris: > > > http://src.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zap_micro.c?r2=4831&r1=2856 > > by this change: > > Repository: /hg/onnv/onnv-gate > Latest revision: 41ec732c6d9fc141be2c6cdccf2f6980f93bd061 > Total changesets: 1 > Log message: > 6584470 zdb needs to initialize the bpl_lock mutex > 6583739 libzpool should check for properly initialized mutexes > 6548010 unbalanced mutex_init/mutex_destroy issues in zfs > 6502263 ZFS needs some more FreeBSD porting love > Contributed by Pawel Dawidek > 6576827 multiple calls to spa_activate() can end up reinitializing all its > mutexes > 6576830 certain spa mutexes and condition variables need some love > Pawel,
I fixed this as part of your intial contribution for '6502263 ZFS needs some more FreeBSD porting love'. When I was doing your changes I detected this issue as well and went ahead and fixed it. So although this wasn't technically in your provided patch, it was your initial changes that led me to detect the problem and fix it. I didn't file another bug as I thought your bug encompassed the spirit of this work. Sorry if that wasn't clearer. Thanks again for contributing! - George
