by /sbin/{zfs,zpool,mount_zfs}. The general effect is to move them
from /usr/lib to /lib. Compatibility links are installed in /usr/lib
and nothing that is installed, say in /usr/pkg, appears to break.
With this, it is possible to have a /var and /usr mount using ZFS
legacy mounting early on in the boot process.
Run tested on amd64 and i386 and compile tested on evbarm.
in the ZFS properties of the dataset and a simple man page for
mount_zfs. With this, it is possible to put ZFS filesystems in
/etc/fstab as file system type zfs.
Add a rc.d script that kicks the module ZFS load mostly before
mountall runs simular to what LVM does. This allows for any legacy
mounts to be specified in critical_local_filesystems and allows for
ZFS pools on top of cgd (probably among other things). Introduce a
rc.conf variable called zfs which needs to be set to YES, in the usual
manor of things, to get zvols and ZFS dataset support rather then just
assume that 'zfs mount' does that in mountall. Fix a problem in
mountall if ZFS is not compiled into the system.
remove now unneeded files from "external/cddl/osnet/sys/sys/".
- sys/sys/bitmap.h -> dist/uts/common/sys/bitmap.h
- sys/sys/callb.h -> dist/uts/common/sys/callb.h
Stop including "cpupart.h", not needed for build.
GENRIC kernel below 2**15-1 (from ~34000 to ~29800).
Remove the type attributes "volatile", "const" and "restrict",
for DTRACE these attributes are of little value.
FreeBSD splits "zfs_context.h" into:
"lib/libzpool/common/sys/zfs_context.h" for user space
"uts/common/fs/zfs/sys/zfs_context.h" for kernel space
Do the same here, move and sync "sys/sys/zfs_context.h" to
"dist/lib/libzpool/common/sys/zfs_context.h" and
"dist/uts/common/fs/zfs/sys/zfs_context.h".
Change "Makefile.zfs" to search includes from "dist/lib"
before "dist/uts" so we get the right include file.
Adapt "usr.sbin/fstyp/Makefile" to get the right include file.
zfs_suspend_fs()/zfs_resume_fs() and get rid of dead "z_sa_hdl == NULL"
znodes before vfs_resume() to keep the vnode cache consistent.
Live rollback should work now.
PR port-xen/54273 ("zpool create pool xbd2" panics DOMU kernel)
the latter implicitly calls cv_signal() on error.
This leads to "tq_waiting > 0" with "tq_running == 0" and the
taskq stalls.
Change task_executor() to increment and decrement "tq_waiting"
and always check and run the queue after cv_timedwait().
Use mstohz(), fix timeout and sort includes.
Addresses PR port-xen/54273: "zpool create pool xbd2" panics DOMU kernel
Change zvol_size_changed() to initialize "zv->zv_volsize"
and initialize only "dg_secsize" and "dg_secperunit".
Calling disk_set_info() will initialize the remaining
parts of the geometry.
Set "doread" in zvol_strategy() to make reading from
device possible.
Reorganize/add disk_busy()/disk_unbusy() instrumentation.
Redo zvol_ioctl() to implement DIOCGWEDGEINFO and let
disk_ioctl() process the remaining ioctls.
- Put device major numbers into "dev_info_t".
- Fix an off-by-one in zvol_create_minor().
- When creating a node handle existing nodes
and add owner read/write permission.
- When removing nodes remove now empty directories.
- Defer spa_config_load() until root is mounted.
- Restore the config path to "/etc/zfs/zpool.cache".
- Module "zfs" is type MODULE_CLASS_VFS and no longer depends on "rootvnode".
- Module "solaris" no longer depends on "mp_online".
- Fix rump component registration to not detach "/dev/zfs" if
it didn't attach it.
Solaris upstream. FreeBSD already replaced it with a glue to their
taskqueue API.
Replace it with a glue component that queues Solaris taskq requests to
threadpool jobs.
like FreeBSD and Illumos do.
Use "f_fsid" for "va_fsid" and cheat NFSD to export snapshots under
".zfs" by setting these snaphots "f_fsidx" to the parents "f_fsidx".
Register cmajor 252 for fbt and 253 for sdt.
Previously the major number was picked randomly and it causes conflicts
with preallocated values for different devices.
Don't take a mount reference for fstrans as it gets notified about the release.
Defer the final free of the mount to fstrans_mount_dtor() when fstrans
has released all references to this mount. Prevents the mount's memory
to be reused as a new mount before fstrans released all references.
Address PR kern/53928 modules/t_builtin:disable test case randomly fails.
- Move the stub routines from zfs_stub.c to zfs_ctldir.c and
remove now empty file zfs_stub.c
- Add stub routines for zfsctl_loadvnode() to initialize control
nodes and zfsctl_snapshot() to retrieve ".zfs/snapshot".
- Add an initial vnode operations vector for control nodes.
- Implement lookup into ".zfs" and lookup ".." from ".zfs/snapshot/<snap>".
- Change nodeid of mounted snapshots to the snapshot object id.
- Respect "-u" flag to "zfs rename <snapshot> ...".
to respect the teardown lock.
Enter z_teardown_lock as reader and ZFS_EXIT().
Instead of ZFS_VERIFY_ZP() return without writing and without
error from zfs_putapage() if "z_sa_hdl == NULL".
deadlock with another reclaim.
Add vfs operation zfs_newvnode() to create a new zfs node and
hold the zfs object in zfs_loadvnode() and zfs_newvnode() only.
ZFS expects a null-terminated name.
Always create a copy with PNBUF_GET()/strlcpy()/PNBUF_PUT().
For LOOKUP use a small buffer on stack and allocate/free compomnent names
longer than 30 chars.
further dmu_tx_assign() fails because over quota or no space.
Use the emulated uiocopy() and uioskip() like illumos does.
Fix the uiocopy() emulation to not clobber the iovecs.
Use user flag UF_NODUMP instead of UF_IMMUTABLE for the test as it
is the only user flag supported by all tested file systems.
PR kern/47656 test zfs_flags.
It turns out this code always sees __HAVE_MM_MD_DIRECT_MAPPED_PHYS as
disabled on amd64, for reasons that I shall address forthwith, but it
is enabled on aarch64 and so the MKZFS=yes build breaks.
As it happens, on x86 both _HARDKERNEL and _KERNEL get defined; see
the conditional in sys/rump/Makefile.rump that _refrains_ from
defining _RUMPKERNEL on x86.
So the only version of this code that has been tested is the one with
all of it included. But on, e.g., aarch64, we do not get _HARDKERNEL
here, and the code fails to build because some things use the field
struct spa::spa_deadman_cycid under _KERNEL when it is declared only
under _HARDKERNEL.
If there's a reason _not_ to use this in rump -- and it's not obvious
to me why -- then all access to the field needs to agree to use
_HARDKERNEL.
Rather than write out a table for each architecture, rely on the C
compiler to define _LP64 for 64-bit ones, on the assumption that
anything not LP64 is ILP32, and on CTASSERTs to verify this
assumption so that if it's wrong it'll fail safely with a noisy build
failure.
Gives zfs half a chance of building on, e.g., powerpc.
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
Comment here already says it isn't necessary and will be removed.
Hasten the process for us and avoid the problematic typedef.
This is useful because u_longlong_t would otherwise need to be
provided by compat headers.
Mark arguments to dtrace_probe_lookup() with __UNCONST().
The proper fix constifying it causes pollution of const in too many files.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Constify char* types when initialized with liternals.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Constify dgr_suffix.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Use __UNCONST() to remove const from an argument.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Add missing const keywords in dtrace_strncmp().
Initialize lim1 and lim2 to zero always. This prevents a false positive
about potentially unset but used variable.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Clang/LLVM does not recognize:
- -Wno-discarded-qualifiers
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Add missing const keywords.
This could be done with -W flags, but they are incompatible between
compilers.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Clang/LLVM does not recognize:
- -Wno-discarded-qualifiers
- -Wno-unused-but-set-variable
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
Clang/LLVM does not recognize:
- -Wno-maybe-uninitialized
- -Wno-unused-but-set-variable
MKGCC=yes still builds the distribution.
This is a step forward functional MKLLVM=yes HAVE_LLVM=yes build.
Sponsored by <The NetBSD Foundation>
merge a new version of the CDDL dtrace and ZFS code.
this changes the upstream vendor from OpenSolaris to FreeBSD,
and this version is based on FreeBSD svn r315983.
in addition to the 10 years of improvements from upstream,
this version also has these NetBSD-specific enhancements:
- dtrace FBT probes can now be placed in kernel modules.
- ZFS now supports mmap().
this changes the upstream vendor from OpenSolaris to FreeBSD,
and this version is based on FreeBSD svn r315983.
in addition to the 10 years of improvements from upstream,
this version also has these NetBSD-specific enhancements:
- dtrace FBT probes can now be placed in kernel modules.
- ZFS now supports mmap().
The following scripts are installed:
dtruss - a DTrace version of truss.
execsnoop - snoop process execution as it occurs.
opensnoop - snoop file opens as they occur.
procsystime - print process system call time details.
ok riastradh
While it fixed the problem of trailing spaces, but if the probe specifier
contained leading spaces, it would brake dtrace. The proper fix would be
to skip the leading spaces in the string as well.
However, it would result in a bigger diff for a very small benefit. While
a new import of dtrace is impending, it's better not to have this change.
Discussed with christos.
When using dtrace using one of the tracing options, such as -n, -P, -i, -f etc.,
the first line of output from dtrace one is something like this:
sudo dtrace -n 'syscall:::entry /pid == 100/ {@num[probefunc] = count();}'
dtrace: description 'syscall:::entry ' matched 482 probes
There is a trailing space at the end of the probe specifier name ('syscall:::entry ').
This happens beucase dtrace tries to separate the probe name from the predicate and actions
using `{' and `/' as the separators but doesn't consider space also as a possible separator.
Output after this change:
sudo dtrace -n 'syscall:::entry /pid == 100/ {@num[probefunc] = count();}'
dtrace: description 'syscall:::entry' matched 482 probes
ok christos@
VOP_RECLAIM naturally has exclusive access to the vnode, so having it
locked on entry is not strictly necessary -- but it means if there
are any final operations that must be done on the vnode, such as
ffs_update, requiring exclusive access to it, we can now kassert that
the vnode is locked in those operations.
We can't just have the caller release the last lock because some file
systems don't use genfs_lock, and require the vnode to remain valid
for VOP_UNLOCK to work, notably unionfs.
fix the dtrace "args" variable to return correct values.
simplify the invop handlers a bit by changing the second argument
from a pointer into the stack to a pointer to the trapframe.
rather than including in kernels with KDTRACE_HOOKS defined. Update
the dtrace_fbt module to depend on the zlib module.
Bump kernel version to avoid module mismatch.
Welcome to 7.99.38 !
Fix DTrace's panic() action.
It would previously call into some unfinished Solaris compatibility code
and return without actually calling panic(9). The compatibility code is
unneeded, however, so just remove it and have dtrace_panic() call vpanic(9)
directly.
Fixes immediate problem in PR-51265. However, this now reveals another
redefined symbol 'strpbrk' in the required module "solaris".
[1] https://svnweb.freebsd.org/changeset/base/281916
[2] http://lists.freebsd.org/pipermail/svn-src-head/2015-April/071019.html
r211608 | rpaulo | 2010-08-22 03:53:32 -0700 (Sun, 22 Aug 2010) | 8 lines
Kernel DTrace support for:
o uregs (sson@)
o ustack (sson@)
o /dev/dtrace/helper device (needed for USDT probes)
The work done by me was:
Sponsored by: The FreeBSD Foundation
plus a few netbsd-specific tweaks from me.
fixes PR 50790.
Fix a couple of bugs around the handling of structs and unions of size zero.
These would cause ctfconvert(1) to return an error when attempting to
resolve valid C types.
If MKDTRACE=yes MKCTF=no makes no sense, we can express that
somewhere else, not as a confusing set lists error at the end -- as
far as I know, there's no way to express MKDTRACE *or* MKCTF as a
condition for set list entries.
brad