summaryrefslogtreecommitdiffstats
path: root/cddl/contrib/opensolaris/cmd
Commit message (Collapse)AuthorAgeFilesLines
* MFC r332426: allow ZFS pool to have temporary name for duration of current ↵avg2018-05-032-24/+95
| | | | | | | | | | | | | import The change adds -t <name> option to zpool create and -t option to zpool import in its form with an old name and a new name. This allows to import (or create) a pool under a name that's different from its real, permanent name without affecting that name. This is useful when working with VM images or images of other physical systems if they happen to have a ZFS pool with the same name as the host system. Sponsored by: Panzura (porting)
* MFC r332641: MFV man pages update from r329502:mav2018-04-183-13/+111
| | | | 7614 zfs device evacuation/removal.
* MFC r331713: MFV r331712:mav2018-04-161-10/+10
| | | | | | | | | | | 9280 Assertion failure while running removal_with_ganging test with 4K devices illumos/illumos-gate@243952c7eeef020886e3e2e3df99a513df40584a Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Approved by: Garrett D'Amore <garrett@damore.org> Author: Matt Ahrens <Matt.Ahrens@delphix.com>
* MFC r331707: MFV r331706:mav2018-04-162-7/+10
| | | | | | | | | | | | | | | | | | | | | | 9235 rename zpool_rewind_policy_t to zpool_load_policy_t illumos/illumos-gate@5dafeea3ebd2dd77affc802bcb90f63faf01589f We want to be able to pass various settings during import/open of a pool, which are not only related to rewind. Instead of adding a new policy and duplicate a bunch of code, we should just rename rewind_policy to a more generic term like load_policy. For instance, we'd like to set spa->spa_import_flags from the nvlist, rather from a flags parameter passed to spa_import as in some cases we want those flags not only for the import case, but also for the open case. One such flag could be ZFS_IMPORT_MISSING_LOG (as used in zdb) which would allow zfs to open a pool when logs are missing. Reviewed by: Matt Ahrens <matt@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Pavel Zakharov <pavel.zakharov@delphix.com>
* MFC r331701: MFV r331695, 331700: 9166 zfs storage pool checkpointmav2018-04-167-143/+1168
| | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@8671400134a11c848244896ca51a7db4d0f69da4 The idea of Storage Pool Checkpoint (aka zpool checkpoint) deals with exactly that. It can be thought of as a “pool-wide snapshot” (or a variation of extreme rewind that doesn’t corrupt your data). It remembers the entire state of the pool at the point that it was taken and the user can revert back to it later or discard it. Its generic use case is an administrator that is about to perform a set of destructive actions to ZFS as part of a critical procedure. She takes a checkpoint of the pool before performing the actions, then rewinds back to it if one of them fails or puts the pool into an unexpected state. Otherwise, she discards it. With the assumption that no one else is making modifications to ZFS, she basically wraps all these actions into a “high-level transaction”. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Serapheim Dimitropoulos <serapheim.dimitro@delphix.com>
* MFC r331699: Partial MFV r329753:mav2018-04-162-115/+119
| | | | | | | | | | | | | | 8809 libzpool should leverage work done in libfakekernel illumos/illumos-gate@f06dce2c1f0f3af78581e7574f65bfba843ddb6e Reviewed by: Sebastien Roy <sebastien.roy@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Gordon Ross <gordon.w.ross@gmail.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Andrew Stormont <astormont@racktopsystems.com> We do not have libfakekernel, but need to reduce code divergence.
* MFC r331408: MFV r331407: 9213 zfs: sytem typomav2018-04-162-2/+2
| | | | | | | | | illumos/illumos-gate@edc8ef7d921c96b23969898aeb766cb24960bda7 Reviewed by: C Fraire <cfraire@me.com> Reviewed by: Andy Fiddaman <omnios@citrus-it.co.uk> Approved by: Joshua M. Clulow <josh@sysmgr.org> Author: Toomas Soome <tsoome@me.com>
* MFC r329798: MFV r329793, r329795:mav2018-04-161-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 9075 Improve ZFS pool import/load process and corrupted pool recovery illumos/illumos-gate@6f7938128a2c5e23f4b970ea101137eadd1470a1 Some work has been done lately to improve the debugability of the ZFS pool load (and import) process. This includes: https://www.illumos.org/issues/7638: Refactor spa_load_impl into several functions https://www.illumos.org/issues/8961: SPA load/import should tell us why it failed https://www.illumos.org/issues/7277: zdb should be able to print zfs_dbgmsg's To iterate on top of that, there's a few changes that were made to make the import process more resilient and crash free. One of the first tasks during the pool load process is to parse a config provided from userland that describes what devices the pool is composed of. A vdev tree is generated from that config, and then all the vdevs are opened. The Meta Object Set (MOS) of the pool is accessed, and several metadata objects that are necessary to load the pool are read. The exact configuration of the pool is also stored inside the MOS. Since the configuration provided from userland is external and might not accurately describe the vdev tree of the pool at the txg that is being loaded, it cannot be relied upon to safely operate the pool. For that reason, the configuration in the MOS is read early on. In the past, the two configurations were compared together and if there was a mismatch then the load process was aborted and an error was returned. The latter was a good way to ensure a pool does not get corrupted, however it made the pool load process needlessly fragile in cases where the vdev configuration changed or the userland configuration was outdated. Since the MOS is stored in 3 copies, the configuration provided by userland doesn't have to be perfect in order to read its contents. Hence, a new approach has been adopted: The pool is first opened with the untrusted userland configuration just so that the real configuration can be read from the MOS. The trusted MOS configuration is then used to generate a new vdev tree and the pool is re-opened. When the pool is opened with an untrusted configuration, writes are disabled to avoid accidentally damaging it. During reads, some sanity checks are performed on block pointers to see if each DVA points to a known vdev; when the configuration is untrusted, instead of panicking the system if those checks fail we simply avoid issuing reads to the invalid DVAs. This new two-step pool load process now allows rewinding pools accross vdev tree changes such as device replacement, addition, etc. Loading a pool from an external config file in a clustering environment also becomes much safer now since the pool will import even if the config is outdated and didn't, for instance, register a recent device addition. With this code in place, it became relatively easy to implement a long-sought-after feature: the ability to import a pool with missing top level (i.e. non-redundant) devices. Note that since this almost guarantees some loss Of data, this feature is for now restricted to a read-only import. Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Andrew Stormont <andyjstormont@gmail.com> Approved by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org> Author: Pavel Zakharov <pavel.zakharov@delphix.com>
* MFC r329769: MFV r329766: 8962 zdb should work on non-idle poolsmav2018-04-161-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@e144c4e6c90e7d4dccaad6db660ee42b6e7ba04f Currently `zdb` consistently fails to examine non-idle pools as it fails during the `spa_load()` process. The main problem seems to be that `spa_load_verify()` fails as can be seen below: $ sudo zdb -d -G dcenter zdb: can't open 'dcenter': I/O error ZFS_DBGMSG(zdb): spa_open_common: opening dcenter spa_load(dcenter): LOADING disk vdev '/dev/dsk/c4t11d0s0': best uberblock found for spa dcenter. txg 40824950 spa_load(dcenter): using uberblock with txg=40824950 spa_load(dcenter): UNLOADING spa_load(dcenter): RELOADING spa_load(dcenter): LOADING disk vdev '/dev/dsk/c3t10d0s0': best uberblock found for spa dcenter. txg 40824952 spa_load(dcenter): using uberblock with txg=40824952 spa_load(dcenter): FAILED: spa_load_verify failed [error=5] spa_load(dcenter): UNLOADING This change makes `spa_load_verify()` a dryrun when ran from `zdb`. This is done by creating a global flag in zfs and then setting it in `zdb`. Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Andy Stormont <astormont@racktopsystems.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Pavel Zakharov <pavel.zakharov@delphix.com>
* MFC r329732: MFV r329502: 7614 zfs device evacuation/removalmav2018-04-164-89/+932
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@5cabbc6b49070407fb9610cfe73d4c0e0dea3e77 https://www.illumos.org/issues/7614: This project allows top-level vdevs to be removed from the storage pool with “zpool remove”, reducing the total amount of storage in the pool. This operation copies all allocated regions of the device to be removed onto other devices, recording the mapping from old to new location. After the removal is complete, read and free operations to the removed (now “indirect”) vdev must be remapped and performed at the new location on disk. The indirect mapping table is kept in memory whenever the pool is loaded, so there is minimal performance overhead when doing operations on the indirect vdev. The size of the in-memory mapping table will be reduced when its entries become “obsolete” because they are no longer used by any block pointers in the pool. An entry becomes obsolete when all the blocks that use it are freed. An entry can also become obsolete when all the snapshots that reference it are deleted, and the block pointers that reference it have been “remapped” in all filesystems/zvols (and clones). Whenever an indirect block is written, all the block pointers in it will be “remapped” to their new (concrete) locations if possible. This process can be accelerated by using the “zfs remap” command to proactively rewrite all indirect blocks that reference indirect (removed) vdevs. Note that when a device is removed, we do not verify the checksum of the data that is copied. This makes the process much faster, but if it were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be possible to copy the wrong data, when we have the correct data on e.g. the other side of the mirror. Therefore, mirror and raidz devices can not be removed. Reviewed by: Alex Reece <alex@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Richard Laager <rlaager@wiktel.com> Reviewed by: Tim Chase <tim@chase2k.com> Approved by: Garrett D'Amore <garrett@damore.org> Author: Prashanth Sreenivasa <pks@delphix.com>
* MFC r331135:markj2018-03-261-1/+1
| | | | Use __syscall(2) rather than syscall(2) in syscall/tst.args.c.
* MFC r329681: MFV r318941: 7446 zpool create should support efi system partitionmav2018-03-223-25/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@7855d95b30fd903e3918bad5a29b777e765db821 https://github.com/illumos/illumos-gate/commit/7855d95b30fd903e3918bad5a29b777e765db821 https://www.illumos.org/issues/7446 Since we support whole-disk configuration for boot pool, we also will need whole disk support with UEFI boot and for this, zpool create should create efi- system partition. I have borrowed the idea from oracle solaris, and introducing zpool create - B switch to provide an way to specify that boot partition should be created. However, there is still an question, how big should the system partition be. For time being, I have set default size 256MB (thats minimum size for FAT32 with 4k blocks). To support custom size, the set on creation "bootsize" property is created and so the custom size can be set as: zpool create B - o bootsize=34MB rpool c0t0d0 After pool is created, the "bootsize" property is read only. When -B switch is not used, the bootsize defaults to 0 and is shown in zpool get output with value ''. Older zfs/zpool implementations are ignoring this property. https://www.illumos.org/rb/r/219/ Reviewed by: Andrew Stormont <andyjstormont@gmail.com> Reviewed by: Yuri Pankov <yuri.pankov@gmail.com> Approved by: Dan McDonald <danmcd@kebe.com> Author: Toomas Soome <tsoome@me.com> This commit makes no sense for FreeBSD, that is why I blocked the option, but it should be good to stay closer to upstream.
* MFC r329658: MFV r316872: 7502 ztest should run zdb with -G (debug mode)mav2018-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@c3c65d17f7b6689bbd6568a1a1fcc0c4a3bac127 https://github.com/illumos/illumos-gate/commit/c3c65d17f7b6689bbd6568a1a1fcc0c4a3bac127 https://www.illumos.org/issues/7502 Right now ztest executes zdb without -G, so when it has errors, the messages are often not very helpful: Executing zdb -bccsv -d -U /rpool/tmp/zpool.cache ztest zdb: can't open 'ztest': Operation not supported ztest: '/usr/sbin/amd64/zdb -bccsv -d -U /rpool/tmp/zpool.cache ztest' exit code 1 With -G, we'd have: /usr/sbin/amd64/zdb -bccsv -d -U /rpool/tmp/zpool.cache -G ztest zdb: can't open 'ztest': Operation not supported ZFS_DBGMSG(zdb): spa_open_common: opening ztest spa_load(ztest): LOADING spa_load(ztest): FAILED: unable to parse config [error=48] spa_load(ztest): UNLOADING Which indicates where the error came from Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Approved by: Gordon Ross <gordon.w.ross@gmail.com> Author: Pavel Zakharov <pavel.zakharov@delphix.com>
* MFC r329657 (by asomers): Fix memory leaks in zdb introduced by r329508mav2018-03-221-0/+2
| | | | | Reported by: Coverity CID: 1386185
* MFC r329508: MFV r324198: 8081 Compiler warnings in zdbmav2018-03-224-119/+196
| | | | | | | | | | | | | | | | illumos/illumos-gate@3f7978d02b206a6ebc5652c91aa9f42da6fbe00c https://github.com/illumos/illumos-gate/commit/3f7978d02b206a6ebc5652c91aa9f42da6fbe00c https://www.illumos.org/issues/8081 zdb(8) is full of minor problems that generate compiler warnings. On FreeBSD, which uses -WError, the only way to build it is to disable all compiler warnings. This makes it much harder to detect newly introduced bugs. We should cleanup all the warnings. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Alan Somers <asomers@gmail.com>
* MFC r313264:eadler2018-03-191-1/+1
| | | | Avoid using Sun compiler-specific flags.
* MFC r329067:asomers2018-03-101-0/+15
| | | | | | | | | | | | | Fix "zpool add" crash when a replacing vdev has a spare child Fix an assertion in zpool that causes a crash when running any "zpool add" command on a spare that contains a replacing vdev with a spare child. This likely affects Illumos, too. PR: 225546 Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D14138
* MFC r328256:mav2018-02-181-4/+7
| | | | | | | | | | | | | | | MFV r328255: 8972 zfs holds: In scripted mode, do not pad columns with spaces illumos/illumos-gate@e9b7d6e7f7a6477679a35b73eb3934b096b3dd39 https://www.illumos.org/issues/8972: 'zfs holds -H' does not properly output content in scripted mode. It uses a tab instead of two spaces, but it still pads column widths with spaces when it should not. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Allan Jude <allanjude@freebsd.org>
* MFC r328252: MFV r328251: 8652 Tautological comparisons with ZPROP_INVALmav2018-02-181-1/+1
| | | | | | | | | | | | | | | illumos/illumos-gate@4ae5f5f06c6c2d1db8167480f7d9e3b5378ba2f2 https://www.illumos.org/issues/8652: Clang and GCC prefer to use unsigned ints to store enums. With Clang, that causes tautological comparison warnings when comparing a zfs_prop_t or zpool_prop_t variable to the macro ZPROP_INVAL. It's likely that error handling code is being silently removed as a result. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Igor Kozhukhov <igor@dilos.org> Approved by: Gordon Ross <gwr@nexenta.com> Author: Alan Somers <asomers@gmail.com>
* MFC r328234: MFV r328233:mav2018-02-181-1/+5
| | | | | | | | | | | | | | | | | | | | 8898 creating fs with checksum=skein on the boot pools fails ungracefully illumos/illumos-gate@9fa2266d9a78b8366e1cd2d5f050e8b5e37d558c https://www.illumos.org/issues/8898: # zfs create -o checksum=skein rpool/test internal error: Result too large Abort (core dumped) Not a big deal per se, but should be handled correctly. Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by: Andy Stormont <astormont@racktopsystems.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Yuri Pankov <yuri.pankov@nexenta.com> PR: 222199
* MFC r328224: MFV r328220: 8677 Open-Context Channel Programsmav2018-02-183-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@a3b2868063897ff0083dea538f55f9873eec981f https://www.illumos.org/issues/8677 We want to be able to run channel programs outside of synching context. This would greatly improve performance of channel program that just gather information, as we won't have to wait for synching context anymore. This feature should introduce the following: - A new command line flag in "zfs program" to specify our intention to run in open context. - A new flag/option within the channel program ioctl which selects the context. - Appropriate error handling whenever we try a channel program in open-context that contains zfs.sync* expressions. - Documentation for the new feature in the manual pages. Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: Chris Williamson <chris.williamson@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Serapheim Dimitropoulos <serapheim@delphix.com>
* MFC r319671:mav2018-02-171-11/+1
| | | | SHA-512 and Skein have been supported by the boot loader for some time.
* MFC r327888, r327972, r327973:markj2018-02-132-0/+88
| | | | Add "jid" and "jailname" variables to DTrace.
* MFC r326150: zdb: use a heap allocation instead of a huge array on stackavg2017-12-041-1/+9
|
* MFC r326061, r326063:markj2017-11-281-1/+1
| | | | DTrace test fixups.
* MFC r325035: MFV r325013,r325034: 640 number_to_scaled_string is duplicated ↵avg2017-11-162-47/+112
| | | | | | | | | | | | in several commands FreeBSD note: of all libcmdutils functionality ZFS (and other illumos contrib code) currently uses only nicenum() function (which is similar to humanize_number but has some formatting differences). For this reason I decided to not port the whole library. As a result, nicenum.c from libcmdutils is compiled into libzfs and libzpool. This is a bit ugly, but works. If one day we are forced to create libillumos, then the file should be moved to that library.
* MFC r324197: MFV r323913: 8600 ZFS channel programs - snapshotavg2017-11-081-1/+14
|
* MFC r324196: MFV r323912: 8592 ZFS channel programs - rollbackavg2017-11-081-2/+14
|
* MFC r324170: MFV r323794: 8605 zfs channel programs: zfs.exists undocumented ↵avg2017-11-081-0/+12
| | | | and non-working
* MFC r324163: MFV r323530,r323533,r323534: 7431 ZFS Channel Programs, and ↵avg2017-11-084-2/+762
| | | | | | | | | | followups Also MFC-ed are the following fixes: - r324164 Add several new files to the files enabled by ZFS kernel option - r324178 unbreak kernel builds on sparc64 and powerpc - r324194 fix incorrect use of getzfsvfs_impl in r324163 - r324292 really unbreak kernel builds on sparc64 and powerpc64
* MFC r324350: zdb.8: replace with the slighly modified upstream versionavg2017-10-301-157/+201
|
* MFC r324349: MFV r322235: 8067 zdb should be able to dump literal embedded ↵avg2017-10-301-3/+49
| | | | block pointer
* MFC r324344: MFV r316864: 6392 zdb: introduce -V for verbatim importavg2017-10-301-12/+14
|
* MFC r324343: MFV r316862: 6410 teach zdb to perform object lookups by pathavg2017-10-301-84/+227
|
* MFC r324011, r324016: MFV r323535: 8585 improve batching done in zil_commit()avg2017-10-301-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FreeBSD notes: - this MFV reverts FreeBSD commit r314549 to make the merge easier - at present our emulation of cv_timedwait_hires is rather poor, so I elected to use cv_timedwait_sbt directly Please see the differential revision for details. Unfortunately, I did not get any positive reviews, so there could be bugs in the FreeBSD-specific piece of the merge. Hence, the long MFC timeout. illumos/illumos-gate@1271e4b10dfaaed576c08a812f466f6e81370e5e https://github.com/illumos/illumos-gate/commit/1271e4b10dfaaed576c08a812f466f6e81370e5e https://www.illumos.org/issues/8585 The current implementation of zil_commit() can introduce significant latency, beyond what is inherent due to the latency of the underlying storage. The additional latency comes from two main problems: 1. When there's outstanding ZIL blocks being written (i.e. there's already a "writer thread" in progress), then any new calls to zil_commit() will block waiting for the currently oustanding ZIL blocks to complete. The blocks written for each "writer thread" is coined a "batch", and there can only ever be a single "batch" being written at a time. When a batch is being written, any new ZIL transactions will have to wait for the next batch to be written, which won't occur until the current batch finishes. As a result, the underlying storage may not be used as efficiently as possible. While "new" threads enter zil_commit() and are blocked waiting for the next batch, it's possible that the underlying storage isn't fully utilized by the current batch of ZIL blocks. In that case, it'd be better to allow these new threads to generate (and issue) a new ZIL block, such that it could be serviced by the underlying storage concurrently with the other ZIL blocks that are being serviced. 2. Any call to zil_commit() must wait for all ZIL blocks in its "batch" to complete, prior to zil_commit() returning. The size of any given batch is proportional to the number of ZIL transaction in the queue at the time that the batch starts processing the queue; which doesn't occur until the previous batch completes. Thus, if there's a lot of transactions in the queue, the batch could be composed of many ZIL blocks, and each call to zil_commit() will have to wait for all of these writes to complete (even if the thread calling zil_commit() only cared about one of the transactions in the batch). Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Prakash Surya <prakash.surya@delphix.com>
* MFC r324223:asomers2017-10-251-8/+13
| | | | | | | | | | | | | | | | MFV r319743: 8108 zdb -l fails to read labels 2 and 3 illumos/illumos-gate@22c8b9583d07895c16549075a53668d7bc988cf3 https://github.com/illumos/illumos-gate/commit/22c8b9583d07895c16549075a53668d7bc988cf3 https://www.illumos.org/issues/8108 Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by: Igor Kozhukhov <igor@dilos.org> Reviewed by: Andrew Stormont <andyjstormont@gmail.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Yuri Pankov <yuri.pankov@nexenta.com>
* MFC r324222:asomers2017-10-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | MFV r316863: 3871 fix issues introduced by 3604 illumos/illumos-gate@de05b58863498b10283637eb9ac85e92fe85150e https://github.com/illumos/illumos-gate/commit/de05b58863498b10283637eb9ac85e92fe85150e https://www.illumos.org/issues/3871 GCC 4.5.3 on Gentoo Linux did not like a few of the changes made in the issue 3604 patch. It printed an error and a couple of warnings: ../../cmd/zdb/zdb.c: In function 'dump_bpobj': ../../cmd/zdb/zdb.c:1257:3: error: 'for' loop initial declarations are only allowed in C99 mode ../../cmd/zdb/zdb.c:1257:3: note: use option -std=c99 or -std=gnu99 to compile your code ../../cmd/zdb/zdb.c: In function 'dump_deadlist': ../../cmd/zdb/zdb.c:1323:8: warning: too many arguments for format ../../cmd/zdb/zdb.c:1323:8: warning: too many arguments for format Reviewed by: Paul Dagnelie <pcd@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Richard Yao <ryao@gentoo.org>
* MFC r324221:asomers2017-10-252-41/+58
| | | | | | | | | | | | | | | | | MFV r316861: 6866 zdb -l should return non-zero if it fails to find any label illumos/illumos-gate@64723e361134b2a2c45341334174f9d34002f8d0 https://github.com/illumos/illumos-gate/commit/64723e361134b2a2c45341334174f9d34002f8d0 https://www.illumos.org/issues/6866 Need this for #6865. To be generally more scripting-friendly, overload this issue with adding '-q' option which should skip printing any label information. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Yuri Pankov <yuri.pankov@nexenta.com>
* MFC r324220:asomers2017-10-253-3/+22
| | | | | | | | | | | | | | | | | | | | | | MFV r316858 7280 Allow changing global libzpool variables in zdb 7280 Allow changing global libzpool variables in zdb and ztest through command line illumos/illumos-gate@0e60744c982adecd0a1f146f5637475d07ab1069 https://github.com/illumos/illumos-gate/commit/0e60744c982adecd0a1f146f5637475d07ab1069 https://www.illumos.org/issues/7280 zdb is very handy for diagnosing problems with a pool in a safe and quick way. When a pool is in a bad shape, we often want to disable some fail-safes, or adjust some tunables in order to open them. In the kernel, this is done by changing public variables in mdb. The goal of this feature is to add the same capability to zdb and ztest, so that they can change libzpool tuneables from the command line. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Pavel Zakharov <pavel.zakharov@delphix.com>
* MFC r323791: MFV r323790: 8567 Inconsistent return value in zpool_read_labelavg2017-10-041-1/+1
|
* MFC r323355: MFV r323107: 8414 Implemented zpool scrub pause/resumeavg2017-09-262-47/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@1702cce751c5cb7ead878d0205a6c90b027e3de8 https://github.com/illumos/illumos-gate/commit/1702cce751c5cb7ead878d0205a6c90b027e3de8 FreeBSD note: rather than merging the zpool.8 update I copied the zpool scrub section from the illumos zpool.1m to FreeBSD zpool.8 almost verbatim. Now that the illumos page uses the mdoc format, it was an easier option. Perhaps the change is not in perfect compliance with the FreeBSD style, but I think that it is acceptible. https://www.illumos.org/issues/8414 This issue tracks the port of scrub pause from ZoL: https://github.com/zfsonlinux/zfs/pull/6167 Currently, there is no way to pause a scrub. Pausing may be useful when the pool is busy with other I/O to preserve bandwidth. Description This patch adds the ability to pause and resume scrubbing. This is achieved by maintaining a persistent on-disk scrub state. While the state is 'paused' we do not scrub any more blocks. We do however perform regular scan housekeeping such as freeing async destroyed and deadlist blocks while paused. Motivation and Context Scrub pausing can be an I/O intensive operation and people have been asking for the ability to pause a scrub for a while. This allows one to preserve scrub progress while freeing up bandwidth for other I/O. Reviewed by: George Melikov <mail@gmelikov.ru> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed by: Brad Lewis <brad.lewis@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Alek Pinchuk <apinchuk@datto.com>
* MFC: 323253, 323499gnn2017-09-201-3/+0
| | | | | | Add D definitions for the named values in socket.h (gnn@) Fix DTrace test tst_inet_ntop_d: remove definitions are already in libdtrace (lwhsu@)
* MFC r322226: MFV r322223: 8378 crash due to bp in-memory modification of ↵avg2017-09-191-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | nopwrite block illumos/illumos-gate@b7edcb940884114e61382937505433c4c38c0278 https://github.com/illumos/illumos-gate/commit/b7edcb940884114e61382937505433c4c38c0278 https://www.illumos.org/issues/8378 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 to zgd_bp, dbuf_write_ready() could change db_blkptr, and dbuf_write_done() could remove the dirty record. dmu_sync() then sees the stale BP and that the dbuf it not dirty, so it is eligible for nop-writing. The fix is for dmu_sync() to copy db_blkptr to zgd_bp after acquiring the db_mtx. We could still see a stale db_blkptr, but if it is stale then the dirty record will still exist and thus we won't attempt to nopwrite. Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Matthew Ahrens <mahrens@delphix.com>
* MFC r319746,r319747,r319769: 8269 dtrace stddev aggregation is normalized ↵avg2017-09-192-0/+49
| | | | | | | | | | | | | | | | | | | | | | | incorrectly illumos/illumos-gate@79809f9cf402f130667349b2d4007ecd65d63c6f https://github.com/illumos/illumos-gate/commit/79809f9cf402f130667349b2d4007ecd65d63c6f https://www.illumos.org/issues/8269 It seems that currently normalization of stddev aggregation is done incorrectly. We divide both the sum of values and the sum of their squares by the normalization factor. But we should divide the sum of squares by the normalization factor squared to scale the original values properly. FreeBSD note: the actual change was committed in r316853, this commit adds the test files and record merge information. Reviewed by: Bryan Cantrill <bryan@joyent.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Andriy Gapon <avg@FreeBSD.org> Sponsored by: Panzura
* MFC r321963:markj2017-09-051-1/+0
| | | | Rework and simplify the ksyms implementation.
* MFC r322773-r322775:markj2017-08-301-0/+25
| | | | Fix an off-by-two in the llquantize() action parameter validation.
* MFC r321387:ngie2017-08-221-1/+1
| | | | | Don't use incorrect hardcoded path to ksh -- use /usr/bin/env to find ksh instead
* MFC r321843, r321843:markj2017-08-081-28/+0
| | | | Let lockstat use ksyms(4)'s mmap interface.
* MFC r320156, r320185, r320186, r320262, r320452, r321111:mav2017-07-273-42/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MFV r318946: 8021 ARC buf data scatter-ization illumos/illumos-gate@770499e185d15678ccb0be57ebc626ad18d93383 https://github.com/illumos/illumos-gate/commit/770499e185d15678ccb0be57ebc626ad1 8d93383 https://www.illumos.org/issues/8021 The ARC buf data project (known simply as "ABD" since its genesis in the ZoL community) changes the way the ARC allocates `b_pdata` memory from using linea r `void *` buffers to using scatter/gather lists of fixed-size 1KB chunks. This improves ZFS's performance by helping to defragment the address space occupied by the ARC, in particular for cases where compressed ARC is enabled. It could also ease future work to allocate pages directly from `segkpm` for minimal- overhead memory allocations, bypassing the `kmem` subsystem. This is essentially the same change as the one which recently landed in ZFS on Linux, although they made some platform-specific changes while adapting this work to their codebase: 1. Implemented the equivalent of the `segkpm` suggestion for future work mentioned above to bypass issues that they've had with the Linux kernel memory allocator. 2. Changed the internal representation of the ABD's scatter/gather list so it could be used to pass I/O directly into Linux block device drivers. (This feature is not available in the illumos block device interface yet.) FreeBSD notes: - the actual (default) chunk size is 4KB (despite the text above saying 1KB) - we can try to reimplement ABDs, so that they are not permanently mapped into the KVA unless explicitly requested, especially on platforms with scarce KVA - we can try to use unmapped I/O and avoid intermediate allocation of a linear, virtual memory mapped buffer - we can try to avoid extra data copying by referring to chunks / pages in the original ABD Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Prashanth Sreenivasa <pks@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Chris Williamson <chris.williamson@delphix.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Dan Kimmel <dan.kimmel@delphix.com>
* MFC r319672 (by allanjude):mav2017-07-261-4/+8
| | | | New sentences start on new lines, fix two violations
OpenPOWER on IntegriCloud