[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)

I haven't been able to reproduce any panic. I'm running debug bits, with default settings on OmniOS upgraded via `onu` from a nightly build of this PR. I'm using a simple `dd` of `/dev/zero` to a file in the zpool (until ENOSPC, and then repeating in a loop), as well as running `fio` with a mix

[developer] Re: [openzfs/openzfs] 9084 ztest failure: spa->spa_ max_ashift == spa->spa_min_ashift (0xc == 0x9) (#543)

prashks approved this pull request. -- 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/543#pullrequestreview-95582867 -- openzfs-developer

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

@andy-js @rmustacc is this good to RTI? it's passing the build, zloop, and zfstest. -- 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/536#issuecomment-364567269

[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)

This is clearly a use-after-free problem, but it's not clear _why_ this is occurring. I don't know the code in this PR, but I'll try and see if I can reproduce this in-house with `kmem_flags=f` set, so we can get a stack trace of where this buffer was freed. >From the dump posted above: ``` >

[developer] [openzfs/openzfs] 9084 ztest failure: spa->spa_ max_ashift == spa->spa_min_ashift (0xc == 0x9) (#543)

It's possible for the following assertion to be tripped when running ztest: assertion failed for thread 0xf09fca40, thread-id 549: spa->spa_max_ashift == spa->spa_min_ashift (0xc == 0x9), file ../../../uts/common/fs/zfs/vdev_removal.c, line 965 > $c

[developer] Re: [openzfs/openzfs] Merge remote-tracking branch 'illumos/master' into illumos-sync (#535)

Closed #535. -- 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/535#event-1467250055 -- openzfs-developer Archives:

[developer] Re: [openzfs/openzfs] Merge remote-tracking branch 'illumos/master' into illumos-sync (#535)

It looks like we're failing to boot after the upgrade. Closing until we can investigate this further. -- 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/535#issuecomment-364520192

Re: [developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

On Fri, Feb 9, 2018 at 7:33 AM, Schweiss, Chip wrote: > I've been following this review for a while. Sorry, if this is not the > correct place for this comment. > > Personally, I've been doing similar outside zpool import by doing a 'zpool > import -N' then parallel

[developer] Re: [openzfs/openzfs] 7584 Improve 'zpool labelclear' command (#424)

I'll chime in here. There have been a number of cases in the past where I have wanted the moral equivalent to dd if=/dev/zero of=/dev/da0 bs=1M Typically, and this may be FreeBSD specific, it's a case of ZFS thinks the device is unused, then geom attaches to the device, then ZFS magically sees

Re: [developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

I've been following this review for a while. Sorry, if this is not the correct place for this comment. Personally, I've been doing similar outside zpool import by doing a 'zpool import -N' then parallel executing 'zfs mount {folder}' followed by parallel executing 'zfs share {folder}'. My

[developer] Re: [openzfs/openzfs] 7584 Improve 'zpool labelclear' command (#424)

One of the guiding principles for zfs is simple administration and it seems like we're exposing way too many knobs to the administrator. These knobs expose the internals of the product. For example, if I want to clear the labels, why wouldn't I just run `zpool labelclear` and have the command

[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)

Dump is here: https://www.magentacloud.de/lnk/FWLB1qmb -- 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-364382103 --