summaryrefslogtreecommitdiff
path: root/cddl/contrib/opensolaris/lib/libzfs
Commit message (Collapse)AuthorAgeFilesLines
...
* MFV r329502: 7614 zfs device evacuation/removalAlexander Motin2018-02-214-20/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Notes: svn path=/head/; revision=329732
* MFV r329718: 8520 7198 lzc_rollback_to should support rolling back to originAndriy Gapon2018-02-211-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@95643f75d23914a3e332adc9661ed51749e9858d https://github.com/illumos/illumos-gate/commit/95643f75d23914a3e332adc9661ed51749e9858d https://www.illumos.org/issues/8520 lzc_rollback_to() should support rolling back to a clone's origin. The current checks in zfs_ioc_rollback() would not allow that because the origin snapshot belongs to a different filesystem. The overly restrictive check was introduced in 7600, but it was not a regression as none of the existing tools provided a way to rollback to the origin. https://www.illumos.org/issues/7198 EINVAL is returned when a dataset does not have any snapshots, so there is nothing to roll back to. Although the code in zfs_do_rollback checks for that condition in advance, it's still possible that the snapshot(s) gets removed after the check and before the rollback sync task is executed. At the moment zfs command would crash when that happens. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Andriy Gapon <avg@FreeBSD.org> MFC after: 2 weeks Notes: svn path=/head/; revision=329719
* MFV r322231:Alexander Motin2018-02-211-0/+1
| | | | | | | | | | | | | | | | | | | | | 8430 dir_is_empty_readdir() doesn't properly handle error from fdopendir() illumos/illumos-gate@ba6e7e6505150388de6dc6a88741164118a421bf https://github.com/illumos/illumos-gate/commit/ba6e7e6505150388de6dc6a88741164118a421bf https://www.illumos.org/issues/8430 we should close dirfd if fdopendir() fails. Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Igor Kozhukhov <igor@dilos.org> Approved by: Robert Mustacchi <rm@joyent.com> Author: Sowrabha Gopal <sowrabha.gopal@delphix.com> Notes: svn path=/head/; revision=329691
* MFV r318941: 7446 zpool create should support efi system partitionAlexander Motin2018-02-212-31/+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. Notes: svn path=/head/; revision=329681
* MFV r316918: 7990 libzfs: snapspec_cb() does not need to call zfs_strdup()Alexander Motin2018-02-201-7/+4
| | | | | | | | | | | | | | | | illumos/illumos-gate@d8584ba6fb7a5e46da1725845b99ae5fab5a4baf https://github.com/illumos/illumos-gate/commit/d8584ba6fb7a5e46da1725845b99ae5fab5a4baf https://www.illumos.org/issues/7990 The snapspec_cb() callback function in libzfs does not need to call zfs_strdup(). Reviewed by: Yuri Pankov <yuri.pankov@gmail.com> Reviewed by: Toomas Soome <tsoome@me.com> Approved by: Matthew Ahrens <mahrens@delphix.com> Author: Marcel Telka <marcel@telka.sk> Notes: svn path=/head/; revision=329668
* MFV r316902: 7745 print error if lzc_* is called before libzfs_core_initAlexander Motin2018-02-201-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@7c13517fff71be473e47531ef4330160c042bedc https://github.com/illumos/illumos-gate/commit/7c13517fff71be473e47531ef4330160c042bedc https://www.illumos.org/issues/7745 The problem is that consumers of `libZFS_Core` that forget to call `libzfs_core_init()` before calling any other function of the library are having a hard time realizing their mistake. The library's internal file descriptor is declared as global static, which is ok, but it is not initialized explicitly; therefore, it defaults to 0, which is a valid file descriptor. If `libzfs_core_init()`, which explicitly initializes the correct fd, is skipped, the ioctl functions return errors that do not have anything to do with `libZFS_Core`, where the problem is actually located. Even though assertions for that existed within `libZFS_Core` for debug builds, they were never enabled because the `-DDEBUG` flag was missing from the compiler flags. This patch applies the following changes: 1. It adds `-DDEBUG` for debug builds of `libZFS_Core` and `libzfs`, to enable their assertions on debug builds. 2. It corrects an assertion within `libzfs`, where a function had been spelled incorrectly (`zpool_prop_unsupported()`) and nobody knew because the `-DDEBUG` flag was missing, and the preprocessor was taking that part of the code away. 3. The library's internal fd is initialized to `-1` and `VERIFY` assertions have been placed to check that the fd is not equal to `-1` before issuing any ioctl. It is important here to note, that the `VERIFY` assertions exist in both debug and non-debug builds. 4. In `libzfs_core_fini` we make sure to never increment the refcount of our fd below 0, and also reset the fd to `-1` when no one refers to it. The reason for this, is for the rare case that the consumer closes all references but then calls one of the library's functions without using `libzfs_core_init()` first, and in the mean time, a previous call to `open()` decided to reuse our previous fd. This scenario would have passed our assertion in Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Serapheim Dimitropoulos <serapheim@delphix.com> Notes: svn path=/head/; revision=329667
* MFV r316901:Alexander Motin2018-02-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7730 libzfs`add_config() leaks config nvl when reading spare/l2cache devices illumos/illumos-gate@105686550ee9cbf5d033166a8a2a5a763667d436 https://github.com/illumos/illumos-gate/commit/105686550ee9cbf5d033166a8a2a5a763667d436 https://www.illumos.org/issues/7730 antares:root:~# mdb /usr/sbin/zpool > ::sysbp _exit > ::run import pool: data id: 2093977168778024605 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: data ONLINE c6t0d0 ONLINE c6t1d0 ONLINE cache c6t2d0 mdb: stop on entry to _exit mdb: target stopped at: 0xfee556ba: nop mdb: You've got symbols! Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libtopo.so.1 libavl.so.1 libnvpair.so.1 ] > ::findleaks -d BYTES LEAKED VMEM_SEG CALLER 4096 10 fda7b000 MMAP 8192 1 fea8d000 MMAP 8192 1 fe76d000 MMAP 8192 1 fe66e000 MMAP 4096 1 fe570000 MMAP 8192 1 fe470000 MMAP 4096 1 fe372000 MMAP 4096 1 fe273000 MMAP Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Yuri Pankov <yuri.pankov@nexenta.com> Notes: svn path=/head/; revision=329665
* MFV r316893:Alexander Motin2018-02-201-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7604 if volblocksize property is the default, it displays as "-" rather than 8K illumos/illumos-gate@4d86c0eab246bdfddc2dd52410ba808433bd6266 https://github.com/illumos/illumos-gate/commit/4d86c0eab246bdfddc2dd52410ba808433bd6266 https://www.illumos.org/issues/7604 If a zvol has the default setting for the "volblocksize" property, it is 8KB. However, it is displayed as "-" (not present), rather than "8K". The problem was introduced by: commit 25228e830e86924a41243343b1de9daf2d7dd43a Author: Matthew Ahrens &lt;mahrens@delphix.com&gt; Date: Thu Nov 17 14:37:24 2016 -0800 7571 non-present readonly numeric ZFS props do not have default value which changed changed get_numeric_property() to indicate that readonly default properties are not present. However, zfs_prop_readonly() returns TRUE for both readonly and set-once properties (e.g. volblocksize). Amusingly, that commit essentially reverted: 6900484 default volblocksize is no longer being reported correctly from November 2009. However, that change was not correct either; the correct solution is to only do this check for "truly readonly" (i.e. not setonce) properties. $ zfs list -t volume -o name,volblocksize NAME VOLBLOCK domain0/group-100/appdata_container-101/appdata_windows_timeflow-102/ archive - domain0/group-100/appdata_container-101/appdata_windows_timeflow-102/ datafile - domain0/group-100/appdata_container-101/appdata_windows_timeflow-102/ external - rpool/dump 128K rpool/swap 4K rpool/swap1 =============================================================================== Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Matthew Ahrens <mahrens@delphix.com> Notes: svn path=/head/; revision=329664
* MFV r316876: 7542 zfs_unmount failed with EZFS_UNSHARENFSFAILEDAlexander Motin2018-02-202-27/+18
| | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@09c9e6dc9b69d10b771bb87e01040ec320a0bfd3 https://github.com/illumos/illumos-gate/commit/09c9e6dc9b69d10b771bb87e01040ec320a0bfd3 https://www.illumos.org/issues/7542 libshare keeps a cached copy of the sharetab listing in memory, which can become out of date if shares are destroyed or created while leaving a libzfs handle open. This results in a spurious unmounting failure when an NFS share exists but isn't in the stale libshare cache. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Reviewed by: Matt Amdur <matt.amdur@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Chris Williamson <chris.williamson@delphix.com> Notes: svn path=/head/; revision=329663
* MFV r316875: 7336 vfork and O_CLOEXEC causes zfs_mount EBUSYAlexander Motin2018-02-201-6/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@873c4903a52d089cd8234b79d24f5a3fc3bccc82 https://github.com/illumos/illumos-gate/commit/873c4903a52d089cd8234b79d24f5a3fc3bccc82 https://www.illumos.org/issues/7336 We can run into a problem where we call into zfs_mount, which in turn calls is_dir_empty, which opens the directory to try and make sure it's empty. The issue with the current approach is that it holds the directory open while it traverses it with readdir, which, due to subtle interaction with the Java JVM, vfork, and exec can cause a tricky race condition resulting in zfs_mount failures. The approach to resolving the issue in this patch is to drop the usage of readdir altogether, and instead rely on the fact that ZFS stores the number of entries contained in a directory using the st_size field of the stat structure. Thus, if the directory in question is a ZFS directory, we can check to see if it's empty by calling stat() and inspecting the st_size field of structure returned. =============================================================================== The root cause appears to be an interesting race between vfork, exec, and zfs_mount's usage of O_CLOEXEC when calling openat. Here's what is going on: 1. We call zfs_mount, and this in turn calls openat to check if the directory is empty, which results in opening the directory we're trying to mount onto, and increment v_count. 2. As we're in the middle of reading the directory, vfork is called by the JVM and proceeds to exec the jspawnhelper utility. As a result of the vfork, we take an additional hold on the directory, which increments v_count a second time. The semantics of vfork mean the parent process will wait for the child process to exit or exec before the parent can continue; at this point the parent is in the middle of zfs_mount, reading the directory to determine if it's empty or not. 3. The child process exec-ing jspawnhelper gets to the relvm call within exec_args (which is called by exec_common). relvm is the function that releases the parent process, allowing the parent to proceed. The problem is, at this point of calling relvm, the child hasn't yet called close_exec which is responsible for closing the file descriptors inherited from the parent process Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Reviewed by: Robert Mustacchi <rm@joyent.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Prakash Surya <prakash.surya@delphix.com> Notes: svn path=/head/; revision=329661
* MFV r316873: 7233 dir_is_empty should open directory with CLOEXECAlexander Motin2018-02-201-2/+10
| | | | | | | | | | | | | | | | | | | illumos/illumos-gate@d420209d9c807f782c1d31f5683be74798142198 https://github.com/illumos/illumos-gate/commit/d420209d9c807f782c1d31f5683be74798142198 https://www.illumos.org/issues/7233 This fixes a race where one thread is executing zfs_mount() while another thread forks and execs. If the fork occurs while the directory is open, the child process will inherit (but not necessarily close immediately) the open fd for the directory, preventing the mount. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Alex Reece <alex@delphix.com> Notes: svn path=/head/; revision=329659
* MFV r323911:Alexander Motin2018-02-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | 8502 illumos#7955 broke delegated datasets when libshare is not present illumos/illumos-gate@1c18e8fbd8db41a9fb39bd3ef7a18ee71ece20da https://github.com/illumos/illumos-gate/commit/1c18e8fbd8db41a9fb39bd3ef7a18ee71ece20da https://www.illumos.org/issues/8502 The code in lib/libzfs/common/libzfs_mount.c already basically handles the case when libshare is not installed. We just need to not fail in zfs_init_libshare_impl. I tested this in lx and things work as expected. I also tested there trying to set sharenfs and sharesmb on the delegated dataset. Neither is allowed from within a zone. The spew of msgs from a native zone is not ZFS specific. I see the same spew simply running the share command. Reviewed by: Robert Mustacchi <rm@joyent.com> Reviewed by: Yuri Pankov <yuripv@gmx.com> Approved by: Richard Lowe <richlowe@richlowe.net> Author: Jerry Jelinek <jerry.jelinek@joyent.com> Notes: svn path=/head/; revision=329505
* MFV r328251: 8652 Tautological comparisons with ZPROP_INVALAlexander Motin2018-01-221-2/+2
| | | | | | | | | | | | | | | | | | 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> Notes: svn path=/head/; revision=328252
* MFV r328249:Alexander Motin2018-01-221-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 8641 "zpool clear" and "zinject" don't work on "spare" or "replacing" vdevs illumos/illumos-gate@2ba5f978a4f9b02da9db1b8cdd9ea5498eb00ad9 https://www.illumos.org/issues/8641: "zpool clear" and "zinject -d" can both operate on specific vdevs, either leaf or interior. However, due to an oversight, neither works on a "spare" or "replacing" vdev. For example: sudo zpool create foo raidz1 c1t5000CCA000081D61d0 c1t5000CCA000186235d0 spare c 1t5000CCA000094115d0 sudo zpool replace foo c1t5000CCA000186235d0 c1t5000CCA000094115d0 $ zpool status foo pool: foo state: ONLINE scan: resilvered 81.5K in 0h0m with 0 errors on Fri Sep 8 10:53:03 2017 config: NAME STATE READ WRITE CKSUM foo ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c1t5000CCA000081D61d0 ONLINE 0 0 0 spare-1 ONLINE 0 0 0 c1t5000CCA000186235d0 ONLINE 0 0 0 c1t5000CCA000094115d0 ONLINE 0 0 0 spares c1t5000CCA000094115d0 INUSE currently in use $ sudo zinject -d spare-1 -A degrade foo cannot find device 'spare-1' in pool 'foo' $ sudo zpool clear foo spare-1 cannot clear errors for spare-1: no such device in pool Even though there was nothing to clear, those commands shouldn't have reported an error. by contrast, trying to clear "raidz1-0" works just fine: $ sudo zpool clear foo raidz1-0 Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Gordon Ross <gwr@nexenta.com> Author: Alan Somers <asomers@gmail.com> Notes: svn path=/head/; revision=328250
* MFV r328233:Alexander Motin2018-01-221-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 Notes: svn path=/head/; revision=328234
* MFV r328231: 8897 zpool online -e fails assertion when run on non-leaf vdevsAlexander Motin2018-01-211-5/+4
| | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@9a551dd645b478816cb11251b19f5034d885bf01 https://www.illumos.org/issues/8897: # zpool online -e test mirror-1 Assertion failed: nvlist_lookup_string(tgt, "path", &pathname) == 0, file ../common/libzfs_pool.c, line 2558, function zpool_vdev_online Abort (core dumped) Not a big deal per se, but should be handled gracefully, same way as 'offline' and 'online' without '-e'. Also reported as: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221408 Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by: Igor Kozhukhov <igor@dilos.org> Approved by: Dan McDonald <danmcd@joyent.com> Author: Yuri Pankov <yuri.pankov@nexenta.com> Notes: svn path=/head/; revision=328232
* MFV r328220: 8677 Open-Context Channel ProgramsAlexander Motin2018-01-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Notes: svn path=/head/; revision=328224
* MFV r325013,r325034: 640 number_to_scaled_string is duplicated in several ↵Andriy Gapon2017-10-271-36/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commands illumos/illumos-gate@0a0551200ecbcd4f1b17560acaeeb7b6c8b0090e https://github.com/illumos/illumos-gate/commit/0a0551200ecbcd4f1b17560acaeeb7b6c8b0090e https://www.illumos.org/issues/640 du(1), df(1m), ls(1), and swap(1m) all include a copy (it appears literally copied) of the 'number_to_scaled_string' function in their source. This should be moved to a shared library and all 4 commands should use this instead. 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. Reviewed by: Sebastian Wiedenroth <wiedi@frubar.net> Reviewed by: Robert Mustacchi <rm@joyent.com> Reviewed by: Yuri Pankov <yuripv@gmx.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Jason King <jason.brian.king@gmail.com> MFC after: 2 weeks Notes: svn path=/head/; revision=325035
* Fix zpool_read_all_labels when vfs.aio.enable_unsafe=0Alan Somers2017-10-251-7/+8
| | | | | | | | | | | | | | Previously, zpool_read_all_labels was trying to do 256KB reads, which are greater than the default MAXPHYS and therefore must go through the slow, unsafe AIO path. Shrink these reads to 112KB so they can use the safe, fast AIO path instead. MFC after: 1 week X-MFC-With: 324568 Sponsored by: Spectra Logic Corp Notes: svn path=/head/; revision=324991
* Optimize zpool_read_all_labels with AIOAlan Somers2017-10-121-8/+33
| | | | | | | | | | | | Read all labels in parallel instead of sequentially MFC after: 3 weeks X-MFC-With: 322854 Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D12495 Notes: svn path=/head/; revision=324568
* MFV r316934: 7340 receive manual origin should override automatic originAndriy Gapon2017-10-061-6/+6
| | | | | | | | | | | | | | | | | | | illumos/illumos-gate@ed4e7a6a5cbc5e8986dc649ad54435210487b102 https://github.com/illumos/illumos-gate/commit/ed4e7a6a5cbc5e8986dc649ad54435210487b102 https://www.illumos.org/issues/7340 When -o origin=<snapshot> is specified as part of a ZFS receive, that origin should override the automatic detection in libzfs. Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Paul Dagnelie <pcd@delphix.com> MFC after: 3 weeks Notes: svn path=/head/; revision=324348
* MFV r316933: 5142 libzfs support raidz root pool (loader project)Andriy Gapon2017-10-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@d5f26ad8122c3762fb16413a17bfb497db86a782 https://github.com/illumos/illumos-gate/commit/d5f26ad8122c3762fb16413a17bfb497db86a782 https://www.illumos.org/issues/5142 the current libzfs only allows simple disk and mirror setup for boot pool, as loader does support booting from raidz, this feature will remove raidz restriction from boot pool setup. FreeBSD note: we have long supported this feature, this commit only removes a small difference in libzfs. Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Andrew Stormont <andyjstormont@gmail.com> Reviewed by: Albert Lee <trisk@omniti.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Toomas Soome <tsoome@me.com> MFC after: 3 weeks Notes: svn path=/head/; revision=324347
* MFV r316931: 6268 zfs diff confused by moving a file to another directoryAndriy Gapon2017-10-061-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@aab04418a72c0a29040a5da7eec08efe19dbef04 https://github.com/illumos/illumos-gate/commit/aab04418a72c0a29040a5da7eec08efe19dbef04 https://www.illumos.org/issues/6268 The zfs diff command presents a description of the changes that have occurred to files within a filesystem between two snapshots. If a file is renamed, the tool is capable of reporting this, e.g.: cd /some/zfs/dataset/subdir mv file0 file1 Will result in a diff record like: R /some/zfs/dataset/subdir/file0 -> /some/zfs/dataset/subdir/file1 Unfortunately, it seems that rename detection only uses the base filename to determine if a file has been renamed or simply modified. This leads to misreporting only the original filename, omitting the more relevant destination filename entirely. For example: cd /some/zfs/dataset/subdir mv file0 ../otherdir/file0 Will result in a diff entry: M /some/zfs/dataset/subdir/file0 But it should really emit: R /some/zfs/dataset/subdir/file0 -> /some/zfs/dataset/otherdir/file0 Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Justin Gibbs <gibbs@scsiguy.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Joshua M. Clulow <josh@sysmgr.org> MFC after: 3 weeks Notes: svn path=/head/; revision=324346
* MFV r316877: 7571 non-present readonly numeric ZFS props do not have default ↵Andriy Gapon2017-10-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | value illumos/illumos-gate@ad2760acbd9c3b479bf632f05c6f03d89830799d https://github.com/illumos/illumos-gate/commit/ad2760acbd9c3b479bf632f05c6f03d89830799d https://www.illumos.org/issues/7571 ZFS displays the default value for non-present readonly numeric (and index) properties. However, these properties default values are not meaningful. Instead, we should display a "-", indicating that they are not present. For example, on a version-12 pool, the usedby* properties are not available, but they show up as the incorrect value "0": 1. zfs get all test12 ... test12 usedbysnapshots 0 - test12 usedbydataset 0 - test12 usedbychildren 0 - test12 usedbyrefreservation 0 - We will be introducing more sometimes-present numeric readonly properties, so it would be nice to fix this. Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Matthew Ahrens <mahrens@delphix.com> MFC after: 3 weeks Notes: svn path=/head/; revision=324345
* MFV r323530,r323533,r323534: 7431 ZFS Channel Programs, and followupsAndriy Gapon2017-10-013-5/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7431 ZFS Channel Programs illumos/illumos-gate@dfc115332c94a2f62058ac7f2bce7631fbd20b3d https://github.com/illumos/illumos-gate/commit/dfc115332c94a2f62058ac7f2bce7631fbd20b3d https://www.illumos.org/issues/7431 ZFS channel programs (ZCP) adds support for performing compound ZFS administrative actions via Lua scripts in a sandboxed environment (with time and memory limits). This initial commit includes both base support for running ZCP scripts, and a small initial library of API calls which support getting properties and listing, destroying, and promoting datasets. Testing: in addition to the included unit tests, channel programs have been in use at Delphix for several months for batch destroying filesystems. The dsl_destroy_snaps_nvl() call has also been replaced with Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Approved by: Garrett D'Amore <garrett@damore.org> Author: Chris Williamson <chris.williamson@delphix.com> 8552 ZFS LUA code uses floating point math illumos/illumos-gate@916c8d881190bd2c3ca20d9fca919aecff504435 https://github.com/illumos/illumos-gate/commit/916c8d881190bd2c3ca20d9fca919aecff504435 https://www.illumos.org/issues/8552 In the LUA interpreter used by "zfs program", the lua format() function accidentally includes support for '%f' and friends, which can cause compilation problems when building on platforms that don't support floating-point math in the kernel (e.g. sparc). Support for '%f' friends (%f %e %E %g %G) should be removed, since there's no way to supply a floating-point value anyway (all numbers in ZFS LUA are int64_t's). Reviewed by: Yuri Pankov <yuripv@gmx.com> Reviewed by: Igor Kozhukhov <igor@dilos.org> Approved by: Dan McDonald <danmcd@joyent.com> Author: Matthew Ahrens <mahrens@delphix.com> 8590 memory leak in dsl_destroy_snapshots_nvl() illumos/illumos-gate@e6ab4525d156c82445c116ecf6b2b874d5e9009d https://github.com/illumos/illumos-gate/commit/e6ab4525d156c82445c116ecf6b2b874d5e9009d https://www.illumos.org/issues/8590 In dsl_destroy_snapshots_nvl(), "snaps_normalized" is not freed after it is added to "arg". Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Steve Gonczi <steve.gonczi@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Dan McDonald <danmcd@joyent.com> Author: Matthew Ahrens <mahrens@delphix.com> FreeBSD notes: - zfs-program.8 manual page is taken almost as is from the vendor repository, no FreeBSD-ification done - fixed multiple instances of NULL being used where an integer is expected - replaced ETIME and ECHRNG with ETIMEDOUT and EDOM respectively This commit adds a modified version of Lua 5.2.4 under sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua, mirroring the upstream. See README.zfs in that directory for the description of Lua customizations. See zfs-program.8 on how to use the new feature. MFC after: 5 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D12528 Notes: svn path=/head/; revision=324163
* MFV r323790: 8567 Inconsistent return value in zpool_read_labelAndriy Gapon2017-09-201-4/+5
| | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@c861bfbd77c4ae780a0341e9cb6926d8b74341cf https://github.com/illumos/illumos-gate/commit/c861bfbd77c4ae780a0341e9cb6926d8b74341cf https://www.illumos.org/issues/8567 If fstat64 fails, pread64 fails, or the label is unintelligible, zpool_read_label will return 0. But if malloc fails, it will return -1. For consistency, it should always return -1 on failure or 0 on success. Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Alan Somers <asomers@gmail.com> MFC after: 2 weeks Notes: svn path=/head/; revision=323791
* MFV r323523: 8331 zfs_unshare returns wrong error code for smb unshare failureAndriy Gapon2017-09-131-4/+6
| | | | | | | | | | | | | | | | | | illumos/illumos-gate@4f4378cc54b7deec3a35c529dc397dbdc325b4bb https://github.com/illumos/illumos-gate/commit/4f4378cc54b7deec3a35c529dc397dbdc325b4bb https://www.illumos.org/issues/8331 zfs_unshare returns EZFS_UNSHARENFSFAILED on error for all share types. Reviewed by: Marcel Telka <marcel@telka.sk> Reviewed by: Toomas Soome <tsoome@me.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Andrew Stormont <astormont@racktopsystems.com> MFC after: 4 weeks Notes: svn path=/head/; revision=323525
* MFV r316932: 6280 libzfs: unshare_one() could fail with EZFS_SHARENFSFAILEDAndriy Gapon2017-09-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@d1672efb6feac57c42788e27f739dfa3c4f3baf7 https://github.com/illumos/illumos-gate/commit/d1672efb6feac57c42788e27f739dfa3c4f3baf7 https://www.illumos.org/issues/6280 The unshare_one() in libzfs could fail with EZFS_SHARENFSFAILED at line 834 here: 831 /* make sure libshare initialized */ 832 if ((err = zfs_init_libshare(hdl, SA_INIT_SHARE_API)) != SA_OK) { 833 free(mntpt); /* don't need the copy anymore */ 834 return (zfs_error_fmt(hdl, EZFS_SHARENFSFAILED, 835 dgettext(TEXT_DOMAIN, "cannot unshare '%s': %s"), 836 name, _sa_errorstr(err))); 837 } The correct error should be EZFS_UNSHARENFSFAILED instead. Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by: Dan McDonald <danmcd@omniti.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Gordon Ross <gwr@nexenta.com> Author: Marcel Telka <marcel.telka@nexenta.com> MFC after: 4 weeks Notes: svn path=/head/; revision=323524
* MFV r323107: 8414 Implemented zpool scrub pause/resumeAndriy Gapon2017-09-093-12/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 after: 2 weeks Notes: svn path=/head/; revision=323355
* zfsd(8): Close a race condition when onlining a disk parititionAlan Somers2017-08-242-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | When inserting a partitioned disk, devfs and geom will announce the whole disk before they announce the partition. If the partition containing ZFS extends to one of the disk's extents, then zfsd will see a ZFS label on the whole disk and attempt to online it. ZFS is smart enough to activate the partition instead of the whole disk, but only if GEOM has already created the partition's provider. cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c Add a zpool_read_all_labels method. It's similar to zpool_read_label, but it will return the number of labels found. cddl/usr.sbin/zfsd/zfsd_event.cc When processing a DevFS CREATE event, only online a VDEV if we can read all four ZFS labels. Reviewed by: mav MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D11920 Notes: svn path=/head/; revision=322854
* MFV r322229: 7600 zfs rollback should pass target snapshot to kernelAndriy Gapon2017-08-081-7/+12
| | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@77b171372ed21642e04c873ef1e87fe2365520df https://github.com/illumos/illumos-gate/commit/77b171372ed21642e04c873ef1e87fe2365520df https://www.illumos.org/issues/7600 At present, the kernel side code seems to blindly rollback to whatever happens to be the latest snapshot at the time when the rollback task is processed. The expected target's name should be passed to the kernel driver and the sync task should validate that the target exists and that it is the latest snapshot indeed. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Andriy Gapon <avg@FreeBSD.org> MFC after: 3 weeks Notes: svn path=/head/; revision=322230
* MFV r322217: 8418 zfs_prop_get_table() call in zfs_validate_name() is a no-opAndriy Gapon2017-08-081-1/+0
| | | | | | | | | | | | | | | | | | | illumos/illumos-gate@e09ba01dcda5e24964b8632718777b39166d86e4 https://github.com/illumos/illumos-gate/commit/e09ba01dcda5e24964b8632718777b39166d86e4 https://www.illumos.org/issues/8418 The following line in zfs_validate_name() is just a no-op and it should be removed: 108 (void) zfs_prop_get_table(); Reviewed by: Vitaliy Gusev <gusev.vitaliy@icloud.com> Approved by: Matthew Ahrens <mahrens@delphix.com> Author: Marcel Telka <marcel@telka.sk> MFC after: 2 weeks Notes: svn path=/head/; revision=322218
* Add compat shim part missed at r305197.Alexander Motin2017-08-021-0/+3
| | | | | | | | | | | This fixes compatibility between old kernel and new ZFS tools. It seems to be tradition to forget it. :( PR: 221112 MFC after: 3 days Notes: svn path=/head/; revision=321921
* MFV r318946: 8021 ARC buf data scatter-izationAndriy Gapon2017-06-201-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@770499e185d15678ccb0be57ebc626ad18d93383 https://github.com/illumos/illumos-gate/commit/770499e185d15678ccb0be57ebc626ad18d93383 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 linear `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 after: 3 weeks Notes: svn path=/head/; revision=320156
* MFV r319945,r319946: 8264 want support for promoting datasets in libzfs_coreAndriy Gapon2017-06-141-13/+7
| | | | | | | | | | | | | | | | | | illumos/illumos-gate@a4b8c9aa65a0a735aba318024a424a90d7b06c37 https://github.com/illumos/illumos-gate/commit/a4b8c9aa65a0a735aba318024a424a90d7b06c37 https://www.illumos.org/issues/8264 Oddly there is a lzc_clone function, but no lzc_promote function. Reviewed by: Andriy Gapon <avg@FreeBSD.org> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan McDonald <danmcd@kebe.com> Approved by: Dan McDonald <danmcd@kebe.com> Author: Andrew Stormont <astormont@racktopsystems.com> MFC after: 1 week Notes: svn path=/head/; revision=319947
* MFV r319740: 8168 NULL pointer dereference in zfs_create()Andriy Gapon2017-06-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@690031d326342fa4ea28b5e80f1ad6a16281519d https://github.com/illumos/illumos-gate/commit/690031d326342fa4ea28b5e80f1ad6a16281519d https://www.illumos.org/issues/8168 If we manage to export the pool on which we are creating a dataset (filesystem or zvol) between entering libzfs`zfs_create() and libzfs`zpool_open() call (for which we never check the return value) we end up dereferencing a NULL pointer in libzfs`zpool_close(). This was discovered on ZFS on Linux. The same issue can be reproduced on Illumos running in parallel: while :; do zpool import -d /tmp testpool ; zpool export testpool ; done while :; do zfs create testpool/fs; zfs destroy testpool/fs ; done Eventually this will result in several core dumps like this one: [root@52-54-00-d3-7a-01 /cores]# mdb core.zfs.4244 Loading modules: [ libumem.so.1 libc.so.1 libtopo.so.1 libavl.so.1 libnvpair.so.1 ld.so.1 ] > ::stack libzfs.so.1`zpool_close+0x17(0, 0, 0, 8047450) libzfs.so.1`zfs_create+0x1bb(8090548, 8047e6f, 1, 808cba8) zfs_do_create+0x545(2, 8047d74, 80778a0, 801, 0, 3) main+0x22c(8047d2c, fef5c6e8, 8047d64, 8055a17, 3, 8047d70) _start+0x83(3, 8047e64, 8047e68, 8047e6f, 0, 8047e7b) > Fix and reproducer (systemtap): https://github.com/zfsonlinux/zfs/pull/6096 Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: loli10K <ezomori.nozomu@gmail.com> MFC after: 2 weeks Notes: svn path=/head/; revision=319751
* MFV r316922: 5380 receive of a send -p stream doesn't need to try renaming ↵Andriy Gapon2017-05-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | snapshots illumos/illumos-gate@471a88e499c660844f4590487ce7c4d5a7090294 https://github.com/illumos/illumos-gate/commit/471a88e499c660844f4590487ce7c4d5a7090294 https://www.illumos.org/issues/5380 A stream created with zfs send -p -I contains properties of all snapshots of a given dataset as opposed to only properties of snapshots in a given range. Not only this is suboptimal but the receive code also does not filter properties by the range. So, properties of earlier snapshots would be updated even though the snapshots themselves are not in the stream (just their properties). Given that modifying the snapshot properties requires a TXG sync and that the snapshots are updated one by one the described behavior may lead to a sever performance penalty. Reviewed by: Paul Dagnelie <pcd@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Andriy Gapon <avg@FreeBSD.org> MFC after: 3 weeks Notes: svn path=/head/; revision=318831
* MFC r316908: 7541 zpool import/tryimport ioctl returns ENOMEM because ↵Andriy Gapon2017-05-242-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | provided buffer is too small for config illumos/illumos-gate@8b65a70b763232c90a91f31eb2010314c02ed338 https://github.com/illumos/illumos-gate/commit/8b65a70b763232c90a91f31eb2010314c02ed338 https://www.illumos.org/issues/7541 When calling zpool import, zpool does a few ioctls to ZFS. zpool allocates a buffer in userland and passes it to the kernel so that ZFS can copy info into it. ZFS will use it to put the nvlist that describes the pool configuration. If the allocated buffer is too small, ZFS will return ENOMEM and the call will have to be redone. This wastes CPU time and slows down the import process. This happens very often for the ZFS_IOC_POOL_TRYIMPORT call. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Pavel Zakharov <pavel.zakharov@delphix.com> MFC after: 2 weeks Notes: svn path=/head/; revision=318819
* MFV 316894Josh Paetzel2017-04-252-17/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7252 7628 compressed zfs send / receive illumos/illumos-gate@5602294fda888d923d57a78bafdaf48ae6223dea https://github.com/illumos/illumos-gate/commit/5602294fda888d923d57a78bafdaf48ae6223dea https://www.illumos.org/issues/7252 This feature includes code to allow a system with compressed ARC enabled to send data in its compressed form straight out of the ARC, and receive data in its compressed form directly into the ARC. https://www.illumos.org/issues/7628 We should have longer, more readable versions of the ZFS send / recv options. 7628 create long versions of ZFS send / receive options Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Sebastien Roy <sebastien.roy@delphix.com> Reviewed by: David Quigley <dpquigl@davequigley.com> Reviewed by: Thomas Caputi <tcaputi@datto.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Dan Kimmel <dan.kimmel@delphix.com> Notes: svn path=/head/; revision=317414
* MFV 316891Josh Paetzel2017-04-213-16/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7386 zfs get does not work properly with bookmarks illumos/illumos-gate@edb901aab9c738b5eb15aa55933e82b0f2f9d9a2 https://github.com/illumos/illumos-gate/commit/edb901aab9c738b5eb15aa55933e82b0f2f9d9a2 https://www.illumos.org/issues/7386 The zfs get command does not work with the bookmark parameter while it works properly with both filesystem and snapshot: # zfs get -t all -r creation rpool/test NAME PROPERTY VALUE SOURCE rpool/test creation Fri Sep 16 15:00 2016 - rpool/test@snap creation Fri Sep 16 15:00 2016 - rpool/test#bkmark creation Fri Sep 16 15:00 2016 - # zfs get -t all -r creation rpool/test@snap NAME PROPERTY VALUE SOURCE rpool/test@snap creation Fri Sep 16 15:00 2016 - # zfs get -t all -r creation rpool/test#bkmark cannot open 'rpool/test#bkmark': invalid dataset name # The zfs get command should be modified to work properly with bookmarks too. Reviewed by: Simon Klinkert <simon.klinkert@gmail.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Approved by: Matthew Ahrens <mahrens@delphix.com> Author: Marcel Telka <marcel@telka.sk> Notes: svn path=/head/; revision=317267
* MFV r316693:Pedro F. Giffuni2017-04-101-1/+1
| | | | | | | | | | | | | | | | | | 8046 Let calloc() do the multiplication in libzfs_fru_refresh https://github.com/illumos/illumos-gate/commit/5697e03e6e3e2697f56ae341c7c8ce79680d6a2e https://www.illumos.org/issues/8046 Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Pedro Giffuni <pfg@freebsd.org> MFC after: 3 days Notes: svn path=/head/; revision=316695
* MFV r308989: 6428 set canmount=off on unmounted filesystem tries toAndriy Gapon2016-11-241-1/+1
| | | | | | | | | | | unmount children This is a cosmetic and bookkeeping change as the actual change is already in FreeBSD. See r297521, r304520, r308985. Notes: svn path=/head/; revision=309096
* revert r304520, set canmount=on is not supposed to mount the filesystemAndriy Gapon2016-11-221-8/+3
| | | | | | | | | | | | | Not sure where I got the idea that it should. See https://github.com/openzfs/openzfs/pull/218 Reported by: mahrens Pointyhat to: avg MFC after: 5 days Notes: svn path=/head/; revision=308985
* zfsbootcfg: a simple tool to set next boot (one time) options for zfsbootAndriy Gapon2016-10-292-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (gpt)zfsboot will read one-time boot directives from a special ZFS pool area. The area was previously described as "Boot Block Header", but currently it is know as Pad2, marked as reserved and is zeroed out on pool creation. The new code interprets data in this area, if any, using the same format as boot.config. The area is immediately wiped out. Failure to parse the directives results in a reboot right after the cleanup. Otherwise the boot sequence proceeds as usual. zfsbootcfg writes zfsboot arguments specified on its command line to the Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and vfs.zfs.boot.primary_vdev kenv variables that are set by loader during boot. Please see the manual page for more. Thanks to all who reviewed, contributed and made suggestions! There are many potential improvements to the feature, please see the review for details. Reviewed by: wblock (docs) Discussed with: jhb, tsoome MFC after: 3 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D7612 Notes: svn path=/head/; revision=308089
* MFV r302660: 6314 buffer overflow in dsl_dataset_nameAlexander Motin2016-09-019-57/+58
| | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@9adfa60d484ce2435f5af77cc99dcd4e692b6660 https://github.com/illumos/illumos-gate/commit/9adfa60d484ce2435f5af77cc99dcd4e6 92b6660 https://www.illumos.org/issues/6314 Callers of dsl_dataset_name pass a buffer of size ZFS_MAXNAMELEN, but dsl_dataset_name copies the datasets' name PLUS the snapshot name to it, resulting in a max of 2 * ZFS_MAXNAMELEN + '@'. Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Matthew Ahrens <mahrens@delphix.com> Notes: svn path=/head/; revision=305209
* MFV r302659: 6931 lib/libzfs: cleanup gcc warningsAlexander Motin2016-09-017-54/+68
| | | | | | | | | | | | | | | | | | illumos/illumos-gate@88f61dee20b358671b1b643e9d1dbf220a1d69be https://github.com/illumos/illumos-gate/commit/88f61dee20b358671b1b643e9d1dbf220a1d69be https://www.illumos.org/issues/6931 need cleanup: CERRWARN += -_gcc=-Wno-switch CERRWARN += -_gcc=-Wno-parentheses CERRWARN += -_gcc=-Wno-unused-function Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Igor Kozhukhov <ikozhukhov@gmail.com> Notes: svn path=/head/; revision=305207
* MFV r302658: 6872 zfs libraries should not allow uninitialized variablesAlexander Motin2016-09-013-7/+8
| | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@f83b46baf98d276f5f84fa84c8b461f412ac1f5e https://github.com/illumos/illumos-gate/commit/f83b46baf98d276f5f84fa84c8b461f41 2ac1f5e https://www.illumos.org/issues/6872 We compile the zfs libraries with -Wno-uninitialized. We should remove this. Change makefiles, fix new warnings, fix pbchk errors. Reviewed by: Dan Kimmel <dan.kimmel@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Prakash Surya <prakash.surya@delphix.com> Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Paul Dagnelie <pcd@delphix.com> Notes: svn path=/head/; revision=305206
* MFV r302657: 4521 zfstest is trying to execute evil "zfs unmount -a"Alexander Motin2016-09-013-12/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | illumos/illumos-gate@8808ac5dae118369991f158b6ab736cb2691ecde https://github.com/illumos/illumos-gate/commit/8808ac5dae118369991f158b6ab736cb2 691ecde https://www.illumos.org/issues/4521 zfstest is trying to execute evil "zfs unmount -a", which fails (fortunately, as it would otherwise leave me with my ~ missing): 03:44:11.86 cannot unmount '/export/home/yuri': Device busy cannot unmount '/ export/home': Device busy 03:44:11.86 ERROR: /usr/sbin/zfs unmount -a exited 1 This affects, at least, zfs_mount_009_neg and zfs_mount_all_001_pos, both failing on that step. The pool containing the /export/home hierarchy is included in KEEP variable, but it doesn't seem to affect anything here. Reviewed by: Andriy Gapon <avg@FreeBSD.org> Reviewed by: Dan McDonald <danmcd@omniti.com> 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> Notes: svn path=/head/; revision=305205
* MFV r302655: 6873 zfs_destroy_snaps_nvl leaks errlistAlexander Motin2016-09-011-2/+5
| | | | | | | | | | | | | | | | | | illumos/illumos-gate@4cde22c29999ffb907ca39d2ebd512812f7e5168 https://github.com/illumos/illumos-gate/commit/4cde22c29999ffb907ca39d2ebd512812 f7e5168 https://www.illumos.org/issues/6873 lzc_destroy_snaps() returns an nvlist in errlist. zfs_destroy_snaps_nvl() should nvlist_free() it before returning. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Chris Williamson <chris.williamson@delphix.com> Notes: svn path=/head/; revision=305203
* MFV r302654:Alexander Motin2016-09-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 6879 incorrect endianness swap for drr_spill.drr_length in libzfs_sendrecv.c illumos/illumos-gate@20fea7a47472aceb64d3ed48cc2a3ea268bc4795 https://github.com/illumos/illumos-gate/commit/20fea7a47472aceb64d3ed48cc2a3ea26 8bc4795 https://www.illumos.org/issues/6879 In libzfs_sendrecv, there's a typo: case DRR_SPILL: if (byteswap) { drr->drr_u.drr_write.drr_length = BSWAP_64(drr->drr_u.drr_spill.drr_length); } Instead of drr_write.drr_length, we should be assigning the result of the byteswap to drr_spill.drr_length. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Paul Dagnelie <pcd@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Dan Kimmel <dan.kimmel@delphix.com> Notes: svn path=/head/; revision=305202
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-10 07:18:14 +0000