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.
Exposed by the fc11 debug kernel we need to hold a reference over all
calls to submit_bio(). Otherwise it is possible all the completion
callbacks run before we exit __vdev_disk_physio(), and we end up with
a GPF. This was quickly exposed when slab poisoning was enabled. I
have added helper functions to cleanly track the reference counts. In
addition dr->dr_ref was converted from an integer to an atomic type
which removes the need for the spinlock. As a nice side effect of
these changes the code is now slightly cleaner and clearer.
With this patch applied I get the following failure 100% of the time,
I'd prefer to debug it and keep moving forward but I do not have the
time right now so I'm reverting the patch to the version which worked.
Ricardo please fix.
(gdb) bt
0 ztest_dmu_write_parallel (za=0x2aaaac898960) at
../../cmd/ztest/ztest.c:2566
1 0x0000000000405a79 in ztest_thread (arg=<value optimized out>)
at ../../cmd/ztest/ztest.c:3862
2 0x00002b2e6a7a841d in zk_thread_helper (arg=<value optimized out>)
at ../../lib/libzpool/kernel.c:131
3 0x000000379be06367 in start_thread (arg=<value optimized out>)
at pthread_create.c:297
4 0x000000379b2d30ad in clone () from /lib64/libc.so.6
This resolves previous scalabily concerns about the cost of calling
curthread which previously required a list walk. The kthread address
is now tracked as thread specific data which can be quickly returned.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
There is concern that READA may do more than simply reorder the queue.
There may be an increased chance that a requested marked READA will
fail because the elevator considers it optional. For this reason, all
read requests, even speculative ones, have been converted back to READ.
The 2.6.30 kernel build systems sets -Wframe-larger-than=2048 which causes
a warning to be generated when an individual stack frame exceeds 2048.
This caught the spa_history_log() and dmu_objset_snapshot() functions
which declared a data structure on the stack which contained a char
array of MAXPATHLEN. This in defined to be 4096 in the linux kernel
and I imagine it is quite large under Solaris as well. Regardless, the
offending data structures were moved to the heap to correctly keep the
stack depth to a minimum. We might consider setting this value even
lower to catch additional offenders because we are expecting deep stacks.
Tested under CHAOS4.2, RHEL5, SLES11, and FC11 (all x86_64)
Features:
Honor spa_mode() when opening the block device. Previously this
was ignored and devices were always opened read/write.
Integrated DKIOCFLUSHWRITECACHE zio operation with linux WRITE_BARRIER
for kernels post 2.6.24 where empty bio requests are supported. For
earlier kernels ENOTSUP is returned and no barriers are performed. If
RHEL5 based kernels are intended to be supported long term we may need
make use of the old akward API.
With the addition of WRITE_BARRIER support all writes which were
WRITE_SYNC can now be safely made WRITE bios. They will now take
advantage of aggregation in the elevator and improved write performance
is likely.
Notice the ZIO_FLAG_SPECULATIVE flag and pass along the hint to the
elevator by using READA instead of READ. This provides the elevator
the ability to prioritize the real READs ahead of the speculative IO
if needed.
Implement an initial version of vdev_disk_io_done() which in the case
of an EIO error triggers a media change check. If it determines a
media change has occured we fail the device and remove it from the
config. This logic I'm sure can be improved further but for now it
is an improvement over the VERIFY() that no error will ever happen.
APIs:
2.6.22 API change
Unused destroy_dirty_buffers arg removed from prototype.
2.6.24 API change
Empty write barriers are now supported and we should use them.
2.6.24 API change
Size argument dropped from bio_endio and bi_end_io, because the
bi_end_io is only called once now when the request is complete.
There is no longer any need for a size argument. This also means
that partial IO's are no longer possibe and the end_io callback
should not check bi->bi_size. Finally, the return type was updated
to void.
2.6.28 API change
open/close_bdev_excl() renamed to open/close_bdev_exclusive().
2.6.29 API change
BIO_RW_SYNC renamed to BIO_RW_SYNCIO.
Use the legacy BIO_RW_FAILFAST flag if it exists. If it is missing it
means we are running against a kernel with the newer API. We should
be able to enable some fairly smart behavior one we intergrate with the
new API, but until I get around to writing that code just remove the
flag entirely. It's not critical for correctness.
Kernel commit 6712ecf8f648118c3363c142196418f89a510b90 which removes the
size argument from bio_endio and bi_end_io, also removes the need to
handle partial IOs in the handler.
The intent here is to fully remove the previous Solaris thread
implementation so we don't need to simulate both Solaris kernel
and user space thread APIs. The few user space consumers of the
thread API have been updated to use the kthread API. In order
to support this we needed to more fully support the kthread API
and that means not doing crazy things like casting a thread id
to a pointer and using that as was done before. This first
implementation is not effecient but it does provide all the
corrent semantics. If/when performance becomes and issue we
can and should just natively adopt pthreads which is portable.
Let me finish by saying I'm not proud of any of this and I would
love to see it improved. However, this slow implementation does
at least provide all the correct kthread API semantics whereas
the previous method of casting the thread ID to a pointer was
dodgy at best.
gcc-unused and gcc-uninit topic branches at the same time and
then ran 'tg update'. I'll need to keep that sort of thing
in mind when updating multiple topic branches between updates.
within an ASSERT with the ASSERTV macro which will ensure it will
be removed when the ASSERTs are commented out. This makes gcc much
happier, makes the variables usage explicit, and removes the need
for the compiler to detect it is unused and do the right thing.
Brian Behlendorf
Ricardo M. Correia