Date: Sat, 3 Oct 2015 10:29:55 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: mav@FreeBSD.org, alc@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: FreeBSD_STABLE_10-i386 - Build #516 - Fixed Message-ID: <1252330668.131.1443868198282.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1474849325.129.1443859639945.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1474849325.129.1443859639945.JavaMail.jenkins@jenkins-9.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD_STABLE_10-i386 - Build #516 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/516/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/516/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/516/console Change summaries: 288576 by mav: Fix r288549 build on stable. For some reason this (odd) code builds on head, but not on stable. 288574 by mav: MFC r286712: 6096 ZFS_SMB_ACL_RENAME needs to cleanup better Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Gordon Ross <gordon.w.ross@gmail.com> Reviewed by: George Wilson <gwilson@zfsmail.com> Approved by: Robert Mustacchi <rm@joyent.com> illumos/illumos-gate@8f5190a540d64d2debee6664bbc740e4c38f5b7f 288573 by mav: MFC r286710: 6093 zfsctl_shares_lookup should only VN_RELE() on zfs_zget() success Reviewed by: Gordon Ross <gwr@nexenta.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Dan McDonald <danmcd@omniti.com> illumos/illumos-gate@0f92170f1ec2737ee5a0e51b5f74093904811452 288572 by mav: MFC r286708: 5959 clean up per-dataset feature count code Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Alex Reece <alex@delphix.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Matthew Ahrens <mahrens@delphix.com> illumos/illumos-gate@ca0cc3918a1789fa839194af2a9245f801a06b1a A ZFS feature flags (large blocks) tracks its refcounts as the number of datasets that have ever used the feature. Several features of this type are planned to be added (new checksum functions). This code should be made common infrastructure rather than duplicating the code for each feature. 288571 by mav: MFC r286705: 5960 zfs recv should prefetch indirect blocks 5925 zfs receive -o origin= Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Author: Paul Dagnelie <pcd@delphix.com> While running 'zfs recv' we noticed that every 128th 8K block required a read. We were seeing that restore_write() was calling dmu_tx_hold_write() and the indirect block was not cached. We should prefetch upcoming indirect blocks to avoid having to go to disk and blocking the restore_write(). Allow an incremental send stream to be received as a clone, even if the stream does not mark it as a clone. 288570 by mav: MFC r286689: 5981 Deadlock in dmu_objset_find_dp illumos/illumos-gate@1d3f896f5469c69c1339890ec3d68e9feddb0343 https://www.illumos.org/issues/5981 When dmu_objset_find_dp gets called with a read lock held, it fans out the work to the task queue. Each task in turn acquires its own read lock before calling the callback. If during this process anyone tries to a acquire a write lock, it will stall all read lock requests.Thus the tasks will never finish, the read lock of the caller will never get freed and the write lock never acquired. deadlock. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan McDonald <danmcd@omniti.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Arne Jansen <jansen@webgods.de> 288569 by mav: MFC r286686: 5269 zpool import slow illumos/illumos-gate@12380e1e701fda28c9e9f32d01cafb54af279eb5 https://www.illumos.org/issues/5269 When importing a pool (at boot or with zpool import) with many filesystem, the process can take minutes. It doesn't matter whether the pool has been exported cleanly or uncleanly. The problem is that each dataset has its own log chain. On import, all datasets have to be checked if there are logs to replay. The idea is to speed up this process by paralellizing it. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Dan McDonald <danmcd@omniti.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Arne Jansen <jansen@webgods.de> 288568 by mav: MFC r286683: 5765 add support for estimating send stream size with lzc_send_space when source is a bookmark Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Christopher Siden <christopher.siden@delphix.com> Reviewed by: Steven Hartland <killing@multiplay.co.uk> Reviewed by: Bayard Bell <buffer.g.overflow@gmail.com> Approved by: Albert Lee <trisk@nexenta.com> Author: Max Grossman <max.grossman@delphix.com> illumos/illumos-gate@643da460c8ca583e39ce053081754e24087f84c8 288567 by mav: MFC r286677: 5695 dmu_sync'ed holes do not retain birth time illumos/illumos-gate@70163ac57e58ace1c5c94dfbe85dca5a974eff36 https://www.illumos.org/issues/5695 In dmu_sync_ready(), a hole block pointer will have it's logical size explicitly set as it's necessary for replay purposes. To "undo" this, dmu_sync_done() will zero out any hole that it finds. This becomes a problem when using the "hole_birth" feature, as this will also wipe out any birth time that might have happened to be set on the hole. ... As a fix, the logic to zero out a hole is only applied to old style holes with a birth time of zero. Holes created with the "hole_birth" feature enabled will have a non-zero birth time, and will be skipped (thus preserving the ltime, type, and level information as well). In addition, zdb was updated to also print the ltime, type, and level information for these new style holes. Previously, only the logical birth time would be printed. Author: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Christopher Siden <christopher.siden@delphix.com> Reviewed by: Bayard Bell <buffer.g.overflow@gmail.com> Approved by: Dan McDonald <danmcd@omniti.com> 288566 by mav: MFC r286655: Fix set of sign extension bugs in r286625. 288565 by mav: MFC r286647: Fix assertion panic caused by combination of r286598 and TRIM. 288564 by mav: MFC r286628: Fix r286625 build on i386. 288563 by mav: MFC r286626: Fix minor mismerge in r286574. 288562 by mav: MFC r286625: 5376 arc_kmem_reap_now() should not result in clearing arc_no_grow Reviewed by: Christopher Siden <christopher.siden@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Steven Hartland <killing@multiplay.co.uk> Reviewed by: Richard Elling <richard.elling@richardelling.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Matthew Ahrens <mahrens@delphix.com> illumos/illumos-gate@2ec99e3e987d8aa273f1e9ba2b983557d058198c 288561 by mav: MFC r286623: Remove extra lock, that IMO only creates potential problems now. 288560 by mav: MFC r286605: 5812 assertion failed in zrl_tryenter(): zr_owner==NULL Reviewed by: George Wilson <george@delphix.com> Reviewed by: Alex Reece <alex@delphix.com> Reviewed by: Will Andrews <will@freebsd.org> Approved by: Gordon Ross <gwr@nexenta.com> Author: Matthew Ahrens <mahrens@delphix.com> illumos/illumos-gate@8df173054ca442cd8845a7364c3edad9d6822351 288559 by mav: MFC r286603: 5810 zdb should print details of bpobj Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Alex Reece <alex@delphix.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Will Andrews <will@freebsd.org> Reviewed by: Simon Klinkert <simon.klinkert@gmail.com> Approved by: Gordon Ross <gwr@nexenta.com> Author: Matthew Ahrens <mahrens@delphix.com> illumos/illumos-gate@732885fca09e11183dd0ea69aaaab5588fb7dbff 288558 by mav: MFC r286600: 5808 spa_check_logs is not necessary on readonly pools Reviewed by: George Wilson <george@delphix.com> Reviewed by: Paul Dagnelie <paul.dagnelie@delphix.com> Reviewed by: Simon Klinkert <simon.klinkert@gmail.com> Reviewed by: Will Andrews <will@freebsd.org> Approved by: Gordon Ross <gwr@nexenta.com> Author: Matthew Ahrens <mahrens@delphix.com> illumos/illumos-gate@23367a2f2caec1ccb4d918bdd0f2fc2c9cadcd06 288557 by mav: MFC r286598: 5701 zpool list reports incorrect "alloc" value for cache devices 288556 by alc: MFC r288281 The conversion of kmem_alloc_attr() from operating on a vm map to a vmem arena in r254025 introduced a bug in the case when an allocation is only partially successful. Specifically, the vm object lock was not being acquired before freeing the allocated pages. To address this bug, replace the existing code by a call to kmem_unback(). Change the type of a variable in kmem_alloc_attr() so that an allocation of two or more gigabytes won't fail. Replace the error handling code in kmem_back() by a call to kmem_unback().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1252330668.131.1443868198282.JavaMail.jenkins>