summaryrefslogtreecommitdiffstats
path: root/sys/cddl
Commit message (Collapse)AuthorAgeFilesLines
* MFC r288204: MFV r288063:delphij2015-10-108-203/+171
| | | | make dataset property de-registration operation O(1)
* MFC r288579: Restore original array_rd_sz semantics.mav2015-10-051-1/+1
| | | | | | Before r278702 prefetch was blocked for I/Os > 1MB, after -- >= 1MB. 1MB I/Os are used for bulk operations in CTL (XCOPY, VERIFY), and disabling prefetch for them reduced the performance.
* MFC r288064 (by avg): 6220 memleak in l2arc on debug buildmav2015-10-031-0/+7
| | | | | | | | | | | | | illumos/illumos-gate/commit/c546f36aa898d913ff77674fb5ff97f15b2e08b4 https://www.illumos.org/issues/6220 5408 introduced a memleak in l2arc, namely the member b_thawed gets leaked when an arc_hdr is realloced from full to l2only. Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com> Reviewed by: Simon Klinkert <simon.klinkert@gmail.com> Reviewed by: George Wilson <george@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Arne Jansen <sensille@gmx.net>
* MFC r287744 (by delphij): Reduce diff against upstream.mav2015-10-031-0/+1
|
* MFC r287706 (by delphij):mav2015-10-032-34/+14
| | | | | | | | | | | | | | | | | | | 6214 zpools going south In r286570 (MFV of r277426) an unprotected write to b_flags to set the compression mode was introduced. This would open a race window where data is partially decompressed, modified, checksummed and written to the pool, resulting in pool corruption due to the partial decompression. Prevent this by reintroducing b_compress illumos/illumos-gate@d4cd038c92c36fd0ae35945831a8fc2975b5272c Illumos issues: 6214 zpools going south https://www.illumos.org/issues/6214
* MFV r287703, r287705 (by delphij):mav2015-10-031-3/+7
| | | | | | | | | | | | | | 6091 avl_add doesn't assert on non-debug builds Use assfail() from libuutil instead of ASSERT() in userland AVL avl_add. illumos/illumos-gate@faa2b6be2fc102adf9ed584fc1a667b4ddf50d78 Illumos issues: 6091 avl_add doesn't assert on non-debug builds https://www.illumos.org/issues/6091
* MFC r287702: 5987 zfs prefetch code needs workmav2015-10-038-669/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the ZFS prefetch code to detect only forward, sequential streams. The following kstats have been added: kstat.zfs.misc.arcstats.sync_wait_for_async How many sync reads have waited for async read to complete. (less is better) kstat.zfs.misc.arcstats.demand_hit_predictive_prefetch How many demand read didn't have to wait for I/O because of predictive prefetch. (more is better) zfetch kstats have been similified to hits, misses, and max_streams, with max_streams representing times when we were not able to create new stream because we already have the maximum number of sequences for a file. The sysctl variable/loader tunable vfs.zfs.zfetch.block_cap have been replaced by vfs.zfs.zfetch.max_distance, which controls maximum bytes to prefetch per stream. illumos/illumos-gate@cf6106c8a0d6598b045811f9650d66e07eb332af Illumos ZFS issues: 5987 zfs prefetch code needs work https://www.illumos.org/issues/5987
* MFC r287283 (by delphij):mav2015-10-031-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a buffer overrun which may lead to data corruption, introduced in r286951 by reinstating changes in r274628. In l2arc_compress_buf(), we allocate a buffer to stash away the compressed data in 'cdata', allocated of l2hdr->b_asize bytes. We then ask zio_compress_data() to compress the buffer, b_l1hdr.b_tmp_cdata, which is of l2hdr->b_asize bytes, and have the compressed size (or original size, if compress didn't gain enough) stored in csize. To pad the buffer to fit the optimal write size, we round up the compressed size to L2 device's vdev_ashift. Illumos code rounds up the size by at most SPA_MINBLOCKSIZE. Because we know csize <= b_asize, and b_asize is integer multiple of SPA_MINBLOCKSIZE, we are guaranteed that the rounded up csize would be <= b_asize. However, this is not necessarily true when we round up to 1 << vdev_ashift, because it could be larger than SPA_MINBLOCKSIZE. So, in the worst case scenario, we are overwriting at most (1 << vdev_ashift - SPA_MINBLOCKSIZE) bytes of memory next to the compressed data buffer. Andriy's original change in r274628 reorganized the code a little bit, by moving the padding to after we determined that the compression was beneficial. At which point, we would check rounded size against the allocated buffer size, and the buffer overrun would not be possible.
* MFC r287280 (by delphij):mav2015-10-031-2/+2
| | | | | | | | | | | In r286705 (Illumos 5960/a2cdcdd), a separate thread is created with curproc as parent. In the case of a send or receive, the curproc would be the userland application that issues the ioctl. This would trigger an assertion failure introduced in Solaris compatibility shims in r196458 when kernel is compiled with INVARIANTS. Fix this by using p0 (proc0 or kernel) as the parent thread when creating the kernel threads.
* MFC r287103 (by avg): 5692 expose the number of hole blocks in a filemav2015-10-033-14/+97
| | | | | | | | | | | | | | | | | | | | | | FreeBSD porting notes: - only kernel-side changes are merged - the new ioctl is not actually implemented yet - thus, the goal is to synchronize DMU code illumos/illumos-gate@2bcf0248e992f292c7b814458bcdce2f004925d6 https://www.illumos.org/issues/5692 we would like to expose the number of hole (sparse) blocks in a file. this can be useful to for example if you want to fill in the holes with some data; knowing the number of holes in advances allows you to report progress on hole filling. We could use SEEK_HOLE to do that but it would be O(n) where n is the number of holes present in the file. Author: Max Grossman <max.grossman@delphix.com> Reviewed by: Adam Leventhal <ahl@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Boris Protopopov <bprotopopov@hotmail.com> Approved by: Richard Lowe <richlowe@richlowe.net>
* MFC r286983 (by avg):mav2015-10-031-1/+1
| | | | fix a mismerge in r286539 (MFV 286538: 5562 ZFS sa_handle's violate...)
* MFC r286951: Restore part of r274628, reverted at r286776.mav2015-10-031-1/+2
|
* MFC r286776: Remove some random accumulated diff from Illumos.mav2015-10-031-19/+13
|
* MFC r286774: 2618 arc.c mistypes in the commentsmav2015-10-031-3/+3
| | | | | | | | | Reviewed by: Jason King <jason.brian.king@gmail.com> Reviewed by: Josef Sipek <jeffpc@josefsipek.net> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Bart Coddens <bart.coddens@gmail.com> illumos/illumos-gate@fc98fea58e89224f6f13d7fae246d6cb5dfa35ea
* MFC r286770: Fix r286766 build with debug.mav2015-10-031-6/+6
|
* MFC r286767: Fix minor mismerge sometimes earlier.mav2015-10-031-4/+4
|
* MFC r286766: 5817 change type of arcs_size from uint64_t to refcount_tmav2015-10-031-25/+108
| | | | | | | | | | | | | | | | | | | | Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <paul.dagnelie@delphix.com> Reviewed by: Adam Leventhal <ahl@delphix.com> Reviewed by: Alex Reece <alex@delphix.com> Reviewed by: Richard Elling <richard.elling@richardelling.com> Approved by: Garrett D'Amore <garrett@damore.org> Author: Prakash Surya <prakash.surya@delphix.com> illumos/illumos-gate@2fd872a734cf486007a8dba532cec52bfb4d40e5 As a way to make it more difficult to introduce bugs into the ARC, and to make it easier to diagnose issues when bugs do creep in, it would be beneficial to change the type of the arc_state_t's arcs_size field to be a refcount_t instead of a uint64_t. This would allow us to make stricter checks when incrementing and decrementing the value with debugging enabled, but still fallback to simple, fast atomic operations when debugging is disabled.
* MFC r286764: 6033 arc_adjust() should search MFU lists for oldest buffermav2015-10-031-2/+2
| | | | | | | | | | | | | | | | | | when adjusting MFU size. illumos/illumos-gate@31c46cf23cd1cf4d66390a983dc5072d7d299ba2 https://www.illumos.org/issues/6033 When we're looking for the list containing oldest buffer we never actually look at the MFU lists even when we try to evict from MFU. looks like a copy paste error, the fix is here: Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com> Reviewed by: Xin Li <delphij@delphij.net> Reviewed by: Prakash Surya <me@prakashsurya.com> Approved by: Matthew Ahrens <mahrens@delphix.com> Author: Alek Pinchuk <alek@nexenta.com> Obtained from: illumos
* MFC r286763: 5497 lock contention on arcs_mtxmav2015-10-037-638/+1624
| | | | | | | | | | | | | | | | Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Richard Elling <richard.elling@richardelling.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Prakash Surya <prakash.surya@delphix.com> illumos/illumos-gate@244781f10dcd82684fd8163c016540667842f203 This patch attempts to reduce lock contention on the current arc_state_t mutexes. These mutexes are used liberally to protect the number of LRU lists within the ARC (e.g. ARC_mru, ARC_mfu, etc). The granularity at which these locks are acquired has been shown to greatly affect the performance of highly concurrent, cached workloads.
* MFC r286762: Revert part of r205231, introducing multiple ARC state locks.mav2015-10-031-278/+148
| | | | | This local implementation will be replaced by one from Illumos to reduce code divergence and make further merges easier.
* Fix r288549 build on stable.mav2015-10-032-6/+1
| | | | For some reason this (odd) code builds on head, but not on stable.
* MFC r286712: 6096 ZFS_SMB_ACL_RENAME needs to cleanup bettermav2015-10-031-0/+1
| | | | | | | | | 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
* MFC r286710:mav2015-10-031-2/+4
| | | | | | | | | | | | 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
* MFC r286708: 5959 clean up per-dataset feature count codemav2015-10-038-153/+182
| | | | | | | | | | | | | | | 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.
* MFC r286705: 5960 zfs recv should prefetch indirect blocksmav2015-10-0330-347/+1295
| | | | | | | | | | | | | | | | 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.
* MFC r286689: 5981 Deadlock in dmu_objset_find_dpmav2015-10-035-4/+40
| | | | | | | | | | | | | | | | | 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>
* MFC r286686: 5269 zpool import slowmav2015-10-0310-60/+239
| | | | | | | | | | | | | | | | | | 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>
* MFC r286683: 5765 add support for estimating send stream size withmav2015-10-034-35/+130
| | | | | | | | | | | | | 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
* MFC r286677: 5695 dmu_sync'ed holes do not retain birth timemav2015-10-032-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* MFC r286655: Fix set of sign extension bugs in r286625.mav2015-10-031-4/+5
|
* MFC r286647: Fix assertion panic caused by combination of r286598 and TRIM.mav2015-10-031-4/+8
|
* MFC r286628: Fix r286625 build on i386.mav2015-10-031-1/+1
|
* MFC r286626: Fix minor mismerge in r286574.mav2015-10-031-42/+42
|
* MFC r286625:mav2015-10-031-95/+158
| | | | | | | | | | | | | 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
* MFC r286623: Remove extra lock, that IMO only creates potential problems now.mav2015-10-031-10/+2
|
* MFC r286605: 5812 assertion failed in zrl_tryenter(): zr_owner==NULLmav2015-10-031-13/+14
| | | | | | | | | | 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
* MFC r286603: 5810 zdb should print details of bpobjmav2015-10-032-5/+3
| | | | | | | | | | | | 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
* MFC r286600: 5808 spa_check_logs is not necessary on readonly poolsmav2015-10-031-1/+1
| | | | | | | | | | | 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
* MFC r286598: 5701 zpool list reports incorrect "alloc" value for cache devicesmav2015-10-031-45/+142
|
* MFC r286593: Local addition and mismerge fix for r286579.mav2015-10-031-14/+12
|
* MFC r286589: 5820 verify failed in zio_done(): BP_EQUAL(bp, io_bp_orig)mav2015-10-031-11/+24
| | | | | | | | | | Reviewed by: Alex Reece <alex@delphix.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Steven Hartland <killing@multiplay.co.uk> Approved by: Garrett D'Amore <garrett@damore.org> Author: Matthew Ahrens <mahrens@delphix.com> illumod/illumos-gate@34e8acef009195effafdcf6417aec385e241796e
* MFC r286587: 5746 more checksumming in zfs sendmav2015-10-034-222/+322
| | | | | | | | | | Reviewed by: Christopher Siden <christopher.siden@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Bayard Bell <buffer.g.overflow@gmail.com> Approved by: Albert Lee <trisk@omniti.com> Author: Matthew Ahrens <mahrens@delphix.com> illumos/illumos-gate@98110f08fa182032082d98be2ddb9391fcd62bf1
* MFC r286579: 5313 Allow I/Os to be aggregated across ZIO priority classesmav2015-10-033-20/+51
| | | | | | | | | | | Reviewed by: Andriy Gapon <avg@FreeBSD.org> Reviewed by: Will Andrews <willa@SpectraLogic.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Justin T. Gibbs <justing@spectralogic.com> illumos/illumos-gate@fe319232d24f4ae183730a5a24a09423d8ab4429
* MFC r286578: Fix r286574 build in user-space.mav2015-10-031-1/+1
|
* MFC r286576: Fix r286570 build with debug.mav2015-10-031-0/+2
|
* MFC r286575: 5056 ZFS deadlock on db_mtx and dn_holdsmav2015-10-0336-304/+627
| | | | | | | | | | Reviewed by: Will Andrews <willa@spectralogic.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Justin Gibbs <justing@spectralogic.com> illumos/illumos-gate@bc9014e6a81272073b9854d9f65dd59e18d18c35
* MFC r286574: 5445 Add more visibility via arcstats; specificallymav2015-10-033-14/+229
| | | | | | | | | | | | | arc_state_t stats and differentiate between "data" and "metadata" Reviewed by: Basil Crow <basil.crow@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Bayard Bell <bayard.bell@nexenta.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Prakash Surya <prakash.surya@delphix.com> illumos/illumos-gate@4076b1bf41cfd9f968a33ed54a7ae76d9e996fe8
* MFC r286570: 5408 managing ZFS cache devices requires lots of RAMmav2015-10-032-581/+903
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reviewed by: Christopher Siden <christopher.siden@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Don Brady <dev.fs.zfs@gmail.com> Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com> Approved by: Garrett D'Amore <garrett@damore.org> Author: Chris Williamson <Chris.Williamson@delphix.com> illumos/illumos-gate@89c86e32293a30cdd7af530c38b2073fee01411c Currently, every buffer cached in the L2ARC is accompanied by a 240-byte header in memory, leading to very high memory consumption when using very large cache devices. These changes significantly reduce this overhead. Currently: L1-only header = 176 bytes L1 + L2 or L2-only header = 176 bytes + 32 byte checksum + 32 byte l2hdr = 240 bytes Memory-optimized: L1-only header = 176 bytes L1 + L2 header = 176 bytes + 32 byte checksum = 208 bytes L2-only header = 96 bytes + 32 byte checksum = 128 bytes So overall: Trunk Optimized +-----------------+ L1-only | 176 B | 176 B | (same) +-----------------+ L1 & L2 | 240 B | 208 B | (saved 32 bytes) +-----------------+ L2-only | 240 B | 128 B | (saved 116 bytes) +-----------------+ For an average blocksize of 8KB, this means that for the L2ARC, the ratio of metadata to data has gone down from about 2.92% to 1.56%. For a 'storage optimized' EC2 instance with 1600GB of SSD and 60GB of RAM, this means that we expect a completely full L2ARC to use (1600 GB * 0.0156) / 60GB = 41% of the available memory, down from 78%. Relnotes: yes
* MFC r286556: Avoid 128K kmem allocations in mzap_upgrade()mav2015-10-031-3/+3
| | | | | | | | | | Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: George Wilson <george@delphix.com> Reviewed by: Steven Hartland <killing@multiplay.co.uk> Approved by: Rich Lowe <richlowe@richlowe.net> illumos/illumos-gate@be3e2ab906b80af79c7b22885f279e45ad8fb995
* MFC r286554: 5769 Cast 'zfs bad bloc' to ULL for x86mav2015-10-031-1/+1
| | | | | | | | | | Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <paul.dagnelie@delphix.com> Reviewed by: Richard PALO <richard@NetBSD.org> Approved by: Dan McDonald <danmcd@omniti.com> illumos/illumos-gate@8c76e0763bcf0029556e106377da859f6492a7ee
OpenPOWER on IntegriCloud