This was leading to a compilation error because in Linux, sizeof
(kmutex_t) can be larger than 64 in some circumstances (e.g. with
debugging and lockdep enabled).
The code was previously fixed to align the structure to 256 bytes,
but a better fix is to align it to the next multiple of 64 bytes.
The previous hack for this was to move headers 3 levels deep in to
the top level include dir and headers 4 levels deep in to sys.
Obviously this was fairly limiting and missed two important headers.
./zfs/include/sys/fm/fs/zfs.h
./zfs/include/sys/fs/zfs.h
This patch updates the code to be smarter and installs all the headers
to the correct location regardless of depth. Each header will have its
leading 3 path args stripped (i.e. ./zfs/include/) and replaced with
the correct install destination. All path information past the first
three levels will be preserved.
Recent builds against 2.6.31 flagged dmu_recv_stream() as stack heavy.
As a quick simple way to resolve this I'm preventing the inlining of
certain functions which gcc will inline here because this is the only
place they are called. Futher analysis of this function should be
performed to futher reduce its stack usage.
For 2.6.27 kernels are earlier revalidate_disk() was not available.
However, check_disk_change() has been available for far longer and
will properly inform the kernel of the volume change for both older
and newer kernels.
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.
* Added module/zfs/zvol.c which is based off the original Solaris ZVOL
implementation but rewritten to intergrate with the Linux block device
APIs. The basic design remains the similar in Linux with the major
change being request processing. Request processing is handled by
registering a request function which the elevator calls once all request
merges is finished and the elevator unplugs. This function is called
under a spin lock and the request structure is passed to the block driver
to be queued for IO. The elevator must be notified asyncronously once
the request completes or fails with an error. This allows us the block
driver a chance to handle many request concurrently. For the ZVOL we
maintain a taskq with a service thread per core. As requests are delivered
by the elevator each request is dispatched to the taskq. The task queue
handles each request with a write or read helper function which basically
copies the request data in to our out of the DMU object. Writes single
completion as soon as the DMU has the data unless they are marked sync.
Reads are all handled syncronously however the elevator will merge many
small reads in to a large read before it submitting the request.
* Cachine is worth specifically mentioning. Because both the Linux VFS
and the ZFS ARC both want to fully manage the cache we unfortunately
end up with two caches. This means our memory foot print is larger
than otherwise expected, and it means we have an extra copy between
the caches, but it does not impact correctness. All syncs are barrior
requests I believe are handled correctly. Longer term there is lots of
room for improvement here but it will require fairly extensive changes
to either the Linux VFS and VM layer, or additional DMU interfaces to
handle managing buffer not directly allocated by the ARC.
* Added module/zfs/include/sys/blkdev.h which contains all the Linux
compatibility foo which is required to handle changes in the Linux block
APIs from 2.6.18 thru 2.6.31 based kernels.
* The dmu_{read,write}_uio interfaces which don't make sense on Linux
have been modified to dmu_{read,write}_req functions which consume the
standard Linux IO request structure. Their function fundamentally
remains the same so this happily worked out pretty cleanly.
* The /dev/zfs character device is no longer created through the half
implemented Solaris driver DDI interfaces. It is now simply created
with it's own major number as a Linux misc device which greatly simplifies
everything. It is only capable of handling ioctls() but this fits nicely
because that's all it ever has to do. The ZVOL devices unlike in Solaris
do not leverage the same major number as /dev/zfs but instead register
their own major. Because only one major is allocated and space is reserved
for 16 partitions per-device there is a limit of 16384 concurrent ZVOL
devices. By using multiple majors like the scsi driver this limit could
be addressed if it becomes a problem.
* The {spa,zfs,zvol}_busy() functions have all be removed because they
are not required on a Linux system. Under Linux the registered module
exit function will not be called while the are still references to the
module. Once the exit function is called however it must succeed or
block, it may not fail so returning an error on module unload makes to
sense under Linux.
* With the addition of ZVOL support all the HAVE_ZVOL defines were removed
for obvious reasons. However, the HAVE_ZPL defines have been relocated
in to the linux-{kernel,user}-disk topic branches and must remain until
the ZPL is implemented.
This change should wrap up the last of the missing block device
support in the vdev_disk layer. With this change I can now
successfully create and use zpools which are layered on top of
md and lvm virtual devices. The following changes include:
1) The big one, properly handle the case when page cannot be added
to a bio due to dynamic limitation of a merge_bdev handler. For
example the md device will limit a bio to the configured stripe
size. Our bio size may also end up being limited by the maximum
request size, and other factors determined during bio construction.
To handle all of the above cases the code has been updated to
handle failures from bio_add_page(). This had been hardcoded to
never fail for the prototype proof of concept implementation. In
the case of a failure the number of bytes which still need to be
added to a bio are returned. New bio's are allocated and attached
to the dio until the entire data buffer is mapped to bios. It is
then submitted as before to the request queue, and once all the bio's
attached to a dio have finished the completion callback is run.
2) The devid comments have been removed because it is not clear to
me that we will not need devid support. They have been replaced
with a comment explaining that udev can and should be used.
Remove the hard coded 512 byte SECTOR_SIZE and replace it with
bdev_hardsect_size() to get the correct hardware sector size.
Usage of get_capacity() was incorrect. We the block_device
references a partition we need to return bdev->part->nr_sects.
If get_capacity() is used the entire device size will be returned
ignoring partition information. This is however the correct thing
to do when the block device in question has not partition table.
Brian Behlendorf
Ricardo M. Correia