Specifically, the following bugs are fixed in this patch:
1) zdb wasn't getting the correct device size when the vdev is a
block device. In Solaris, fstat64() returns the device size but
in Linux an ioctl() is needed.
2) We were opening block devices with O_DIRECT, which caused pread64()
to fail with EINVAL due to memory alignment issues. This was fixed by
the previous umem cache alignment fix in stub implementation to align
objects correctly. But we still needed to add a check for the error here.
3) We also make sure that we don't try to open a block device in write
mode in userspace. This shouldn't happen, because zdb opens devices
in read-only mode, and ztest only uses files.
Under linux we open block devices with O_DIRECT which means we must
provide aligned memory buffers. This patch adds the needed umem
interfaces or in the case of caches simply honors alignment provided
at cache creation time.
In vn_open(), if fstat64() returned an error, the real errno
was being obscured by calling close().
Add error handling for both pwrite64() calls in vn_rdwr().
This typedef is being done in both lib/libefi/include/sys/uuid.h and
/usr/include/uuid/uuid.h, both of which are included in lib/libefi/rdwr_efi.c.
This leads to the following error:
In file included from ../../lib/libefi/include/sys/efi_partition.h:29,
from ../../lib/libefi/rdwr_efi.c:41:
../../lib/libefi/include/sys/uuid.h:81: error: redefinition of typedef 'uuid_t'
/usr/include/uuid/uuid.h:19: note: previous declaration of 'uuid_t' was here
The reason that we didn't see this before, is because of a strange feature in
gcc where some types of warnings/errors are silently ignored if they come from
system headers. But depending on the order of how system headers end up
included, libefi's uuid.h may actually be included after uuid/uuid.h, which
leads to the error above.
It is safe to remove this duplicate typedef because we are already
dependent on the linux uuid.h header and it's exceptionally unlikely
they will ever change the size.
At last a useful user space interface for the Linux ZFS port arrives.
With the addition of the ZVOL real ZFS based block devices are available
and can be compared head to head with Linux's MD and LVM block drivers.
The Linux ZVOL has not yet had any performance work done but from a user
perspective it should be functionally complete and behave like any other
Linux block device.
The ZVOL has so far been tested using zconfig.sh on the following x86_64
based platforms: FC11, CHAOS4, RHEL5, RHEL6, and SLES11. However, more
testing is required to ensure everything is working as designed.
What follows in a somewhat detailed list of changes includes in this
commit to make ZVOL's possible. A few other issues were addressed in
the context of these changes which will also be mentioned.
* zvol_create_link_common() simplified to simply issue to ioctl to
create the device and then wait up to 10 seconds for it to appear.
The device will be created within a few miliseconds by udev under
/dev/<pool>/<volume>. Note this naming convention is slightly
different than on Solaris by I feel is more Linuxy.
* Removed support for dump vdevs. This concept is specific to Solaris
and done not map cleanly to Linux. Under Linux generating system cores
is perferably done over the network via netdump, or alternately to a
block device via O_DIRECT.
Brian Behlendorf
Ricardo M. Correia