[incomplete] October | 10/2015; List of Upstream Illumos changes

[kernelOfTruth]

[applied]

https://www.illumos.org/issues/6386 Fix function call with uninitialized value in vdev_inuse

485c581

[applied]

https://www.illumos.org/issues/6390 Free props in ztest_init()

85802aa

[applied ?]

https://www.illumos.org/issues/5219 l2arc_write_buffers() may write beyond target_sz

illumos/illumos-gate@d7d9a6d

[applied]

https://www.illumos.org/issues/6385 Fix unlocking order in zfs_zget

f3ad9cd

[ZoL]
https://www.illumos.org/issues/5984 zfs clone should not mount the clone if canmount == noauto
#2241
480f626

---

---

[open]

https://www.illumos.org/issues/6434 sa_find_sizes() may compute wrong SA header size

illumos/illumos-gate@3502ed6

(see: #1890 ; 472e7c6 sa_find_sizes() may compute wrong SA header size)

---

https://www.illumos.org/issues/6334 Cannot unlink files when over quota

illumos/illumos-gate@6575bca
(depends on may_delete_now)

https://www.illumos.org/issues/6298 zfs_create_008_neg and zpool_create_023_neg need to be updated for large block support

illumos/illumos-gate@e9316f7

https://www.illumos.org/issues/5963 rmis should be removed from arcstat manpage

illumos/illumos-gate@f34d737

https://www.illumos.org/issues/2605 want to resume interrupted zfs send

illumos/illumos-gate@9c3fd12

6286 ZFS internal error when set large block on bootfs

illumos/illumos-gate@6de9bb5

---

https://www.illumos.org/issues/6281 prefetching should apply to 1MB reads

illumos/illumos-gate@6328027

(depends on Illumos 5987 zfs prefetch code needs work , see: #3765 , #3611 , #3574)

---

https://www.illumos.org/issues/6280 libzfs: unshare_one() could fail with EZFS_SHARENFSFAILED

illumos/illumos-gate@d1672ef

https://www.illumos.org/issues/6249 6249 async_destroy_001_pos fails because it doesn't see 'freeing' prop populated

illumos/illumos-gate@db24175

https://www.illumos.org/issues/6248 6248 zpool_create_008_pos and zpool_create_009_neg can fail intermittently

illumos/illumos-gate@999dc7a

---

---

[processing]

https://www.illumos.org/issues/6292 exporting a pool while an async destroy is running can leave entries in the deferred tree

illumos/illumos-gate@a443cc8

---

https://www.illumos.org/issues/6319 assertion failed in zio_ddt_write: bp->blk_birth == txg

illumos/illumos-gate@b39b744

---

https://www.illumos.org/issues/6288 dmu_buf_will_dirty could be faster

illumos/illumos-gate@0f2e7d0

---

https://www.illumos.org/issues/6295 metaslab_condense's dbgmsg should include vdev id

illumos/illumos-gate@daec38e

---

https://www.illumos.org/issues/6367 spa_config_tryenter incorrectly handles the multiple-lock case

illumos/illumos-gate@e495b6e

---

https://www.illumos.org/issues/6268 zfs diff confused by moving a file to another directory

illumos/illumos-gate@aab0441

---

---

[non-applicable (Illumos- or *BSD-specific]

https://www.illumos.org/issues/6290 zdb -h overflows stack

illumos/illumos-gate@3f84190

(see: [ZOL] 017da6f Fix for recent zdb -h | -i crashes (seg fault) )

https://www.illumos.org/issues/6315 taskq kstat uses the wrong label

illumos/illumos-gate@7c5f01c

[behlendorf]

@kernelOfTruth awesome, this is a great start. We should decide on the best way to track this kind of work. What do you think about either enabling the wiki and tracking this on a wiki page, or perhaps creating a new upstream milestone and opening an issue per-upstream-patch?

[kernelOfTruth]

@behlendorf I'd say, we could go with a mix of both:

A wiki where everyone ((future) devs, community, ...) can contribute to keep the per-month list of upstream changes up-to-date and opening an issue per patch

Not sure how to proceed with the milestone targets (leave it at the current approach ? how is it decided what lands in what milestone ? clarity is needed what major or minor milestone targets are), in my opinion however an additional voting system would be great to gauge how big the demand is for a feature or patch, also to involve the community some more - I'm uncertain whether github supports this but it would be a nice addition.

[behlendorf]

A wiki where everyone ((future) devs, community, ...) can contribute

Sounds good. I've enabled the wiki and created https://github.com/zfsonlinux/zfs/wiki/Illumos-Tracking as a starting point.

As for the milestones at the moment I make a best guess as to what can realistically be accomplished in a given milestone given the available resources. But I think that's probably a separate issue than tracking the Illumos changes.

[gmelikov]

Maybe automatically open an issue on each openZFS commit with label openZFS tracking (for example)?

New issue - we react - easy filter - close if ported\already merged\doesn't need to merge.

Additional plus - we can discuss each openZFS commit in issue, and after that someone (who took the issue - assigned) can start porting.

There's only one minus - more issues. We can use separate repository for it.

I can make a light bot, which will track openZFS commits and open issues.

[behlendorf]

@kernelOfTruth @gmelikov I took the opportunity to throw together a little script which dynamically generates a simple OpenZFS Commit Tracking page. It won't be winning any design awards but it refreshes hourly and as long as we always add OpenZFS XXX to the git commit and new PR summaries it'll automatically link the commits and PRs.

My hope is this'll help us more easily track the outstanding porting work without resorting to opening a new issue for every OpenZFS commit. Although, that's also a pretty reasonable option. I've updated the wiki sidebar to reference the new page.