Tony Hutter

We should wait until #13743 (autoexpand test fix) is in before merging this commit

Don't merge this yet - looks like this is failing `zpool_expand_001`. Let me look into it

I've figured out what was going on. In the test case, we create a 1GB scsi_debug vdev, make a pool, expand the scsi_debug vdev to 2GB, and then expect to...

Updated PR with some fixes. Should be good to go now.

reopening and self-assigning so I can track this with #7132

I'm just trying to understand this architecture... using compression as an example: ``` zio_write_compress() zia_compress() zio_compress_impl() dpusm->compress() ------------------------- dpusm layer- ---------------------------------- sw_provider_compress() kernel_offloader_compress() // does a gzip compresion ``` I'm...

> The software provider/kernel offloader is included with this pull request because it links with ZFS and reuses ZFS functions instead of implementing its own operations. I think the whole...

As mentioned in https://github.com/openzfs/zfs/issues/7366#issuecomment-377400619, the simplest reproducer is to call `sg_logs -t ` on a vdev with `autoexpand=on` and `zed` running. If `autoexpand=off` then it wont work Example: ``` $...

> So maybe the "dev status change" event is causing zed or something else to do an operation on the vdev partition, which in turn kicks off a new "dev...

I tried to reproduce this in `master` and got mixed results. When I force faulted a drive with `zpool offline -f`, the spare did not kick in: ``` pool: tank...