The dmu_objset_register_type() function is required by the Lustre
quota code in order to inform the DMU of the uid/gid of a given
object for the purposes of space accounting.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ricardo M. Correia <ricardo.correia@oracle.com>
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
Both of these allocations are larger than 8k which trips the
warning, but so no large that they must be vmem_alloc()'ed. For
this case I have added the KM_NODEBUG flag which silences the
warning. The flag also acts as a marker in the source so I can
keep track of this as something which needs to be better addressed
in the long term.
SPL: large kmem_alloc(11876, 0x50) at get_nvlist:911 (341009/1877530)
SPL: large kmem_alloc(11240, 0x50) at load_nvlist:1273 (2639492/2643588)
Closes#50
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>
The mzap_update() function allocates enough memory for a full
dbuf which can be 128K in size. Ideally, this memory should
be allocated from our slab but in the short term it's simplest
just to vmem_alloc() the memory instead.
Closes#48
As part of commit f162433deb the /zvol/
path component was added for zvol devices. This ensured all zvol
devices would be created by udev in /dev/zvol/<pool>/<dataset>, as
opposed to the previous /dev/<pool>/<dataset> path. Logically, it
was nice to organize them in a directory much like Solaris does.
However, while initial testing showed this to work fine with modern
kernels it does not appear to be supported under RHEL5. The extra
path component triggers a NULL deref in create_dir(). Anyway, to
avoid having different zvol path names based on your kernel version
its more consistent simply to revert to the original naming convention.
If you really want the zvol component you can always add custom
udev rules to do exactly this.
We can revisiting this change again once we are willing to drop
support for RHEL5 and similar older distros.
I've noticed the TopGit linux-zfs-branch has some linux-kernel-mem
changes which were incorrectly merged. To fix the issue I'm
reverting the changes in the linux-kernel-mem topic branch, then
remerging the revert, and finally reapplying and merging the
change correctly.
Brian Behlendorf
Zhiyong Landen tian
Ricardo M. Correia
Ned Bass