Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View


Tags: Architectures Distributions Performance Style Tests default
Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

Architectures Distributions Performance Style Tests default
loli10K
Redacted Send/Receive causes zdb to dump core

When used with verbosity >= 4 zdb fails an assertion in dump_bookmarks()
because it expects snprintf() to retun 0 on success.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Paul Dagnelie <pcd@delphix.com>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #8948
loli10K
Fix bp_embedded_type enum definition

With the addition of BP_EMBEDDED_TYPE_REDACTED in 30af21b0 a couple of
codepaths make wrong assumptions and could potentially result in errors.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chris Dunlop <chris@onthe.net.au>
Reviewed-by: Paul Dagnelie <pcd@delphix.com>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #8951
Igor K
-Y option for zdb is valid

The -Y option was added for ztest to test split block reconstruction.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Richard Elling <Richard.Elling@RichardElling.com>
Signed-off-by: Igor Kozhukhov <igor@dilos.org>
Closes #8926
Matthew Ahrens
Remove code for zfs remap

The "zfs remap" command was disabled by
6e91a72fe3ff8bb282490773bd687632f3e8c79d, because it has little utility
and introduced some tricky bugs.  This commit removes the code for it,
the associated ZFS_IOC_REMAP ioctl, and tests.

Note that the ioctl and property will remain, but have no functionality.
This allows older software to fail gracefully if it attempts to use
these, and avoids a backwards incompatibility that would be introduced if
we renumbered the later ioctls/props.

Reviewed-by: Tom Caputi <tcaputi@datto.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #8944
Tom Caputi
Fix error message on promoting encrypted dataset

This patch corrects the error message reported when attempting
to promote a dataset outside of its encryption root.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #8905
Closes #8935
Tom Caputi
Add 'zfs umount -u' for encrypted datasets

This patch adds the ability for the user to unload keys for
datasets as they are being unmounted. This is analagous to
'zfs mount -l'.

Fixes: #8917

Signed-off-by: Tom Caputi <tcaputi@datto.com>

Pull-request: #8952 part 1/1
Tom Caputi
Add 'zfs umount -u' for encrypted datasets

This patch adds the ability for the user to unload keys for
datasets as they are being unmounted. This is analagous to
'zfs mount -l'.

Signed-off-by: Tom Caputi <tcaputi@datto.com>

Pull-request: #8952 part 1/1
  • Amazon 2 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 8 arm (BUILD): cloning zfs -  stdio
  • Debian 8 ppc (BUILD): cloning zfs -  stdio
  • CentOS 6 x86_64 (BUILD): cloning zfs -  stdio
  • CentOS 7 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 9 x86_64 (BUILD): cloning zfs -  stdio
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 18.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 17.10 x86_64 (STYLE): cloning zfs -  stdio
Brian Behlendorf
Fix out-of-tree build failures

Resolve the incorrect use of srcdir and builddir references for
various files in the build system.  These have crept in over time
and went unnoticed because when building in the top level directory
srcdir and builddir are identical.

With this change it's again possible to build in a subdirectory.

    $ mkdir obj
    $ cd obj
    $ ../configure
    $ make

Reviewed-by: loli10K <ezomori.nozomu@gmail.com>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Don Brady <don.brady@delphix.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #8921
Closes #8943
Tomohiro Kusumi
Add missing .gitignore from "Implement Redacted Send/Receive"

30af21b025 needed to ignore get_diff executable.

Reviewed-by: loli10K <ezomori.nozomu@gmail.com>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
Closes #8950
loli10K
Fix bp_embedded_type enum definition

With the addition of BP_EMBEDDED_TYPE_REDACTED in 30af21b0 a couple of
codepaths make wrong assumptions and could potentially result in errors.

Signed-off-by: loli10K <ezomori.nozomu@gmail.com>

Pull-request: #8951 part 1/1
loli10K
Fix bp_embedded_type enum definition

With the addition of BP_EMBEDDED_TYPE_REDACTED in 30af21b0 a couple of
codepaths make wrong assumptions and could potentially result in errors.

Signed-off-by: loli10K <ezomori.nozomu@gmail.com>

Pull-request: #8951 part 1/1
Tomohiro Kusumi
Add missing .gitignore from "Implement Redacted Send/Receive"

30af21b025 needed to ignore get_diff executable.

Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>

Pull-request: #8950 part 1/1
Don Brady
OpenZFS 9425 - channel programs can be interrupted

Problem Statement
=================
ZFS Channel program scripts currently require a timeout, so that hung or
long-running scripts return a timeout error instead of causing ZFS to get
wedged. This limit can currently be set up to 100 million Lua instructions.
Even with a limit in place, it would be desirable to have a sys admin
(support engineer) be able to cancel a script that is taking a long time.

Proposed Solution
=================
Make it possible to abort a channel program by sending an interrupt signal.In
the underlying txg_wait_sync function, switch the cv_wait to a cv_wait_sig to
catch the signal. Once a signal is encountered, the dsl_sync_task function can
install a Lua hook that will get called before the Lua interpreter executes a
new line of code. The dsl_sync_task can resume with a standard txg_wait_sync
call and wait for the txg to complete.  Meanwhile, the hook will abort the
script and indicate that the channel program was canceled. The kernel returns
a EINTR to indicate that the channel program run was canceled.

Porting notes: Added missing return value from cv_wait_sig()

Authored by: Don Brady <don.brady@delphix.com>
Reviewed by: Sebastien Roy <sebastien.roy@delphix.com>
Reviewed by: Serapheim Dimitropoulos <serapheim.dimitro@delphix.com>
Reviewed by: Matt Ahrens <matt@delphix.com>
Reviewed by: Sara Hartse <sara.hartse@delphix.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Robert Mustacchi <rm@joyent.com>
Ported-by: Don Brady <don.brady@delphix.com>
Signed-off-by: Don Brady <don.brady@delphix.com>

OpenZFS-issue: https://www.illumos.org/issues/9425
OpenZFS-commit: https://github.com/illumos/illumos-gate/commit/d0cb1fb926
Closes #8904
Matthew Ahrens
dn_struct_rwlock can not be held in dmu_tx_try_assign()

The thread calling dmu_tx_try_assign() can't hold the dn_struct_rwlock
while assigning the tx, because this can lead to deadlock. Specifically,
if this dnode is already assigned to an earlier txg, this thread may
need to wait for that txg to sync (the ERESTART case below).  The other
thread that has assigned this dnode to an earlier txg prevents this txg
from syncing until its tx can complete (calling dmu_tx_commit()), but it
may need to acquire the dn_struct_rwlock to do so (e.g. via
dmu_buf_hold*()).

This commit adds an assertion to dmu_tx_try_assign() to ensure that this
deadlock is not inadvertently introduced.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #8929
gordan-bobic
Remove arch and relax version dependency

Remove arch and relax version dependency for zfs-dracut
package.

Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Gordan Bobic <gordan@redsleeve.org>
Issue #8913
Closes #8914
Harry Mallon
Add libnvpair to libzfs pkg-config

Functions such as `fnvlist_lookup_nvlist` need libnvpair to be linked.
Default pkg-config file did not contain it.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Harry Mallon <hjmallon@gmail.com>
Closes #8919
Don Brady
Let zfs mount all tolerate in-progress mounts

The zfs-mount service can unexpectedly fail to start when zfs
encounters a mount that is in progress. This service uses
zfs mount -a, which has a window between the time it checks if
the dataset was mounted and when the actual mount (via mount.zfs
binary) occurs.

The reason for the racing mounts is that both zfs-mount.target
and zfs-share.target are allowed to execute concurrently after
the import.  This is more of an issue with the relatively recent
addition of parallel mounting, and we should consider serializing
the mount and share targets.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Don Brady <don.brady@delphix.com>
Closes #8881
Allan Jude
zstreamdump: add per-record-type counters and an overhead counter

Count the bytes of payload for each replication record type

Count the bytes of overhead (replication records themselves)

Include these counters in the output summary at the end of the run.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matt Ahrens <mahrens@delphix.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Sponsored-By: Klara Systems and Catalogic
Closes #8432
Paul Dagnelie
Fix comments on zfs_bookmark_phys

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matt Ahrens <mahrens@delphix.com>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes #8945
Tomohiro Kusumi
Fix build break by "Implement Redacted Send/Receive"

30af21b025 broke build on Fedora. gcc can detect potential overflow
on compile-time. Consider strlen of already copied string.

Also change strn to strl variants per suggestion from @behlendorf
and @ofaaland.

--
libzfs_input_check.c: In function 'test_redact':
libzfs_input_check.c:711:2: error: 'strncat' specified bound 288 equals
destination size [-Werror=stringop-overflow=]
  strncat(bookmark, "#testbookmark", sizeof (bookmark));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Olaf Faaland <faaland1@llnl.gov>
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
Closes #8939
loli10K
Redacted Send/Receive causes zdb to dump core

When used with verbosity >= 4 zdb fails an assertion in dump_bookmarks()
because it expects snprintf() to retun 0 on success.

Signed-off-by: loli10K <ezomori.nozomu@gmail.com>

Pull-request: #8948 part 1/1
Alexander Motin
Avoid extra taskq_dispatch() calls by DMU.

DMU sync code calls taskq_dispatch() for each sublist of os_dirty_dnodes
and os_synced_dnodes.  Since the number of sublists by default is equal
to number of CPUs, it will dispatch equal, potentially large, number of
tasks, waking up many CPUs to handle them, even if only one or few of
sublists actually have any work to do.

This change adds check for empty sublists to avoid this.

Signed-off-by:  Alexander Motin <mav@FreeBSD.org>

Pull-request: #8909 part 1/1
Tomohiro Kusumi
Fix race in parallel mount's thread dispatching algorithm

Strategy of parallel mount is as follows.

1) Initial thread dispatching selects sets of mount points that don't
have dependencies on other sets, hence threads can/should go lock-less
and shouldn't race with other threads for other sets. Each thread
dispatched corresponds to top level directory which may or may not have
datasets mounted on sub directories.

2) Subsequent recursive thread dispatching for each thread from 1) is
to mount datasets for each set of mount points. The mount points within
each set have dependencies (i.e. child directories), so child
directories are processed only after parent directory completes.

The problem is that initial thread dispatching can spawn >1 threads
for datasets with the same top level directory, and this puts threads
under race condition. This appeared as mount issue on ZoL for ZoL having
different timing regarding mount(2) execution due to fork(2)/exec(2) of
mount(8) on mount. Fix it by libzfs_path_contains() returning true for
same paths.

Closes #8450
Closes #8833

Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>

Pull-request: #8878 part 1/1
Tomohiro Kusumi
Fix race in parallel mount's thread dispatching algorithm

Strategy of parallel mount is as follows.

1) Initial thread dispatching selects sets of mount points that don't
have dependencies on other sets, hence threads can/should go lock-less
and shouldn't race with other threads for other sets. Each thread
dispatched corresponds to top level directory which may or may not have
datasets mounted on sub directories.

2) Subsequent recursive thread dispatching for each thread from 1) is
to mount datasets for each set of mount points. The mount points within
each set have dependencies (i.e. child directories), so child
directories are processed only after parent directory completes.

The problem is that initial thread dispatching can spawn >1 threads
for datasets with the same top level directory, and this puts threads
under race condition. This appeared as mount issue on ZoL for ZoL having
different timing regarding mount(2) execution due to fork(2)/exec(2) of
mount(8) on mount. Fix it by libzfs_path_contains() returning true for
same paths.

Closes #8450
Closes #8833

Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>

Pull-request: #8878 part 1/1
Tomohiro Kusumi
Fix race in parallel mount's thread dispatching algorithm

Strategy of parallel mount is as follows.

1) Initial thread dispatching selects sets of mount points that don't
have dependencies on other sets, hence threads can/should go lock-less
and shouldn't race with other threads for other sets. Each thread
dispatched corresponds to top level directory which may or may not have
datasets mounted on sub directories.

2) Subsequent recursive thread dispatching for each thread from 1) is
to mount datasets for each set of mount points. The mount points within
each set have dependencies (i.e. child directories), so child
directories are processed only after parent directory completes.

The problem is that initial thread dispatching can spawn >1 threads
for datasets with the same top level directory, and this puts threads
under race condition. This appeared as mount issue on ZoL for ZoL having
different timing regarding mount(2) execution due to fork(2)/exec(2) of
mount(8) on mount. Fix it by libzfs_path_contains() returning true for
same paths.

Closes #8450
Closes #8833

Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>

Pull-request: #8878 part 1/1
Aleksa Sarai
tests: add tests for renameat2(2) flags

Since mv(1) doesn't expose the RENAME_* flags we need to have our own
variation in the tests/ tree. The tests are fairly obvious functional
tests, though in the future (once we solve the d_revalidate issue) we
might also add a full-stack overlayfs integration test.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 3/3
Aleksa Sarai
zfs_rename: support RENAME_* flags

Implement support for Linux's RENAME_* flags (for renameat2). Aside from
being quite useful for userspace (providing race-free ways to exchange
paths and implement mv --no-clobber), they are used by overlayfs and are
thus required in order to use overlayfs-on-ZFS.

In order for us to represent the new renameat2(2) flags in the ZIL, we
need to create a new transaction type (to be backwards-compatible).
Since RENAME_EXCHANGE and RENAME_WHITEOUT are mutually exclusive they
deserve separate types. We just re-use the logic of
zfs_{log,replay}_rename() with the only change being the transaction
types and the associate vfsflags passed to zfs_rename().

RENAME_NOREPLACE doesn't need an entry because if the renameat2(2) fails
because of RENAME_NOREPLACE there won't be a ZIL entry for the operation
(and if it succeeds then it should also succeed on-replay).

Unfortunately, more work is required in order use overlayfs-on-ZFS
(namely we have to remove our .d_revalidate hook, since overlayfs
refuses to use a filesystem with d_revalidate as an upperdir).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 2/3
Aleksa Sarai
zfs_rename: restructure to have cleaner fallbacks

This is in preparation for RENAME_EXCHANGE and RENAME_WHITEOUT support
for ZoL, but the changes here allow for far nicer fallbacks than the
previous implementation (the source and target are re-linked in case of
the final link failing).

In addition, a small cleanup was done for the "target exists but is a
different type" codepath so that it's more understandable.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 1/3
Aleksa Sarai
tests: add tests for renameat2(2) flags

Since mv(1) doesn't expose the RENAME_* flags we need to have our own
variation in the tests/ tree. The tests are fairly obvious functional
tests, though in the future (once we solve the d_revalidate issue) we
might also add a full-stack overlayfs integration test.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 3/3
Aleksa Sarai
zfs_rename: support RENAME_* flags

Implement support for Linux's RENAME_* flags (for renameat2). Aside from
being quite useful for userspace (providing race-free ways to exchange
paths and implement mv --no-clobber), they are used by overlayfs and are
thus required in order to use overlayfs-on-ZFS.

In order for us to represent the new renameat2(2) flags in the ZIL, we
need to create a new transaction type (to be backwards-compatible).
Since RENAME_EXCHANGE and RENAME_WHITEOUT are mutually exclusive they
deserve separate types. We just re-use the logic of
zfs_{log,replay}_rename() with the only change being the transaction
types and the associate vfsflags passed to zfs_rename().

RENAME_NOREPLACE doesn't need an entry because if the renameat2(2) fails
because of RENAME_NOREPLACE there won't be a ZIL entry for the operation
(and if it succeeds then it should also succeed on-replay).

Unfortunately, more work is required in order use overlayfs-on-ZFS
(namely we have to remove our .d_revalidate hook, since overlayfs
refuses to use a filesystem with d_revalidate as an upperdir).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 2/3
  • Amazon 2 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 8 ppc64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 aarch64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 i386 (BUILD): cloning zfs -  stdio
  • CentOS 6 x86_64 (BUILD): cloning zfs -  stdio
  • CentOS 7 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 9 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 18.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 17.10 x86_64 (STYLE): cloning zfs -  stdio
Aleksa Sarai
zfs_rename: restructure to have cleaner fallbacks

This is in preparation for RENAME_EXCHANGE and RENAME_WHITEOUT support
for ZoL, but the changes here allow for far nicer fallbacks than the
previous implementation (the source and target are re-linked in case of
the final link failing).

In addition, a small cleanup was done for the "target exists but is a
different type" codepath so that it's more understandable.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 1/3
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
Aleksa Sarai
tests: add tests for renameat2(2) flags

Since mv(1) doesn't expose the RENAME_* flags we need to have our own
variation in the tests/ tree. The tests are fairly obvious functional
tests, though in the future (once we solve the d_revalidate issue) we
might also add a full-stack overlayfs integration test.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 3/3
Aleksa Sarai
zfs_rename: support RENAME_* flags

Implement support for Linux's RENAME_* flags (for renameat2). Aside from
being quite useful for userspace (providing race-free ways to exchange
paths and implement mv --no-clobber), they are used by overlayfs and are
thus required in order to use overlayfs-on-ZFS.

In order for us to represent the new renameat2(2) flags in the ZIL, we
need to create a new transaction type (to be backwards-compatible).
Since RENAME_EXCHANGE and RENAME_WHITEOUT are mutually exclusive they
deserve separate types. We just re-use the logic of
zfs_{log,replay}_rename() with the only change being the transaction
types and the associate vfsflags passed to zfs_rename().

RENAME_NOREPLACE doesn't need an entry because if the renameat2(2) fails
because of RENAME_NOREPLACE there won't be a ZIL entry for the operation
(and if it succeeds then it should also succeed on-replay).

Unfortunately, more work is required in order use overlayfs-on-ZFS
(namely we have to remove our .d_revalidate hook, since overlayfs
refuses to use a filesystem with d_revalidate as an upperdir).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 2/3
  • Amazon 2 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 8 ppc64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 aarch64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 i386 (BUILD): cloning zfs -  stdio
  • CentOS 6 x86_64 (BUILD): cloning zfs -  stdio
  • CentOS 7 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 9 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 18.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 17.10 x86_64 (STYLE): cloning zfs -  stdio
Aleksa Sarai
zfs_rename: restructure to have cleaner fallbacks

This is in preparation for RENAME_EXCHANGE and RENAME_WHITEOUT support
for ZoL, but the changes here allow for far nicer fallbacks than the
previous implementation (the source and target are re-linked in case of
the final link failing).

In addition, a small cleanup was done for the "target exists but is a
different type" codepath so that it's more understandable.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 1/3
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
Aleksa Sarai
tests: add tests for renameat2(2) flags

Since mv(1) doesn't expose the RENAME_* flags we need to have our own
variation in the tests/ tree. The tests are fairly obvious functional
tests, though in the future (once we solve the d_revalidate issue) we
might also add a full-stack overlayfs integration test.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 3/3
Aleksa Sarai
zfs_rename: support RENAME_* flags

Implement support for Linux's RENAME_* flags (for renameat2). Aside from
being quite useful for userspace (providing race-free ways to exchange
paths and implement mv --no-clobber), they are used by overlayfs and are
thus required in order to use overlayfs-on-ZFS.

In order for us to represent the new renameat2(2) flags in the ZIL, we
need to create a new transaction type (to be backwards-compatible).
Since RENAME_EXCHANGE and RENAME_WHITEOUT are mutually exclusive they
deserve separate types. We just re-use the logic of
zfs_{log,replay}_rename() with the only change being the transaction
types and the associate vfsflags passed to zfs_rename().

RENAME_NOREPLACE doesn't need an entry because if the renameat2(2) fails
because of RENAME_NOREPLACE there won't be a ZIL entry for the operation
(and if it succeeds then it should also succeed on-replay).

Unfortunately, more work is required in order use overlayfs-on-ZFS
(namely we have to remove our .d_revalidate hook, since overlayfs
refuses to use a filesystem with d_revalidate as an upperdir).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 2/3
  • Debian 8 ppc64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 aarch64 (BUILD): cloning zfs -  stdio
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
Aleksa Sarai
zfs_rename: restructure to have cleaner fallbacks

This is in preparation for RENAME_EXCHANGE and RENAME_WHITEOUT support
for ZoL, but the changes here allow for far nicer fallbacks than the
previous implementation (the source and target are re-linked in case of
the final link failing).

In addition, a small cleanup was done for the "target exists but is a
different type" codepath so that it's more understandable.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 1/3
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
Aleksa Sarai
tests: add tests for renameat2(2) flags

Since mv(1) doesn't expose the RENAME_* flags we need to have our own
variation in the tests/ tree. The tests are fairly obvious functional
tests, though in the future (once we solve the d_revalidate issue) we
might also add a full-stack overlayfs integration test.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 3/3
Aleksa Sarai
zfs_rename: support RENAME_* flags

Implement support for Linux's RENAME_* flags (for renameat2). Aside from
being quite useful for userspace (providing race-free ways to exchange
paths and implement mv --no-clobber), they are used by overlayfs and are
thus required in order to use overlayfs-on-ZFS.

In order for us to represent the new renameat2(2) flags in the ZIL, we
need to create a new transaction type (to be backwards-compatible).
Since RENAME_EXCHANGE and RENAME_WHITEOUT are mutually exclusive they
deserve separate types. We just re-use the logic of
zfs_{log,replay}_rename() with the only change being the transaction
types and the associate vfsflags passed to zfs_rename().

RENAME_NOREPLACE doesn't need an entry because if the renameat2(2) fails
because of RENAME_NOREPLACE there won't be a ZIL entry for the operation
(and if it succeeds then it should also succeed on-replay).

Unfortunately, more work is required in order use overlayfs-on-ZFS
(namely we have to remove our .d_revalidate hook, since overlayfs
refuses to use a filesystem with d_revalidate as an upperdir).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 2/3
  • Amazon 2 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 8 ppc64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 aarch64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 i386 (BUILD): cloning zfs -  stdio
  • CentOS 7 x86_64 (BUILD): cloning zfs -  stdio
  • Debian 9 x86_64 (BUILD): cloning zfs -  stdio
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 18.04 x86_64 (BUILD): cloning zfs -  stdio
Aleksa Sarai
zfs_rename: restructure to have cleaner fallbacks

This is in preparation for RENAME_EXCHANGE and RENAME_WHITEOUT support
for ZoL, but the changes here allow for far nicer fallbacks than the
previous implementation (the source and target are re-linked in case of
the final link failing).

In addition, a small cleanup was done for the "target exists but is a
different type" codepath so that it's more understandable.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

Pull-request: #8667 part 1/3
  • Debian 9 x86_64 (BUILD): cloning zfs -  stdio
  • Kernel.org Built-in x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 16.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 18.04 x86_64 (BUILD): cloning zfs -  stdio
  • Ubuntu 17.10 x86_64 (STYLE): cloning zfs -  stdio