[developer] Re: [openzfs/openzfs] 8086 Add Stride parameter to dd (#357)

Closed #357 via b8290ea5f671630a57c371950c342d58684451e8. -- 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/357#event-1120591971 --

[developer] [openzfs/openzfs] 8380 Assertion failure panic in zio_buf_alloc() (#401)

Reviewed by: George Wilson Reviewed by: Matthew Ahrens Reviewed by: Prashanth Sreenivasa We need to initialize the dn_origin_obj_refd field of a dnode when it is allocated from the kmem cache (or, alternatively, when it is

[developer] Re: [openzfs/openzfs] WIP: Archive the build's "nightly.log" file (#394)

Closed #394 via 1d2bb1c86c216c433219772052d19bf0871cc985. -- 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/394#event-1120368347 --

[developer] [openzfs/openzfs] 8378 crash due to bp in-memory modification of nopwrite block (#400)

Reviewed by: Prakash Surya Reviewed by: George Wilson The problem is that zfs_get_data() supplies a stale zgd_bp to dmu_sync(), which we then nopwrite against. zfs_get_data() doesn't hold any DMU-related locks, so after it copies db_blkptr

[developer] [openzfs/openzfs] 8377 Panic in bookmark deletion (#399)

Reviewed by: Paul Dagnelie Reviewed by: Pavel Zakharov Reviewed by: George Wilson The problem is that when dsl_bookmark_destroy_check() is executed from open context (the pre-check), it fills in dbda_success based on the

[developer] Re: [openzfs/openzfs] 7431 ZFS Channel Programs [updated] (#397)

@arekinath Neat, I think that'd work well. The only downsides I see of using an `NVList` directly are: - Uniqueness checking is an `O(# of keys)` operation (whereas Lua tables use a hash table). I'm sure we could build a workaround to deal with this. - People reading Lua documentation to learn

[developer] [openzfs/openzfs] 8375 Kernel memory leak in nvpair code (#398)

In nvs_embedded(), when we return EINVAL due to reaching the recursion limit, we should free the nvpriv_t that was allocated earlier in the function. Reviewed by: Pavel Zakharov Reviewed by: George Wilson Reviewed by: Prashanth Sreenivasa

[developer] Re: [openzfs/openzfs] 7431 ZFS Channel Programs [updated] (#397)

Instead of having Lua return a table and converting that in C to an nvlist, why not make the Lua code build the nvlist? You can push in a C function (call it `NVList`) that returns a userdata (pointing at a struct with an nvlist pointer in it) with a metatable that has `__index` and

[developer] Re: [openzfs/openzfs] 8264 want support for promoting datasets in libzfs_core (rebase) (#389)

Closed #389 via b9cad68c52caf6f9f35813eb83c98ea4b96b17d0. -- 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/389#event-1120052243 --

[developer] Re: [openzfs/openzfs] 7431 ZFS Channel Programs [updated] (#397)

@dankimmel @ikozhukhov That's right, our take is that the core LUA code is stable (changing only very slowly), so there would be little need to update it in the future. FYI, Here are the response that @cwill provided to the this question previously

[developer] Re: [openzfs/openzfs] 7431 ZFS Channel Programs [updated] (#397)

@ikozhukhov: I believe some of your questions were already answered in the previous thread (on https://github.com/openzfs/openzfs/pull/198). Regarding updating the Lua interpreter, we will update it opportunistically if there's a new feature or bug/security fix that we need, but otherwise there

[developer] Re: [openzfs/openzfs] 7431 ZFS Channel Programs [updated] (#397)

about LUA - it is 3rd party library? what version? do you have your own fixes for it? what are fixes - if they have? (will be better to see special fixes over LUA as separate commit) how you plans update it if needed? -- You are receiving this because you are subscribed to this thread. Reply to

[developer] Re: [openzfs/openzfs] 7910 l2arc_write_buffers() may write beyond target_sz (#310)

grwilson 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/310#pullrequestreview-43429326 -- openzfs-developer

[developer] Re: [openzfs/openzfs] 7910 l2arc_write_buffers() may write beyond target_sz (#310)

grwilson commented on this pull request. > ARCSTAT_INCR(arcstat_l2_size, write_sz); - ARCSTAT_INCR(arcstat_l2_asize, write_asize); - vdev_space_update(dev->l2ad_vdev, write_asize, 0, 0); + ARCSTAT_INCR(arcstat_l2_asize, write_psize); I agree. These variables and their

[developer] Re: [openzfs/openzfs] 7910 l2arc_write_buffers() may write beyond target_sz (#310)

@avg-I pushed 1 commit. 25c6409 l2arc_write_buffers: rename size -> psize for better clarity -- You are receiving this because you are subscribed to this thread. View it on GitHub: