The ZIO pipeline has been modified to allow for external,
alternative implementations of existing operations to be
used. The original ZFS functions remain in the code as
fallback in case the external implementation fails.
Definitions:
Accelerator - an entity (usually hardware) that is
intended to accelerate operations
Offloader - synonym of accelerator; used interchangeably
Data Processing Unit Services Module (DPUSM)
- https://github.com/hpc/dpusm
- defines a "provider API" for accelerator
vendors to set up
- defines a "user API" for accelerator consumers
to call
- maintains list of providers and coordinates
interactions between providers and consumers.
Provider - a DPUSM wrapper for an accelerator's API
Offload - moving data from ZFS/memory to the accelerator
Onload - the opposite of offload
In order for Z.I.A. to be extensible, it does not directly
communicate with a fixed accelerator. Rather, Z.I.A. acquires
a handle to a DPUSM, which is then used to acquire handles
to providers.
Using ZFS with Z.I.A.:
1. Build and start the DPUSM
2. Implement, build, and register a provider with the DPUSM
3. Reconfigure ZFS with '--with-zia=<DPUSM root>'
4. Rebuild and start ZFS
5. Create a zpool
6. Select the provider
zpool set zia_provider=<provider name> <zpool>
7. Select operations to offload
zpool set zia_<property>=on <zpool>
The operations that have been modified are:
- compression
- non-raw-writes only
- decompression
- checksum
- not handling embedded checksums
- checksum compute and checksum error call the same function
- raidz
- generation
- reconstruction
- vdev_file
- open
- write
- close
- vdev_disk
- open
- invalidate
- write
- flush
- close
Successful operations do not bring data back into memory after
they complete, allowing for subsequent offloader operations
reuse the data. This results in only one data movement per ZIO
at the beginning of a pipeline that is necessary for getting
data from ZFS to the accelerator.
When errors ocurr and the offloaded data is still accessible,
the offloaded data will be onloaded (or dropped if it still
matches the in-memory copy) for that ZIO pipeline stage and
processed with ZFS. This will cause thrashing if a later
operation offloads data. This should not happen often, as
constant errors (resulting in data movement) is not expected
to be the norm.
Unrecoverable errors such as hardware failures will trigger
pipeline restarts (if necessary) in order to complete the
original ZIO using the software path.
The modifications to ZFS can be thought of as two sets of changes:
- The ZIO write pipeline
- compression, checksum, RAIDZ generation, and write
- Each stage starts by offloading data that was not
previously offloaded
- This allows for ZIOs to be offloaded at any point
in the pipeline
- Resilver
- vdev_raidz_io_done (RAIDZ reconstruction, checksum, and
RAIDZ generation), and write
- Because the core of resilver is vdev_raidz_io_done, data
is only offloaded once at the beginning of
vdev_raidz_io_done
- Errors cause data to be onloaded, but will not
re-offload in subsequent steps within resilver
- Write is a separate ZIO pipeline stage, so it will
attempt to offload data
The zio_decompress function has been modified to allow for
offloading but the ZIO read pipeline as a whole has not, so it
is not part of the above list.
An example provider implementation can be found in
module/zia-software-provider
- The provider's "hardware" is actually software - data is
"offloaded" to memory not owned by ZFS
- Calls ZFS functions in order to not reimplement operations
- Has kernel module parameters that can be used to trigger
ZIA_ACCELERATOR_DOWN states for testing pipeline restarts.
abd_t, raidz_row_t, and vdev_t have each been given an additional
"void *<prefix>_zia_handle" member. These opaque handles point to
data that is located on an offloader. abds are still allocated,
but their payloads are expected to diverge from the offloaded copy
as operations are run.
Encryption and deduplication are disabled for zpools with Z.I.A.
operations enabled
Aggregation is disabled for offloaded abds
RPMs will build with Z.I.A.
Signed-off-by: Jason Lee <jasonlee@lanl.gov>
Provide a common zfs_file_* interface which can be implemented on all
platforms to perform normal file access from either the kernel module
or the libzpool library.
This allows all non-portable vnode_t usage in the common code to be
replaced by the new portable zfs_file_t. The associated vnode and
kobj compatibility functions, types, and macros have been removed
from the SPL. Moving forward, vnodes should only be used in platform
specific code when provided by the native operating system.
Reviewed-by: Sean Eric Fagan <sef@ixsystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Matt Macy <mmacy@FreeBSD.org>
Closes#9556
The introduction of parallel zvol prefetch causes deadlock when using
vdev_file.
spa_async->(spa_namespace_lock)->txg_wait_synced->(wait for txg_sync)
txg_sync->zio_wait->(wait for vdev_file_io_fsync on system_taskq)
zvol_prefetch_minors_impl (on system_taskq)->spa_open_common->(wait for spa_namespace_lock)
We fix this by using dedicated taskq for vdev_file. This same change
was originally made in commit bc25c93 but reverted in commit aa9af22
when dynamic taskqs were added.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Chunwei Chen <tuxoko@gmail.com>
Closes#5506Closes#5495
Over the years the default values for the taskqs used on Linux have
differed slightly from illumos. In the vast majority of cases this
was done to avoid creating an obnoxious number of idle threads which
would pollute the process listing.
With the addition of support for dynamic taskqs all multi-threaded
queues should be created as dynamic taskqs. This allows us to get
the best of both worlds.
* The illumos default values for the I/O pipeline can be restored.
These values are known to work well for most workloads. The only
exception is the zio write interrupt taskq which is changed to
ZTI_P(12, 8). At least under Linux more threads has been shown
to improve performance, see commit 7e55f4e.
* Reduces the number of idle threads on the system when it's not
under heavy load. The maximum number of threads will only be
created when they are required.
* Remove the vdev_file_taskq and rely on the system_taskq instead
which is now dynamic and may have up to 64-threads. Again this
brings us back inline with upstream.
* Tasks dispatched with taskq_dispatch_ent() are allowed to use
dynamic taskqs. The Linux taskq implementation supports this.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Tim Chase <tim@chase2k.com>
Closes#3507
Originally, vdev_file used system_taskq. This would cause a deadlock,
especially on system with few CPUs. The reason is that the prefetcher
threads, which are on system_taskq, will sometimes be blocked waiting
for I/O to finish. If the prefetcher threads consume all the tasks in
system_taskq, the I/O cannot be served and thus results in a deadlock.
We fix this by creating a dedicated vdev_file_taskq for vdev_file I/O.
Signed-off-by: Chunwei Chen <tuxoko@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes#2270
One of the neat tricks an autoconf style project is capable of
is allow configurion/building in a directory other than the
source directory. The major advantage to this is that you can
build the project various different ways while making changes
in a single source tree.
For example, this project is designed to work on various different
Linux distributions each of which work slightly differently. This
means that changes need to verified on each of those supported
distributions perferably before the change is committed to the
public git repo.
Using nfs and custom build directories makes this much easier.
I now have a single source tree in nfs mounted on several different
systems each running a supported distribution. When I make a
change to the source base I suspect may break things I can
concurrently build from the same source on all the systems each
in their own subdirectory.
wget -c http://github.com/downloads/behlendorf/zfs/zfs-x.y.z.tar.gz
tar -xzf zfs-x.y.z.tar.gz
cd zfs-x-y-z
------------------------- run concurrently ----------------------
<ubuntu system> <fedora system> <debian system> <rhel6 system>
mkdir ubuntu mkdir fedora mkdir debian mkdir rhel6
cd ubuntu cd fedora cd debian cd rhel6
../configure ../configure ../configure ../configure
make make make make
make check make check make check make check
This change also moves many of the include headers from individual
incude/sys directories under the modules directory in to a single
top level include directory. This has the advantage of making
the build rules cleaner and logically it makes a bit more sense.
Jason Lee
Tino Reichardt
Matthew Macy
Chunwei Chen
Brian Behlendorf