summaryrefslogtreecommitdiffstats
path: root/cddl/contrib/opensolaris/lib/libzfs
Commit message (Collapse)AuthorAgeFilesLines
...
* MFV r268119:delphij2014-07-011-9/+12
| | | | | | | | 4914 zfs on-disk bookmark structure should be named *_phys_t illumos/illumos-gate@7802d7bf98dec568dadf72286893b1fe5abd8602 MFC after: 2 weeks
* - Fix handling of "new" style of ioctl in compatiblity mode [1];delphij2014-07-011-10/+17
| | | | | | | | - Reorganize code and reduce diff from upstream; - Improve forward compatibility shims for previous kernel; Reported by: sbruno [1] X-MFC-With: r268075
* MFV r267566:delphij2014-07-011-0/+1
| | | | | | 4390 i/o errors when deleting filesystem/zvol can lead to space map corruption MFC after: 2 weeks
* MFV r267565:delphij2014-07-012-7/+45
| | | | | | | 4757 ZFS embedded-data block pointers ("zero block compression") 4913 zfs release should not be subject to space checks MFC after: 2 weeks
* Comment out some pointless device open/close around reading device IDs.mav2014-05-102-0/+8
| | | | | | | | | FreeBSD ZFS port unlike OpenSolaris does not use device IDs, and does not implement respective devid_*() fuctions. It is pointless to open devices just to close them back immediately. MFC after: 2 weeks Sponsored by: iXsystems, Inc.
* Silence compiler warning due to missing return in idmap_id_to_numeric_domain_ridsmh2014-04-241-0/+1
|
* MFV r264829:delphij2014-04-232-0/+40
| | | | | | 3897 zfs filesystem and snapshot limits MFC after: 2 weeks
* Take into account when zpool history block grows exceeding 128KB in zpool(8)delphij2014-04-141-4/+26
| | | | | | | | | and zdb(8) by growing the buffer on demand with a cap of 1GB (specified in spa_history_create_obj()). PR: bin/186574 Submitted by: Andrew Childs <lorne cons org nz> (with changes) MFC after: 2 weeks
* MFV r263887:delphij2014-03-283-12/+20
| | | | | | | 3993 zpool(1M) and zfs(1M) should support -p for "list" and "get" 4700 "zpool get" doesn't support -H or -o options MFC after: 2 weeks
* MFV r262570:delphij2014-02-271-4/+11
| | | | | | | | 4626 libzfs memleak in zpool_in_use() illumos/illumos-gate@fb13f48f1d9593453b94cd1c7277553b56f493c8 MFC after: 2 weeks
* MFV r260154 + 260182:delphij2014-01-025-40/+236
| | | | | | | | | 4369 implement zfs bookmarks 4368 zfs send filesystems from readonly pools Illumos/illumos-gate@78f171005391b928aaf1642b3206c534ed644332 MFC after: 2 weeks
* MFV r258384:delphij2013-12-252-8/+10
| | | | | | | | 2583 Add -p (parsable) option to zfs list illumos/illumos-gate@43d68d68c1ce08fb35026bebfb141af422e7082e MFC after: 2 weeks
* MFV r258374:delphij2013-12-241-6/+5
| | | | | | | | | | | 4171 clean up spa_feature_*() interfaces 4172 implement extensible_dataset feature for use by other zpool features illumos/illumos-gate@2acef22db7808606888f8f92715629ff3ba555b9 MFC after: 2 weeks
* Don't even try to read vdev labels from devices smaller then SPA_MINDEVSIZEmav2013-12-101-2/+9
| | | | | | (64MB). Even if we would find one somehow, ZFS kernel code rejects such devices. It is funny to look on attempts to read 4 256K vdev labels from 1.44MB floppy, though it is not very practical and quite slow.
* MFV r254750:delphij2013-09-211-11/+8
| | | | | | | | | | | | | Add support of Illumos dumps on zvol over RAID-Z. Note that this only adds the features. FreeBSD would still need more work to support dumping on zvols. Illumos ZFS issues: 2932 support crash dumps to raidz, etc. pools MFC after: 1 month Approved by: re (ZFS blanket)
* MFV r254748:delphij2013-08-241-1/+5
| | | | | | | Fix memory leak in libzfs's iter_dependents_cb(). Illumos ZFS issues: 4061 libzfs: memory leak in iter_dependents_cb()
* Enhance the ZFS vdev layer to maintain both a logical and a physicalgibbs2013-08-212-35/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | minimum allocation size for devices. Use this information to automatically increase ZFS's minimum allocation size for new top-level vdevs to a value that more closely matches the optimum device allocation size. Use GEOM's stripesize attribute, if set, as the physical sector size of the GEOM. Calculate the minimum blocksize of each metaslab class. Use the calculated value instead of SPA_MINBLOCKSIZE (512b) when determining the likelyhood of compression yeilding a reduction in physical space usage. Report devices with sub-optimal block size configuration in "zpool status". Also properly fail attempts to attach devices with a logical block size greater than 8kB, since this will cause corruption to ZFS's label area. Sponsored by: Spectra Logic Corporaion MFC after: 2 weeks Background ========== Many modern devices use physical allocation units that are much larger than the minimum logical allocation size accessible by external commands. Two prevalent examples of this are 512e disk drives (512b logical sector, 4K physical sector) and flash devices (512b logical sector, 4K or larger allocation block size, and 128k or larger erase block size). Operations that modify less than the physical sector size result in a costly read-modify-write or garbage collection sequence on these devices. Simply exporting the true physical sector of the device to ZFS would yield optimal performance, but has two serious drawbacks: 1) Existing pools created with devices that have different logical and physical block sizes, but were configured to use the logical block size (e.g. because the OS version used for pool construction reported the logical block size instead of the physical block size) will suddenly find that the vdev allocation size has increased. This can be easily tolerated for active members of the array, but ZFS would prevent replacement of a vdev with another identical device because it now appears that the smaller allocation size required by the pool is not supported by the new device. 2) The device's physical block size may be too large to be supported by ZFS. The optimal allocation size for the vdev may be quite large. For example, a RAID controller may export a vdev that requires read-modify-write cycles unless accessed using 64k aligned/sized requests. ZFS currently has an 8k minimum block size limit. Reporting both the logical and physical allocation sizes for vdevs solves these problems. A device may be used so long as the logical block size is compatible with the configuration. By comparing the logical and physical block sizes, new configurations can be optimized and administrators can be notified of any existing pools that are sub-optimal. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa.h: Add the SPA_ASHIFT constant. ZFS currently has a hard upper limit of 13 (8k) for ashift and this constant is used to both document and enforce this limit. sys/cddl/contrib/opensolaris/uts/common/sys/fs/zfs.h: Add the VDEV_AUX_ASHIFT_TOO_BIG error code. Add fields for exporting the configured, logical, and physical ashift to the vdev_stat_t structure. Add VDEV_STAT_VALID() macro which can be used to verify the presence of required vdev_stat_t fields in nvlist data. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c: Provide a SYSCTL_PROC handler for "max_auto_ashift". Since the limit is only referenced long after boot when a create operation occurs, there's no compelling need for it to be a boot time configurable tunable. This also allows the validation code for the max_auto_ashift value to be contained within the sysctl handler. Populate the new fields in the vdev_stat_t structure. Fail vdev opens if the vdev reports an ashift larger than SPA_MAXASHIFT. Propogate vdev_logical_ashift and vdev_physical_ashift between child and parent vdevs as is done for vdev_ashift. In vdev_open(), restore code that fails opens for devices where vdev_ashift grows. This can only happen now if the device's logical ashift grows, which means it really isn't safe to use the device. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_missing.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_root.c: Update the vdev_open() API so that both logical (what was just ashift before) and physical ashift are reported. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev_impl.h: Add two new fields, vdev_physical_ashift and vdev_logical_ashift, to vdev_t. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c: Add vdev_ashift_optimize(). Call it anytime a new top-level vdev is allocated. cddl/contrib/opensolaris/cmd/zpool/zpool_main.c: Add text for the VDEV_AUX_ASHIFT_TOO_BIG error. For each sub-optimally configured leaf vdev, report configured and native block sizes. cddl/contrib/opensolaris/cmd/zpool/zpool_main.c: cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c: Introduce a new zpool status: ZPOOL_STATUS_NON_NATIVE_ASHIFT. This status is reported on healthy pools containing vdevs configured to use a block size smaller than their reported physical block size. cddl/contrib/opensolaris/lib/libzfs/common/libzfs_status.c: Update find_vdev_problem() and supporting functions to provide the full vdev_stat_t structure to problem checking routines, and to allow decent into replacing vdevs. Add a vdev_non_native_ashift() validator which is used on the full vdev tree to check for ZPOOL_STATUS_NON_NATIVE_ASHIFT. cddl/contrib/opensolaris/lib/libzpool/common/kernel.c: cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: Enhance sysctl userland stubs now that a SYSCTL_PROC handler is used in vdev.c. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/metaslab_impl.h: When the group membership of a metaslab class changes (i.e. when a vdev is added or removed from a pool), walk the group list to determine the smallest block size currently available and record this in the metaslab class. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/metaslab.h: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c: Add the metaslab_class_get_minblocksize() accessor. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio_compress.h: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio_compress.c: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In zio_compress_data(), take the minimum blocksize as an input parameter instead of assuming SPA_MINBLOCKSIZE. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In l2arc_compress_buf(), pass SPA_MINBLOCKSIZE as the minimum blocksize of the device. The l2arc code performs has it's own code for deciding if compression is worth while, so this effectively disables zio_compress_data() from second guessing the original decision. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c: In zio_write_bp_init(), use the minimum blocksize of the normal metaslab class when compressing data.
* MFV r254421:delphij2013-08-211-10/+2
| | | | | Illumos ZFS issues: 3996 want a libzfs_core API to rollback to latest snapshot
* MFV r253781 + r253871:delphij2013-07-301-4/+11
| | | | | | | Illumos ZFS issues: 3894 zfs should not allow snapshot of inconsistent dataset MFC after: 2 weeks
* MFV r253784:smh2013-07-301-2/+2
| | | | | | | | | | | | Fix zfs send -D hang after processing requiring a CTRL+C to interrupt due to pthread_join prior to fd close. This was introduced by r251646 (MFV r251644) Illumos ZFS issue: 3909 "zfs send -D" does not work MFC after: 1 day
* MFV r252215:delphij2013-06-251-9/+20
| | | | | | | | | | | | Restore a previous behavior before r251646, where when destructing ZFS snapshot, the ioctl would return ENOENT when it hit any of them in the errlist (the new behavior was only return ENOENT when all returns error). Illumos ZFS issues: 3829 fix for 3740 changed behavior of zfs destroy/hold/release ioctl MFC after: 1 week
* Diff reduction against Illumos, no real change to code itself.delphij2013-06-251-0/+1
| | | | | | | This marks vendor branch revision 252213 as merged, the actual code was committed in r245479. MFC after: 1 week
* MFV r251644:delphij2013-06-123-121/+120
| | | | | | | | | | | Poor ZFS send / receive performance due to snapshot hold / release processing (by smh@) Illumos ZFS issues: 3740 Poor ZFS send / receive performance due to snapshot hold / release processing MFC after: 2 weeks
* MFV r251623:delphij2013-06-111-16/+0
| | | | | | | | | zpool create should treat -O mountpoint and -m the same Illumos ZFS issues: 3745 zpool create should treat -O mountpoint and -m the same MFC after: 2 weeks
* MFV r251619:delphij2013-06-111-0/+5
| | | | | | | | | ZFS needs better comments. Illumos ZFS issues: 3741 zfs needs better comments MFC after: 2 weeks
* Respect the enoent_ok flag if reporting error for holding an non-existingmm2013-04-251-4/+7
| | | | | | | | | | snapshot. Related illumos ZFS issue: 3699 zfs hold or release of a non-existent snapshot does not output error Reported by: Steven Hartland <smh@FreeBSD.org> MFC after: 3 days
* Correct error message.pjd2013-04-161-1/+1
| | | | Reported by: Dirk Engling <erdgeist@erdgeist.org>
* Fix libzfs to report error instead of returning zero if trying to hold ormm2013-04-111-4/+24
| | | | | | | | | | release a non-existing snapshot of a existing dataset. In recursive case error is reported if no snapshots with the requested name have been found. Problem and proposed solution reported to illumos: 3699 zfs hold or release of a non-existent snapshot does not output error MFC after: 8 days
* ZFS expects a copyout of zfs_cmd_t on an ioctl error. Our sys_ioctl()mm2013-04-091-1/+3
| | | | | | | | | | | | | | | doesn't copyout in this case. To solve this issue a new struct zfs_iocparm_t is introduced consisting of: - zfs_ioctl_version (future backwards compatibility purposes) - user space pointer to zfs_cmd_t (copyin and copyout) - size of zfs_cmd_t (verification purposes) The copyin and copyout of zfs_cmd_t is now done the illumos (vendor) way what makes porting of new changes easier and ensures correct behavior if returning an error. MFC after: 10 days
* MFV r247580:mm2013-03-193-134/+215
| | | | | | | | | | | Merge synctask code restructuring from vendor. Modify forward and backward compatibility to support new change. Illumos ZFS issues: 3464 zfs synctask code needs restructuring Sponsored by: Hybrid Logic Ltd.
* Move common zfs ioctl compatibility functions (userland) into libzfs_compat.cmm2013-03-182-64/+105
| | | | Introduce additional constants for zfs ioctl versions
* Fix working with zfs_ioctl_version in libzfs_compat.h and include mirrormm2013-03-171-7/+19
| | | | lzc_ioctl_version in libzfs_core
* libzfs_core:mm2013-03-171-5/+5
| | | | | | - provide complete backwards compatibility (old utility, new kernel) - add zfs_cmd_t compatibility mapping in both directions - determine ioctl address in zfs_ioctl_compat.c
* Move libzfs compat functions to libzfs_compat.hmm2013-03-062-59/+95
| | | | This header is used by both libzfs_core and libzfs libraries
* WiP merge of libzfs_core (MFV r238590, r238592)mm2013-03-056-198/+208
| | | | not yet working, ioctl handling needs to be changed
* Fix the zfs_ioctl compat layer to support zfs_cmd size change introducedmm2013-03-011-9/+26
| | | | | | | | | | | | | | | in r247265 (ZFS deadman thread). Both new utilities now support the old kernel and new kernel properly detects old utilities. For future backwards compatibility, the vfs.zfs.version.ioctl read-only sysctl has been introduced. With this sysctl zfs utilities will be able to detect the ioctl interface version of the currently loaded zfs module. As a side effect, the zfs utilities between r247265 and this revision don't support the old kernel module. If you are using HEAD newer or equal than r247265, install the new kernel module (or whole kernel) first. MFC after: 10 days
* MFV r246388:mm2013-02-101-7/+1
| | | | | | | | | | | | | | Import vendor bugfixes Illumos ZFS issues: 3422 zpool create/syseventd race yield non-importable pool 3425 first write to a new zvol can fail with EFBIG References: https://www.illumos.org/issues/3422 https://www.illumos.org/issues/3425 MFC after: 2 weeks
* Reports pools which have a removed l2cache disk under -x as this is whatsmh2013-01-151-0/+10
| | | | | | | | happens when a cache device is dropped for any reason. Reviewed by: pjd Approved by: pjd (mentor) MFC after: 2 weeks
* Fixes zfs receive errors caused by snapshot replication being processed in asmh2012-12-131-2/+29
| | | | | | | | | | | | | random order instead of creation order. Eliminates needless filesystem renames caused by removed parent snapshots which subsequently causes many more errors. PR: kern/172259 Submitted by: Steven Hartland Reviewed by: pjd (mentor) Approved by: pjd (mentor) MFC after: 2 weeks
* Add missing initialization for do_prefix.mm2012-10-171-1/+1
| | | | | | | | | | | | | Corrects porting error in r238391 Vendor issue and changeset reference: 2883 changing "canmount" property to "on" should not always remount dataset https://www.illumos.org/issues/2883 Changeset 13743:95aba6e49b9f Reported by: Guido Falsi <mad@madpilot.net>, avg Obtained from: illumos (issue #2883) MFC after: 1 week
* Make sure that each va_start has one and only one matching va_end,kevlo2012-09-281-0/+2
| | | | especially in error cases.
* It is possible to recursively destroy snapshots even if the snapshotpjd2012-09-232-2/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | doesn't exist on a dataset we are starting from. For example if we have the following configuration: tank tank/foo tank/foo@snap tank/bar tank/bar@snap We can execute: # zfs destroy -t tank@snap eventhough tank@snap doesn't exit. Unfortunately it is not possible to do the same with recursive rename: # zfs rename -r tank@snap tank@pans cannot open 'tank@snap': dataset does not exist ...until now. This change allows to recursively rename snapshots even if snapshot doesn't exist on the starting dataset. Sponsored by: rsync.net MFC after: 2 weeks
* Merge recent zfs vendor changes, sync code and adjust userland DEBUG.mm2012-09-121-12/+17
| | | | | | | | | | | | | | | | | | | | | Illumos issued covered: 1884 Empty "used" field for zfs *space commands 3006 VERIFY[S,U,P] and ASSERT[S,U,P] frequently check if first argument is zero 3028 zfs {group,user}space -n prints (null) instead of numeric GID/UID 3048 zfs {user,group}space [-s|-S] is broken 3049 zfs {user,group}space -t doesn't really filter the results 3060 zfs {user,group}space -H output isn't tab-delimited 3061 zfs {user,group}space -o doesn't use specified fields order 3064 usr/src/cmd/zpool/zpool_main.c misspells "successful" 3093 zfs {user,group}space's -i is noop 3098 zfs userspace/groupspace fail without saying why when run as non-root References: https://www.illumos.org/issues/ + [issue_id] Obtained from: illumos (vendor/illumos, vendor/illumos-sys) MFC after: 2 weeks
* Merge recent vendor changes:mm2012-08-281-1/+1
| | | | | | | | | | | | | | 3100 zvol rename fails with EBUSY when dirty 3104 eliminate empty bpobjs 3120 zinject hangs in zfsdev_ioctl() due to uninitialized zc References: https://www.illumos.org/issues/3100 https://www.illumos.org/issues/3104 https://www.illumos.org/issues/3120 Obtained from: illumos (vendor/illumos, vendor/illumos-sys) MFC after: 2 weeks
* Merge recent vendor changes:mm2012-08-231-46/+39
| | | | | | | | | | | | | | | 3086 unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets 3090 vdev_reopen() during reguid causes vdev to be treated as corrupt 3102 vdev_uberblock_load() and vdev_validate() may read the wrong label Referenes: https://www.illumos.org/issues/3086 https://www.illumos.org/issues/3090 https://www.illumos.org/issues/3102 PR: kern/170912, kern/170914 Obtained from: illumos (changeset #13776, #13777) MFC after: 2 weeks
* Partial MFV (illumos-gate 13753:2aba784c276b)mm2012-07-302-1/+27
| | | | | | | | | 2762 zpool command should have better support for feature flags References: https://www.illumos.org/issues/2762 MFC after: 2 weeks
* Merge illumos commit 13749:df4cd82e2b60mm2012-07-133-10/+65
| | | | | | | | | | | | | | | 1796 "ZFS HOLD" should not be used when doing "ZFS SEND" froma read-only pool 2871 support for __ZFS_POOL_RESTRICT used by ZFS test suite 2903 zfs destroy -d does not work 2957 zfs destroy -R/r sometimes fails when removing defer-destroyed snapshot References: https://www.illumos.org/issues/1796 https://www.illumos.org/issues/2871 https://www.illumos.org/issues/2903 https://www.illumos.org/issues/2957 MFC after: 1 week
* Change behavior introduced in r237119 to vendor solutionmm2012-07-121-7/+10
| | | | | | | | | References: https://www.illumos.org/issues/2883 PR: 167905 Obtained from: illumos (issue #2883) MFC after: 2 weeks
* Do not remount ZFS dataset if changing canmount property to "on" andmm2012-06-151-1/+3
| | | | | | | | dataset is already mounted. PR: 167905 Submitted by: Bryan Drewery <bryan@shatow.net> MFC after: 1 week
* Introduce "feature flags" for ZFS pools (bump SPA version to 5000).mm2012-06-115-10/+307
| | | | | | | | | | | | | | | | | | | Add first feature "com.delphix:async_destroy" (asynchronous destroy of ZFS datasets). Implement features support in ZFS boot code. Illumos revisions merged: 13700:2889e2596bd6 13701:1949b688d5fb 2619 asynchronous destruction of ZFS file systems 2747 SPA versioning with zfs feature flags References: https://www.illumos.org/issues/2619 https://www.illumos.org/issues/2747 Obtained from: illumos (issue #2619, #2747) MFC after: 1 month
OpenPOWER on IntegriCloud