Properly initialize the variable resid for the error case where
vn_rdwr() returns an error with setting *resid. In practice
this is harmless because the contents of resid don't matter
when vn_rdwr() returns an error. But the code does check the
result which means we may or may not end up having the check
zio->io_error. This makes gcc unhappy and having a completely
deterministic code path here is a good thing.
Closes#51
The upstream commit cb code had a few bugs:
1) The arguments of the list_move_tail() call in txg_dispatch_callbacks()
were reversed by mistake. This caused the commit callbacks to not be
called at all.
2) ztest had a bug in ztest_dmu_commit_callbacks() where "error" was not
initialized correctly. This seems to have caused the test to always take
the simulated error code path, which made ztest unable to detect whether
commit cbs were being called for transactions that successfuly complete.
3) ztest had another bug in ztest_dmu_commit_callbacks() where the commit
cb threshold was not being compared correctly.
4) The commit cb taskq was using 'max_ncpus * 2' as the maxalloc argument
of taskq_create(), which could have caused unnecessary delays in the txg
sync thread.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Implement zio_execute() as a wrapper around the static function
__zio_execute() so that we can force __zio_execute() to be inlined.
This reduces stack overhead which is important because __zio_execute()
is called recursively in several zio code paths. zio_execute() itself
cannot be inlined because it is externally visible.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Add two additional basic sanity tests to confirm zvol snapshots
and clones work. The snapshot test is basically the same as the
example provided in the wiki. The clone test goes one step father
and clones the snapshot then modifies it to match the original
modified volume. It them compares them to ensure everything was
modified as expected.
These are just meant to be sanity tests to catch obvious breakage
before tagging a release. They are still not a substitute for a
full regression test suite.
It appears that in earlier kernels the maximum name length of a
kobject was KOBJ_NAME_LEN (20) bytes. This was later extended to
dynamically allocate enough memory if it was over KOBJ_NAME_LEN,
and finally it was always made dynamic. Unfortunately, util this
last step happened it doesn't look like it always safe to use
names larger than KOBJ_NAME_LEN. For example, under the RHEL5
2.6.18 kernel if the kobject name length exceeds KOBJ_NAME_LEN
a NULL dereference is tripped.
To avoid this issue the build system has been update to check
to see if KOBJ_NAME_LEN is defined. If it is we have to assume
the maximum kobject name length is only 20 bytes. This 20 byte
name must minimally include the following components.
<zpool>/<dataset>[@snapshot[partition]]
While the zfs utilities do block until the expected device appears
they can only do this for full devices, not partitions. This means
that once as device appears it still may take a little bit of time
before the kernel rescans the partition table, updates sysfs, udev
is notified and the partition devices are created. The test case
itself could block briefly waiting for the partition beause it knows
what to expect. But for now the simpler thing to do is just delay.
See previous commit for details. But the gist is with the removal of
the zvol path component the regression tests must be updated to use
the correct path name.
This reverts commit 421d95b3ea.
Ricardo correctly pointed out that there is more going on here than
typecasting. By removing the locals we are actually causing LEFT and
RIGHT to be evaluated twice which can potentially lead to some
strange side effects as:
1) VERIFY3*() causing a panic but in the panic message the values
look correct such that the assertion shouldn't fail, or:
2) if LEFT or RIGHT are expressions with side-effects (e.g. a call
to a function which changes some state), then when we panic and
examine the crash dump, it may lead to an unexpected state because
we are not expecting certain things to change during the panic,
after the expressions inside VERIFY3*(...) have been evaluated.
3) Also, it may lead to double-panics or deadlocks during panics,
like for example, if the expressions inside VERIFY3*(...) only expect
to be called once (e.g. because they acquire a mutex).
Brian Behlendorf
Ricardo M. Correia
Ned Bass