This is for marking a test case is flakey and should not be executed in
the CI environment.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34635
In 9fae47666 zfsd got a libspl dependency to avoid undefined references.
However that workaround did not help external consumers of libzfs_core.
Fix all missing dependencies lld 13 and the rtld complain about.
Reviewed by: freqlabs, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32521
Because lld 13.0.0 is more strict about undefined references when
linking to shared libraries, it produces the following errors for zfsd:
ld: error: /home/dim/obj/home/dim/src/llvm-13-update/amd64.amd64/tmp/usr/lib/libzfs_core.so: undefined reference to libspl_assertf [--no-allow-shlib-undefined]
ld: error: /home/dim/obj/home/dim/src/llvm-13-update/amd64.amd64/tmp/usr/lib/libnvpair.so: undefined reference to libspl_assertf [--no-allow-shlib-undefined]
ld: error: /home/dim/obj/home/dim/src/llvm-13-update/amd64.amd64/tmp/usr/lib/libavl.so: undefined reference to libspl_assertf [--no-allow-shlib-undefined]
*** [zfsd.full] Error code 1
Fix this by adding libspl (where libspl_assertf lives) to zfsd's LIBADD.
MFC after: 3 days
Onlining a vdev can fail. Log the error if it does.
Reviewed by: mav, asomers
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D30882
WITHOUT_LIBTHR has been broken for a little over five years now, since the
xz 5.2.0 update introduced a hard liblzma dependency on libthr, and building
a useful system without threading support is becoming increasingly more
difficult.
Additionally, in the five plus years that it's been broken more reverse
dependencies have cropped up in libzstd, libsqlite3, and libcrypto (among
others) that make it more and more difficult to reconcile the effort needed
to fix these options.
Remove the broken options.
PR: 252760
Reviewed by: brooks, emaste, kib
Differential Revision: https://reviews.freebsd.org/D28263
Found this while trying to get macOS bootstrap to work again after OpenZFS merge.
Reviewed By: #zfs, freqlabs
Differential Revision: https://reviews.freebsd.org/D26192
The primary benefit is maintaining a completely shared
code base with the community allowing FreeBSD to receive
new features sooner and with less effort.
I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.
Work on merging FreeBSD support in to what was
at the time "ZFS on Linux" began in August 2018.
I first publicly proposed transitioning FreeBSD
to (new) OpenZFS on December 18th, 2018. FreeBSD
support in OpenZFS was finally completed in December
2019. A CFT for downstreaming OpenZFS support in
to FreeBSD was first issued on July 8th. All issues
that were reported have been addressed or, for
a couple of less critical matters there are
pull requests in progress with OpenZFS. iXsystems
has tested and dogfooded extensively internally.
The TrueNAS 12 release is based on OpenZFS with
some additional features that have not yet made
it upstream.
Improvements include:
project quotas, encrypted datasets,
allocation classes, vectorized raidz,
vectorized checksums, various command line
improvements, zstd compression.
Thanks to those who have helped along the way:
Ryan Moeller, Allan Jude, Zack Welch, and many
others.
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25872
To define USDT probes, dtrace -G makes use of relocations for undefined
symbols: the target address is overwritten with NOPs and the location is
recorded in the DOF section of the output object file. To avoid link
errors, the original relocation is destroyed. However, this means that
the same input object file cannot be processed multiple times, as
happens during incremental rebuilds. Instead, only set the relocation
type to NONE, so that all information required to reconstruct USDT
probes is preserved.
Reported by: bdrewery
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Create two tests checking if we can read urgs registers and if the
rax register returns a correct number.
Reviewed by: markj
Discussed with: lwhsu
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20364
This change integrates the unit tests for zfsd into the test suite using the
integration method described in r345203.
This change removes the `LOCALBASE` includes added for the port version of
googlemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`
defines, which are included in the `GTEST_CXXFLAGS` variable, as part of
r345203.
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 2 months
MFC with: r345203
Differential Revision: https://reviews.freebsd.org/D19552
SCTP. They are based on what is specified in the Solaris DTrace manual
for Solaris 11.4.
Reviewed by: 0mp, dteske, markj
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16839
The dtrace provider for UDP-Lite is modeled after the UDP provider.
This fixes the bug that UDP-Lite packets were triggering the UDP
provider.
Thanks to dteske@ for providing the dwatch module.
Reviewed by: dteske@, markj@, rrs@
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16377
Ensure that the TCP connections are terminated gracefully as expected
by the test. Use appropriate numbers for sent/received packets.
In addition, enable tst.localtcpstate.ksh, which should pass, but
doesn't until https://reviews.freebsd.org/D16369 is committed.
Reviewed by: markj@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D16288
The code imported from opensolaris was depending on ping supporting
UDP for sending probes. Since this is not supported by ping on FreeBSD
use a perl script instead.
The remote test requires the usage of ksh93, so state that in the
sheband.
Enable the local test, but keep the remote test disabled, since it
requires a remote machine on the LAN.
Reviewed by: markj@, gnn@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D16268
Profiles that perform post-processing of the DTrace output were
dropping the "-t test" option on the floor. Fix handling of this
option for said profiles.
X-MFC-to: stable/11
X-MFC-with: r334261-334262
Sponsored by: Smule, Inc.
"Developer mode" (passing of "-dev" options), which enables debugging
features on compilation error, used to dim lines unrelated to error.
That proved distracting and feedback from testers also confirmed that
simply highlighting the line the compiler complains about is enough.
Sponsored by: Smule, Inc.
dwatch allows you to customnize the predicate (condition) for when
information is displayed. The DTrace syntax for this is:
probe[, ...] /predicate/ { [actions] }
But if predicate is something like "*args[1]!=NULL" to test that
the first pointer in an array is non-NULL, the syntax produced is:
probe[, ...] /*arg1!=NULL/ { [actions] }
The issue being that "/*" is the beginning of a comment and thus
the following error is emitted:
dtrace: failed to compile script /dev/stdin:
line 535: /* encountered inside a comment
This patch adds whitespace around the argument given to -t,
producing:
probe[, ...] / *arg1!=NULL / { [actions] }
Sponsored by: Smule, Inc.
The profile for send(2)/recv(2) observation has been refactored to
eliminate alloca() in favor of translations available in HEAD.
Sponsored by: Smule, Inc.
Knowing the value of execname during these probes is of some value even
if it is commonly the interrupt kernel thread (intr[12]) -- quite often
it is not, but that depends on the probe.
Sponsored by: Smule, Inc.
A module that wishes to post-process the output needs to know which
arguments were passed in order to re-execute a child in a pipe-chain.
Further, the expansion of ARGV needs to be such that items are escaped
properly.
Sponsored by: Smule, Inc.
If you were to pass an invalid option after `-B num' or `-K num' you
would see that the usage statement would show the value you passed
instead of the actual default.
Moving the default values to separate variables that are unaffected
by the options-parsing allows the usage statement to correctly show
the hard-coded default values if no flags are used.
Sponsored by: Smule, Inc.
A return statement should have been an exit in list_profiles().
If the user passed `-Q' to list profiles and asked for one-line
per profile (`-1'), list_profiles() would not exit as should.
Sponsored by: Smule, Inc.
In recently added sendrecv profile, there was a line purposefully
added to introduce a compilation error in which `-dev' is used to
debug the entry. Removing the entry.
Sponsored by: Smule, Inc.
The options `-d' (debug), `-e' (exit after compile), and `-v' (verbose)
when combined in any order (though best remembered as `-dev') will run
the conflated script through dtrace(1), test for error conditions, and
show the line that dtrace(1) failed at (with context).
If no errors are found, the output is the same as `-e[v]'.
When writing a new profile for dwatch(1), you can quickly test to
make sure it compiles by running `dwatch -devX profile_name' where
profiles live in /usr/libexec/dwatch or /usr/local/libexec/dwatch
(the latter being where profiles installed via ports should go).
Sponsored by: Smule, Inc.
illumos/illumos-gate@7855d95b307855d95b30https://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.
If there are no damaged pools, then ignore all GEOM events. We only use
them to fix damaged pools. However, still pay attention to ZFS events.
MFC after: 20 days
X-MFC-With: 329284
Sponsored by: Spectra Logic Corp
cddl/usr.sbin/zfsd/zfsd_event.cc
Remove the check for da and ada devices. This way zfsd can work on md,
geli, glabel, gstripe, etc devices. geli in particular is useful
combined with ZFS. gnop is also useful for simulating drive pulls in
the ZFSD test suite.
Also, eliminate the DevfsEvent class entirely. Move its
responsibilities into GeomEvent. We can get everything we need to know
just from listening to GEOM events.
lib/libdevdctl/event.cc
Fix GeomEvent::DevName for CREATE events. Oddly, the relevant field is
named "cdev" for CREATE events but "devname" for disk events.
MFC after: 3 weeks
Relnotes: Yes (probably worth mentioning the geli part)
Sponsored by: Spectra Logic Corp
