#
357706 |
|
09-Feb-2020 |
kevans |
MFC O_SEARCH: r357412, r357461, r357580, r357584, r357636, r357671, r357688
r357412: Provide O_SEARCH
O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping permissions checks on the directory itself after the initial open(). This is close to the semantics we've historically applied for O_EXEC on a directory, which is UB according to POSIX. Conveniently, O_SEARCH on a file is also explicitly undefined behavior according to POSIX, so O_EXEC would be a fine choice. The spec goes on to state that O_SEARCH and O_EXEC need not be distinct values, but they're not defined to be the same value.
This was pointed out as an incompatibility with other systems that had made its way into libarchive, which had assumed that O_EXEC was an alias for O_SEARCH.
This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a directory is checked in vn_open_vnode already, so for completeness we add a NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not re-check that when descending in namei.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/
r357461: namei: preserve errors from fget_cap_locked
Most notably, we want to make sure we don't clobber any capabilities-related errors. This is a regression from r357412 (O_SEARCH) that was picked up by the capsicum tests.
r357580: O_SEARCH test: drop O_SEARCH|O_RDWR local diff
In FreeBSD's O_SEARCH implementation, O_SEARCH in conjunction with O_RDWR or O_WRONLY is explicitly rejected. In this case, O_RDWR was not necessary anyways as the file will get created with or without it.
This was submitted upstream as misc/54940 and committed in rev 1.8 of the file.
r357584: Record-only MFV of r357583: netbsd-tests: import upstreamed changes
The changes in question originated in FreeBSD/head; no further action is required.
r357636: MFV r357635: imnport v1.9 of the O_SEARCH tests
The RCSID data was wrong, so this is effectively a record-only merge with correction of said data. No further changes should be needed in this area, as we've now upstreamed our local changes to this specific test.
r357671: O_SEARCH test: mark revokex an expected fail on NFS
The revokex test does not work when the scratch directory is created on NFS. Given the nature of NFS, it likely can never work without looking like a security hole since O_SEARCH would rely on the server knowing that the directory did have +x at the time of open and that it's OK for it to have been revoked based on POSIX specification for O_SEARCH.
This does mean that O_SEARCH is only partially functional on NFS in general, but I suspect the execute bit getting revoked in the process is likely not common.
r357688: MFV r357687: Import NFS fix for O_SEARCH tests
The version that ended upstream was ultimately slightly different than the version committed here; notably, statvfs() is used but it's redefined appropriately to statfs() on FreeBSD since we don't provide the fstypename for the former interface.
|
#
357605 |
|
05-Feb-2020 |
kevans |
MFC r357410-r357411: Avoid duplicating VEXEC checks in VOP_CACHEDLOOKUP
r357410: pseudofs: don't do VEXEC check in VOP_CACHEDLOOKUP
VOP_CACHEDLOOKUP should assume that the appropriate VEXEC check has been done in the caller (vfs_cache_lookup), so it does not belong here.
r357411: zfs: light refactor to indicate cachedlookup in zfs_lookup
If we come from VOP_CACHEDLOOKUP, we must skip the VEXEC check as it will have been done in the caller (vfs_cache_lookup). This is a part of D23247, which may skip the earlier VEXEC check as well if the root fd was opened with O_SEARCH.
This one required slightly more work as zfs_lookup may also be called indirectly as VOP_LOOKUP or a couple of other places where we must do the check.
|
#
355443 |
|
06-Dec-2019 |
kib |
MFC r355211: Add a VN_OPEN_INVFS flag.
|
#
352687 |
|
25-Sep-2019 |
mav |
MFC r352493: Fix typo, setting hidden flag instead of reparse.
|
#
341074 |
|
27-Nov-2018 |
markj |
MFC r340856: Ensure that directory entry padding bytes are zeroed.
|
#
332525 |
|
16-Apr-2018 |
mav |
MFC r329732: MFV r329502: 7614 zfs device evacuation/removal
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>
|
#
331017 |
|
15-Mar-2018 |
kevans |
MFC r317055,r317056 (glebius): Include sys/vmmeter.h as included
r317055: All these files need sys/vmmeter.h, but now they got it implicitly included via sys/pcpu.h.
r317056: Typo!
|
#
330991 |
|
15-Mar-2018 |
avg |
MFC r329363: read-behind / read-ahead support for zfs_getpages()
|
#
330986 |
|
15-Mar-2018 |
avg |
MFC r329717: MFV r329715: 8997 ztest assertion failure in zil_lwb_write_issue
|
#
330064 |
|
27-Feb-2018 |
avg |
MFC r329016: remove a duplicate assignment
|
#
330062 |
|
27-Feb-2018 |
avg |
MFC r328881: zfs: move a utility function, ioflags, closer to its consumers
|
#
328298 |
|
23-Jan-2018 |
jhb |
MFC 320900,323882,324224,324226,324228,326986,326988,326989,326990,326993, 326994,326995,327004: Various fixes for pathconf(2).
The original change to use vop_stdpathconf() more widely was motivated by a panic due to recent AIO-related changes. However, bde@ reported that vop_stdpathconf() contained too many settings that were not filesystem-independent. The end result of this set of patches is to fix the AIO-related panic via use of a trimmed-down vop_stdpathconf() while also adding support for missing pathconf variables in various filesystems (and removing a few settings incorrectly reported as supported).
320900: Consistently use vop_stdpathconf() for default pathconf values.
Update filesystems not currently using vop_stdpathconf() in pathconf VOPs to use vop_stdpathconf() for any configuration variables that do not have filesystem-specific values. vop_stdpathconf() is used for variables that have system-wide settings as well as providing default values for some values based on system limits. Filesystems can still explicitly override individual settings.
323882: Only handle _PC_MAX_CANON, _PC_MAX_INPUT, and _PC_VDISABLE for TTY devices.
Move handling of these three pathconf() variables out of vop_stdpathconf() and into devfs_pathconf() as TTY devices can only be devfs files. In addition, only return settings for these three variables for devfs devices whose device switch has the D_TTY flag set.
324224: Handle _PC_FILESIZEBITS and _PC_SYMLINK_MAX pathconf() requests in cd9660.
cd9660 only supports symlinks with Rock Ridge extensions, so _PC_SYMLINK_MAX is conditional on Rock Ridge.
324226: Return 64 for pathconf(_PC_FILESIZEBITS) on tmpfs.
324228: Flesh out pathconf() on UDF.
- Return 64 bits for _PC_FILESIZEBITS. - Handle _PC_SYMLINK_MAX. - Defer _PC_PATH_MAX to vop_stdpathconf().
326986: Add a custom VOP_PATHCONF method for fdescfs.
The method handles NAME_MAX and LINK_MAX explicitly. For all other pathconf variables, the method passes the request down to the underlying file descriptor. This requires splitting a kern_fpathconf() syscallsubr routine out of sys_fpathconf(). Also, to avoid lock order reversals with vnode locks, the fdescfs vnode is unlocked around the call to kern_fpathconf(), but with the usecount of the vnode bumped.
326988: Add a custom VOP_PATHCONF method for fuse.
This method handles _PC_FILESIZEBITS, _PC_SYMLINK_MAX, and _PC_NO_TRUNC. For other values it defers to vop_stdpathconf().
326989: Support _PC_FILESIZEBITS in msdosfs' VOP_PATHCONF().
326990: Handle _PC_FILESIZEBITS and _PC_NO_TRUNC for smbfs' VOP_PATHCONF().
326993: Move NAME_MAX, LINK_MAX, and CHOWN_RESTRICTED out of vop_stdpathconf().
Having all filesystems fall through to default values isn't always correct and these values can vary for different filesystem implementations. Most of these changes just use the existing default values with a few exceptions: - Don't report CHOWN_RESTRICTED for ZFS since it doesn't do the exact permissions check this claims for chown(). - Use NANDFS_NAME_LEN for NAME_MAX for nandfs. - Don't report a LINK_MAX of 0 on smbfs. Now fail with EINVAL to indicate hard links aren't supported.
326994: Handle _PC_FILESIZEBITS and _PC_SYMLINK_MAX for devfs' VOP_PATHCONF().
326995: Use FUSE_LINK_MAX for LINK_MAX in fuse' VOP_PATHCONF().
Should have included this in r326993.
327004: Rework pathconf handling for FIFOs.
On the one hand, FIFOs should respect other variables not supported by the fifofs vnode operation (such as _PC_NAME_MAX, _PC_LINK_MAX, etc.). These values are fs-specific and must come from a fs-specific method. On the other hand, filesystems that support FIFOs are required to support _PC_PIPE_BUF on directory vnodes that can contain FIFOs. Given this latter requirement, once the fs-specific VOP_PATHCONF method supports _PC_PIPE_BUF for directories, it is also suitable for FIFOs permitting a single VOP_PATHCONF method to be used for both FIFOs and non-FIFOs.
To that end, retire all of the FIFO-specific pathconf methods from filesystems and change FIFO-specific vnode operation switches to use the existing fs-specific VOP_PATHCONF method. For fifofs, set it's VOP_PATHCONF to VOP_PANIC since it should no longer be used.
While here, move _PC_PIPE_BUF handling out of vop_stdpathconf() so that only filesystems supporting FIFOs will report a value. In addition, only report a valid _PC_PIPE_BUF for directories and FIFOs.
PR: 219851 Sponsored by: Chelsio Communications
|
#
326427 |
|
01-Dec-2017 |
avg |
MFC r326070: zfs_write: fix problem with writes appearing to succeed when over quota
The problem happens when the writes have offsets and sizes aligned with a filesystem's recordsize (maximum block size). In this scenario dmu_tx_assign() would fail because of being over the quota, but the uio would already be modified in the code path where we copy data from the uio into a borrowed ARC buffer. That makes an appearance of a partial write, so zfs_write() would return success and the uio would be modified consistently with writing a single block.
That bug can result in a data loss because the writes over the quota would appear to succeed while the actual data is being discarded.
This commit fixes the bug by ensuring that the uio is not changed until after all error checks are done. To achieve that the code now uses uiocopy() + uioskip() as in the original illumos design. We can do that now that uiocopy() has been updated in r326067 to use vn_io_fault_uiomove().
|
#
325132 |
|
30-Oct-2017 |
avg |
MFC r324011, r324016: MFV r323535: 8585 improve batching done in zil_commit()
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>
|
#
324203 |
|
02-Oct-2017 |
avg |
MFC r323918: MFV r323917: 8648 Fix range locking in ZIL commit codepath
This fixes a problem introduced in r315441, MFC of r308782.
|
#
324158 |
|
01-Oct-2017 |
avg |
MFC r323522: slightly simplify zfs_vptocnp
|
#
323748 |
|
19-Sep-2017 |
avg |
MFC r322226: MFV r322223: 8378 crash due to bp in-memory modification of 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>
|
#
321579 |
|
26-Jul-2017 |
mav |
MFC r319953: MFV r319951: 8311 ZFS_READONLY is a little too strict
illumos/illumos-gate@2889ec41c05e9ffe1890b529b3111354da325aeb https://github.com/illumos/illumos-gate/commit/2889ec41c05e9ffe1890b529b3111354d a325aeb
https://www.illumos.org/issues/8311 Description: There was a misunderstanding about the enforcement details of the "Read-only" flag introduced for SMB/CIFS compatibility, way back in 2007 in the Sun PSARC 2007/315 case. The original authors thought enforcement of the READONLY flag should work similarly as the IMMUTABLE flag. Unfortunately, that enforcement is incompatible with the expectations of Windows applications using this feature through the SMB service. Applications assume (and the MS File System Algorithm s MS-FSA confirms they should) that an SMB client can: (a) Open an SMB handle on a file with read/write access, (b) Set the DOS attributes to include the READONLY flag, (c) continue to have write access via that handle. This access model is essentially the same as a Unix/POSIX application that creates a file (with read/write access), uses fchmod() to change the file mode to something not granting write access (i.e. 0444), and then continues to writ e that file using the open handle it got before the mode change. Currently, the SMB server works-around this problem in a way that will become difficult to maintain as we implement support for SMB3 persistent handles, so SMB depends on this fix. I've written a test program that can be used to demonstrate this problem, and added it to zfs-tests (tests/functional/acl/cifs/cifs_attr_004_pos). It currently fails, but will pass when this problem fixed. Steps to Reproduce: Run the test program on a ZFS file system. Expected Results: Pass Actual Results: Fail.
Reviewed by: Sanjay Nadkarni <sanjay.nadkarni@nexenta.com> Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Andrew Stormont <andyjstormont@gmail.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: John Kennedy <john.kennedy@delphix.com> Approved by: Prakash Surya <prakash.surya@delphix.com> Author: Gordon Ross <gwr@nexenta.com>
|
#
321561 |
|
26-Jul-2017 |
mav |
MFC r318923: zfs_putpages: assert that sa_bulk_update() must succeed
Same as the upstream does in r316927.
|
#
321559 |
|
26-Jul-2017 |
mav |
MFC r318921: MFV r316928: 7256 low probability race in zfs_get_data
illumos/illumos-gate@0c94e1af6784c69a1dea25e0e35dd13b2b91e2e5 https://github.com/illumos/illumos-gate/commit/0c94e1af6784c69a1dea25e0e35dd13b2b91e2e5
https://www.illumos.org/issues/7256 error = dmu_sync(zio, lr->lr_common.lrc_txg, zfs_get_done, zgd); ASSERT(error || lr->lr_length <= zp->z_blksz); It's possible, although extremely rare, that the zfs_get_done() callback is executed before dmu_sync() returns. In that case the znode's range lock is dropped and the znode is unreferenced. Thus, the assertion can access some invalid or wrong data via the zp pointer. size variable caches the correct value of z_blksz and can be safely used here.
Reviewed by: Matt Ahrens <mahrens@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Andriy Gapon <andriy.gapon@clusterhq.com>
|
#
321545 |
|
26-Jul-2017 |
mav |
MFC r318818: MFV r316907: 1300 filename normalization doesn't work for removes
illumos/illumos-gate@1c17160ac558f98048951327f4e9248d8f46acc0 https://github.com/illumos/illumos-gate/commit/1c17160ac558f98048951327f4e9248d8f46acc0
https://www.illumos.org/issues/1300
FreeBSD note: recent FreeBSD was not affected by the issue fixed as the name cache is completely bypassed when normalization is enabled. The change is imported for the sake of ZAP infrastructure modifications.
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Matt Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com> Author: Kevin Crowe <kevin.crowe@nexenta.com>
|
#
319415 |
|
01-Jun-2017 |
avg |
MFC r319096: zfs_lookup: fix bogus arguments to lookup of "snapshot" directory
|
#
319091 |
|
29-May-2017 |
avg |
MFC r308826: zfs: fix up after the removal of PG_CACHED pages in r308691
Now that r308691 has been MFC-ed as a part of r318716, r308826 must be MFC-ed as well.
PR: 214629 Reported by: mshirk@daemon-security.com [head], lev [stable/11]
|
#
318716 |
|
23-May-2017 |
markj |
MFC r308474, r308691, r309203, r309365, r309703, r309898, r310720, r308489, r308706: Add PQ_LAUNDRY and remove PG_CACHED pages.
|
#
316847 |
|
14-Apr-2017 |
avg |
MFC r315853: zfs_putpages: use TXG_WAIT
|
#
316391 |
|
02-Apr-2017 |
asomers |
MFC r313483:
Fix setting birthtime in ZFS
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c * In zfs_freebsd_setattr, if the caller wants to set the birthtime, set the bits that zfs_settattr expects
* In zfs_setattr, if XAT_CREATETIME is set, set xoa_createtime, expected by zfs_xvattr_set. The two levels of indirection seem excessive, but it minimizes diffs vs OpenZFS.
* In zfs_setattr, check for overflow of va_birthtime (from delphij)
* Remove red herring in zfs_getattr
sys/cddl/contrib/opensolaris/uts/common/sys/vnode.h * Un-booby-trap some macros
New tests are under review at https://github.com/pjd/pjdfstest/pull/6
Reviewed by: avg MFC after: 3 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D9353
|
#
315842 |
|
23-Mar-2017 |
avg |
MFC r314048,r314194: reimplement zfsctl (.zfs) support
|
#
314710 |
|
05-Mar-2017 |
mm |
MFC r314572:
Fix null pointer dereference in zfs_freebsd_setacl().
Prevents unprivileged users from panicking the kernel by calling __acl_delete_*() on files or directories inside a ZFS mount.
|
#
314030 |
|
21-Feb-2017 |
avg |
MFC r313686: check remaining space in zfs implementations of vptocnp
PR: 216939
|
#
310066 |
|
14-Dec-2016 |
avg |
MFC r308887,309090: fix unsafe modification of zfs_vnodeops when DIAGNOSTIC is enabled
|
#
307995 |
|
27-Oct-2016 |
avg |
MFC r306801: implement zfs_vptocnp() using z_parent property
|
#
307671 |
|
20-Oct-2016 |
kib |
MFC r307218: Fix a race in vm_page_busy_sleep(9).
|
#
307142 |
|
12-Oct-2016 |
avg |
MFC r306665: zfs: fix a wrong assertion for extended attributes
PR: 213112
|
#
306818 |
|
07-Oct-2016 |
avg |
MFC r306292: fix vnode lock assertion for extended attributes directory
|
#
304122 |
|
15-Aug-2016 |
avg |
MFC r302839: 6940 Cannot unlink directories when over quota
|
#
303970 |
|
11-Aug-2016 |
avg |
MFC r303763,303791,303869: zfs: honour and make use of vfs vnode locking protocol
ZFS POSIX Layer is originally written for Solaris VFS which is very different from FreeBSD VFS. Most importantly many things that FreeBSD VFS manages on behalf of all filesystems are implemented in ZPL in a different way. Thus, ZPL contains code that is redundant on FreeBSD or duplicates VFS functionality or, in the worst cases, badly interacts / interferes with VFS.
The most prominent problem is a deadlock caused by the lock order reversal of vnode locks that may happen with concurrent zfs_rename() and lookup(). The deadlock is a result of zfs_rename() not observing the vnode locking contract expected by VFS.
This commit removes all ZPL internal locking that protects parent-child relationships of filesystem nodes. These relationships are protected by vnode locks and the code is changed to take advantage of that fact and to properly interact with VFS.
Removal of the internal locking allowed all ZPL dmu_tx_assign calls to use TXG_WAIT mode.
Another victim, disputable perhaps, is ZFS support for filesystems with mixed case sensitivity. That support is not provided by the OS anyway, so in ZFS it was a buch of dead code.
To do: - replace ZFS_ENTER mechanism with VFS managed / visible mechanism - replace zfs_zget with zfs_vget[f] as much as possible - get rid of not really useful now zfs_freebsd_* adapters - more cleanups of unneeded / unused code - fix / replace .zfs support
PR: 209158 Approved by: re (gjb)
|