2010-08-26 18:45:02 +00:00
|
|
|
/*
|
|
|
|
* CDDL HEADER START
|
|
|
|
*
|
|
|
|
* The contents of this file are subject to the terms of the
|
|
|
|
* Common Development and Distribution License (the "License").
|
|
|
|
* You may not use this file except in compliance with the License.
|
|
|
|
*
|
|
|
|
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
|
|
|
|
* or http://www.opensolaris.org/os/licensing.
|
|
|
|
* See the License for the specific language governing permissions
|
|
|
|
* and limitations under the License.
|
|
|
|
*
|
|
|
|
* When distributing Covered Code, include this CDDL HEADER in each
|
|
|
|
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
|
|
|
|
* If applicable, add the following below this CDDL HEADER, with the
|
|
|
|
* fields enclosed by brackets "[]" replaced with your own identifying
|
|
|
|
* information: Portions Copyright [yyyy] [name of copyright owner]
|
|
|
|
*
|
|
|
|
* CDDL HEADER END
|
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2008-2010 Lawrence Livermore National Security, LLC.
|
|
|
|
* Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER).
|
|
|
|
* Rewritten for Linux by Brian Behlendorf <behlendorf1@llnl.gov>.
|
|
|
|
* LLNL-CODE-403049.
|
|
|
|
*
|
|
|
|
* ZFS volume emulation driver.
|
|
|
|
*
|
|
|
|
* Makes a DMU object look like a volume of arbitrary size, up to 2^64 bytes.
|
|
|
|
* Volumes are accessed through the symbolic links named:
|
|
|
|
*
|
|
|
|
* /dev/<pool_name>/<dataset_name>
|
|
|
|
*
|
|
|
|
* Volumes are persistent through reboot and module load. No user command
|
|
|
|
* needs to be run before opening and using a device.
|
|
|
|
*/
|
|
|
|
|
2013-05-10 19:47:54 +00:00
|
|
|
#include <sys/dbuf.h>
|
2010-08-26 18:45:02 +00:00
|
|
|
#include <sys/dmu_traverse.h>
|
|
|
|
#include <sys/dsl_dataset.h>
|
|
|
|
#include <sys/dsl_prop.h>
|
|
|
|
#include <sys/zap.h>
|
2015-08-24 21:18:48 +00:00
|
|
|
#include <sys/zfeature.h>
|
2010-08-26 18:45:02 +00:00
|
|
|
#include <sys/zil_impl.h>
|
|
|
|
#include <sys/zio.h>
|
|
|
|
#include <sys/zfs_rlock.h>
|
|
|
|
#include <sys/zfs_znode.h>
|
|
|
|
#include <sys/zvol.h>
|
2011-02-22 20:15:13 +00:00
|
|
|
#include <linux/blkdev_compat.h>
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2012-06-02 01:49:10 +00:00
|
|
|
unsigned int zvol_inhibit_dev = 0;
|
2010-08-26 18:45:02 +00:00
|
|
|
unsigned int zvol_major = ZVOL_MAJOR;
|
2015-08-18 20:51:20 +00:00
|
|
|
unsigned int zvol_prefetch_bytes = (128 * 1024);
|
Limit the number of blocks to discard at once.
The number of blocks that can be discarded in one BLKDISCARD ioctl on a
zvol is currently unlimited. Some applications, such as mkfs, discard
the whole volume at once and they use the maximum possible discard size
to do that. As a result, several gigabytes discard requests are not
uncommon.
Unfortunately, if a large amount of data is allocated in the zvol, ZFS
can be quite slow to process discard requests. This is especially true
if the volblocksize is low (e.g. the 8K default). As a result, very
large discard requests can take a very long time (seconds to minutes
under heavy load) to complete. This can cause a number of problems, most
notably if the zvol is accessed remotely (e.g. via iSCSI), in which case
the client has a high probability of timing out on the request.
This patch solves the issue by adding a new tunable module parameter:
zvol_max_discard_blocks. This indicates the maximum possible range, in
zvol blocks, of one discard operation. It is set by default to 16384
blocks, which appears to be a good tradeoff. Using the default
volblocksize of 8K this is equivalent to 128 MB. When using the maximum
volblocksize of 128K this is equivalent to 2 GB.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #858
2012-07-31 08:45:37 +00:00
|
|
|
unsigned long zvol_max_discard_blocks = 16384;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
static kmutex_t zvol_state_lock;
|
|
|
|
static list_t zvol_state_list;
|
|
|
|
static char *zvol_tag = "zvol_tag";
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The in-core state of each volume.
|
|
|
|
*/
|
|
|
|
typedef struct zvol_state {
|
2011-02-22 10:58:44 +00:00
|
|
|
char zv_name[MAXNAMELEN]; /* name */
|
2013-12-12 21:04:40 +00:00
|
|
|
uint64_t zv_volsize; /* advertised space */
|
|
|
|
uint64_t zv_volblocksize; /* volume block size */
|
2010-08-26 18:45:02 +00:00
|
|
|
objset_t *zv_objset; /* objset handle */
|
|
|
|
uint32_t zv_flags; /* ZVOL_* flags */
|
|
|
|
uint32_t zv_open_count; /* open counts */
|
|
|
|
uint32_t zv_changed; /* disk changed */
|
|
|
|
zilog_t *zv_zilog; /* ZIL handle */
|
|
|
|
znode_t zv_znode; /* for range locking */
|
|
|
|
dmu_buf_t *zv_dbuf; /* bonus handle */
|
|
|
|
dev_t zv_dev; /* device id */
|
|
|
|
struct gendisk *zv_disk; /* generic disk */
|
|
|
|
struct request_queue *zv_queue; /* request queue */
|
|
|
|
spinlock_t zv_lock; /* request queue lock */
|
|
|
|
list_node_t zv_next; /* next zvol_state_t linkage */
|
|
|
|
} zvol_state_t;
|
|
|
|
|
|
|
|
#define ZVOL_RDONLY 0x1
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the next available range of ZVOL_MINORS minor numbers. The
|
|
|
|
* zvol_state_list is kept in ascending minor order so we simply need
|
|
|
|
* to scan the list for the first gap in the sequence. This allows us
|
|
|
|
* to recycle minor number as devices are created and removed.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
zvol_find_minor(unsigned *minor)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
|
|
|
|
*minor = 0;
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
for (zv = list_head(&zvol_state_list); zv != NULL;
|
2013-12-12 21:04:40 +00:00
|
|
|
zv = list_next(&zvol_state_list, zv), *minor += ZVOL_MINORS) {
|
2010-08-26 18:45:02 +00:00
|
|
|
if (MINOR(zv->zv_dev) != MINOR(*minor))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* All minors are in use */
|
|
|
|
if (*minor >= (1 << MINORBITS))
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(ENXIO));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (0);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find a zvol_state_t given the full major+minor dev_t.
|
|
|
|
*/
|
|
|
|
static zvol_state_t *
|
|
|
|
zvol_find_by_dev(dev_t dev)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
for (zv = list_head(&zvol_state_list); zv != NULL;
|
2013-12-12 21:04:40 +00:00
|
|
|
zv = list_next(&zvol_state_list, zv)) {
|
2010-08-26 18:45:02 +00:00
|
|
|
if (zv->zv_dev == dev)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (zv);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (NULL);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find a zvol_state_t given the name provided at zvol_alloc() time.
|
|
|
|
*/
|
|
|
|
static zvol_state_t *
|
|
|
|
zvol_find_by_name(const char *name)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
for (zv = list_head(&zvol_state_list); zv != NULL;
|
2013-12-12 21:04:40 +00:00
|
|
|
zv = list_next(&zvol_state_list, zv)) {
|
|
|
|
if (strncmp(zv->zv_name, name, MAXNAMELEN) == 0)
|
|
|
|
return (zv);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (NULL);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2012-12-17 01:33:57 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Given a path, return TRUE if path is a ZVOL.
|
|
|
|
*/
|
|
|
|
boolean_t
|
|
|
|
zvol_is_zvol(const char *device)
|
|
|
|
{
|
|
|
|
struct block_device *bdev;
|
|
|
|
unsigned int major;
|
|
|
|
|
|
|
|
bdev = lookup_bdev(device);
|
|
|
|
if (IS_ERR(bdev))
|
|
|
|
return (B_FALSE);
|
|
|
|
|
|
|
|
major = MAJOR(bdev->bd_dev);
|
|
|
|
bdput(bdev);
|
|
|
|
|
|
|
|
if (major == zvol_major)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (B_TRUE);
|
2012-12-17 01:33:57 +00:00
|
|
|
|
|
|
|
return (B_FALSE);
|
|
|
|
}
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
/*
|
|
|
|
* ZFS_IOC_CREATE callback handles dmu zvol and zap object creation.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
zvol_create_cb(objset_t *os, void *arg, cred_t *cr, dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
zfs_creat_t *zct = arg;
|
|
|
|
nvlist_t *nvprops = zct->zct_props;
|
|
|
|
int error;
|
|
|
|
uint64_t volblocksize, volsize;
|
|
|
|
|
|
|
|
VERIFY(nvlist_lookup_uint64(nvprops,
|
|
|
|
zfs_prop_to_name(ZFS_PROP_VOLSIZE), &volsize) == 0);
|
|
|
|
if (nvlist_lookup_uint64(nvprops,
|
|
|
|
zfs_prop_to_name(ZFS_PROP_VOLBLOCKSIZE), &volblocksize) != 0)
|
|
|
|
volblocksize = zfs_prop_default_numeric(ZFS_PROP_VOLBLOCKSIZE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These properties must be removed from the list so the generic
|
|
|
|
* property setting step won't apply to them.
|
|
|
|
*/
|
|
|
|
VERIFY(nvlist_remove_all(nvprops,
|
|
|
|
zfs_prop_to_name(ZFS_PROP_VOLSIZE)) == 0);
|
|
|
|
(void) nvlist_remove_all(nvprops,
|
|
|
|
zfs_prop_to_name(ZFS_PROP_VOLBLOCKSIZE));
|
|
|
|
|
|
|
|
error = dmu_object_claim(os, ZVOL_OBJ, DMU_OT_ZVOL, volblocksize,
|
|
|
|
DMU_OT_NONE, 0, tx);
|
|
|
|
ASSERT(error == 0);
|
|
|
|
|
|
|
|
error = zap_create_claim(os, ZVOL_ZAP_OBJ, DMU_OT_ZVOL_PROP,
|
|
|
|
DMU_OT_NONE, 0, tx);
|
|
|
|
ASSERT(error == 0);
|
|
|
|
|
|
|
|
error = zap_update(os, ZVOL_ZAP_OBJ, "size", 8, 1, &volsize, tx);
|
|
|
|
ASSERT(error == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ZFS_IOC_OBJSET_STATS entry point.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
zvol_get_stats(objset_t *os, nvlist_t *nv)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
dmu_object_info_t *doi;
|
|
|
|
uint64_t val;
|
|
|
|
|
|
|
|
error = zap_lookup(os, ZVOL_ZAP_OBJ, "size", 8, 1, &val);
|
|
|
|
if (error)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
dsl_prop_nvlist_add_uint64(nv, ZFS_PROP_VOLSIZE, val);
|
2013-12-12 21:04:40 +00:00
|
|
|
doi = kmem_alloc(sizeof (dmu_object_info_t), KM_SLEEP);
|
2010-08-26 18:45:02 +00:00
|
|
|
error = dmu_object_info(os, ZVOL_OBJ, doi);
|
|
|
|
|
|
|
|
if (error == 0) {
|
|
|
|
dsl_prop_nvlist_add_uint64(nv, ZFS_PROP_VOLBLOCKSIZE,
|
|
|
|
doi->doi_data_block_size);
|
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
kmem_free(doi, sizeof (dmu_object_info_t));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
static void
|
|
|
|
zvol_size_changed(zvol_state_t *zv, uint64_t volsize)
|
|
|
|
{
|
|
|
|
struct block_device *bdev;
|
|
|
|
|
|
|
|
bdev = bdget_disk(zv->zv_disk, 0);
|
|
|
|
if (bdev == NULL)
|
|
|
|
return;
|
|
|
|
/*
|
|
|
|
* 2.6.28 API change
|
|
|
|
* Added check_disk_size_change() helper function.
|
|
|
|
*/
|
|
|
|
#ifdef HAVE_CHECK_DISK_SIZE_CHANGE
|
|
|
|
set_capacity(zv->zv_disk, volsize >> 9);
|
|
|
|
zv->zv_volsize = volsize;
|
|
|
|
check_disk_size_change(zv->zv_disk, bdev);
|
|
|
|
#else
|
|
|
|
zv->zv_volsize = volsize;
|
|
|
|
zv->zv_changed = 1;
|
|
|
|
(void) check_disk_change(bdev);
|
|
|
|
#endif /* HAVE_CHECK_DISK_SIZE_CHANGE */
|
|
|
|
|
|
|
|
bdput(bdev);
|
|
|
|
}
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
/*
|
|
|
|
* Sanity check volume size.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
zvol_check_volsize(uint64_t volsize, uint64_t blocksize)
|
|
|
|
{
|
|
|
|
if (volsize == 0)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(EINVAL));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
if (volsize % blocksize != 0)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(EINVAL));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
#ifdef _ILP32
|
|
|
|
if (volsize - 1 > MAXOFFSET_T)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(EOVERFLOW));
|
2010-08-26 18:45:02 +00:00
|
|
|
#endif
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure the zap is flushed then inform the VFS of the capacity change.
|
|
|
|
*/
|
|
|
|
static int
|
2014-01-13 22:27:33 +00:00
|
|
|
zvol_update_volsize(uint64_t volsize, objset_t *os)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
dmu_tx_t *tx;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
|
2011-02-25 07:36:01 +00:00
|
|
|
tx = dmu_tx_create(os);
|
2010-08-26 18:45:02 +00:00
|
|
|
dmu_tx_hold_zap(tx, ZVOL_ZAP_OBJ, TRUE, NULL);
|
|
|
|
error = dmu_tx_assign(tx, TXG_WAIT);
|
|
|
|
if (error) {
|
|
|
|
dmu_tx_abort(tx);
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2011-02-25 07:36:01 +00:00
|
|
|
error = zap_update(os, ZVOL_ZAP_OBJ, "size", 8, 1,
|
2010-08-26 18:45:02 +00:00
|
|
|
&volsize, tx);
|
|
|
|
dmu_tx_commit(tx);
|
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
if (error == 0)
|
|
|
|
error = dmu_free_long_range(os,
|
|
|
|
ZVOL_OBJ, volsize, DMU_OBJECT_END);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
return (error);
|
|
|
|
}
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
static int
|
|
|
|
zvol_update_live_volsize(zvol_state_t *zv, uint64_t volsize)
|
|
|
|
{
|
|
|
|
zvol_size_changed(zv, volsize);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
/*
|
|
|
|
* We should post a event here describing the expansion. However,
|
|
|
|
* the zfs_ereport_post() interface doesn't nicely support posting
|
|
|
|
* events for zvols, it assumes events relate to vdevs or zios.
|
|
|
|
*/
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set ZFS_PROP_VOLSIZE set entry point.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
zvol_set_volsize(const char *name, uint64_t volsize)
|
|
|
|
{
|
2014-01-13 22:27:33 +00:00
|
|
|
zvol_state_t *zv = NULL;
|
2010-08-26 18:45:02 +00:00
|
|
|
objset_t *os = NULL;
|
|
|
|
int error;
|
2014-01-13 22:27:33 +00:00
|
|
|
dmu_object_info_t *doi;
|
|
|
|
uint64_t readonly;
|
|
|
|
boolean_t owned = B_FALSE;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2013-09-04 12:00:57 +00:00
|
|
|
error = dsl_prop_get_integer(name,
|
|
|
|
zfs_prop_to_name(ZFS_PROP_READONLY), &readonly, NULL);
|
|
|
|
if (error != 0)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2013-09-04 12:00:57 +00:00
|
|
|
if (readonly)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(EROFS));
|
2013-09-04 12:00:57 +00:00
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
zv = zvol_find_by_name(name);
|
2014-01-13 22:27:33 +00:00
|
|
|
|
|
|
|
if (zv == NULL || zv->zv_objset == NULL) {
|
|
|
|
if ((error = dmu_objset_own(name, DMU_OST_ZVOL, B_FALSE,
|
|
|
|
FTAG, &os)) != 0) {
|
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
return (SET_ERROR(error));
|
|
|
|
}
|
|
|
|
owned = B_TRUE;
|
|
|
|
if (zv != NULL)
|
|
|
|
zv->zv_objset = os;
|
|
|
|
} else {
|
|
|
|
os = zv->zv_objset;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
doi = kmem_alloc(sizeof (dmu_object_info_t), KM_SLEEP);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
if ((error = dmu_object_info(os, ZVOL_OBJ, doi)) ||
|
|
|
|
(error = zvol_check_volsize(volsize, doi->doi_data_block_size)))
|
2014-01-13 22:27:33 +00:00
|
|
|
goto out;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
error = zvol_update_volsize(volsize, os);
|
2013-12-12 21:04:40 +00:00
|
|
|
kmem_free(doi, sizeof (dmu_object_info_t));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2014-01-13 22:27:33 +00:00
|
|
|
if (error == 0 && zv != NULL)
|
|
|
|
error = zvol_update_live_volsize(zv, volsize);
|
|
|
|
out:
|
|
|
|
if (owned) {
|
|
|
|
dmu_objset_disown(os, FTAG);
|
|
|
|
if (zv != NULL)
|
|
|
|
zv->zv_objset = NULL;
|
|
|
|
}
|
2010-08-26 18:45:02 +00:00
|
|
|
mutex_exit(&zvol_state_lock);
|
2014-01-13 22:27:33 +00:00
|
|
|
return (error);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sanity check volume block size.
|
|
|
|
*/
|
|
|
|
int
|
2015-08-24 21:18:48 +00:00
|
|
|
zvol_check_volblocksize(const char *name, uint64_t volblocksize)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
2015-08-24 21:18:48 +00:00
|
|
|
/* Record sizes above 128k need the feature to be enabled */
|
|
|
|
if (volblocksize > SPA_OLD_MAXBLOCKSIZE) {
|
|
|
|
spa_t *spa;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if ((error = spa_open(name, &spa, FTAG)) != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
if (!spa_feature_is_enabled(spa, SPA_FEATURE_LARGE_BLOCKS)) {
|
|
|
|
spa_close(spa, FTAG);
|
|
|
|
return (SET_ERROR(ENOTSUP));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't allow setting the property above 1MB,
|
|
|
|
* unless the tunable has been changed.
|
|
|
|
*/
|
|
|
|
if (volblocksize > zfs_max_recordsize)
|
|
|
|
return (SET_ERROR(EDOM));
|
|
|
|
|
|
|
|
spa_close(spa, FTAG);
|
|
|
|
}
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
if (volblocksize < SPA_MINBLOCKSIZE ||
|
|
|
|
volblocksize > SPA_MAXBLOCKSIZE ||
|
|
|
|
!ISP2(volblocksize))
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(EDOM));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set ZFS_PROP_VOLBLOCKSIZE set entry point.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
zvol_set_volblocksize(const char *name, uint64_t volblocksize)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
dmu_tx_t *tx;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
|
|
|
|
zv = zvol_find_by_name(name);
|
|
|
|
if (zv == NULL) {
|
2013-03-08 18:41:28 +00:00
|
|
|
error = SET_ERROR(ENXIO);
|
2010-08-26 18:45:02 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
if (zv->zv_flags & ZVOL_RDONLY) {
|
2013-03-08 18:41:28 +00:00
|
|
|
error = SET_ERROR(EROFS);
|
2010-08-26 18:45:02 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
tx = dmu_tx_create(zv->zv_objset);
|
|
|
|
dmu_tx_hold_bonus(tx, ZVOL_OBJ);
|
|
|
|
error = dmu_tx_assign(tx, TXG_WAIT);
|
|
|
|
if (error) {
|
|
|
|
dmu_tx_abort(tx);
|
|
|
|
} else {
|
|
|
|
error = dmu_object_set_blocksize(zv->zv_objset, ZVOL_OBJ,
|
|
|
|
volblocksize, 0, tx);
|
|
|
|
if (error == ENOTSUP)
|
2013-03-08 18:41:28 +00:00
|
|
|
error = SET_ERROR(EBUSY);
|
2010-08-26 18:45:02 +00:00
|
|
|
dmu_tx_commit(tx);
|
|
|
|
if (error == 0)
|
|
|
|
zv->zv_volblocksize = volblocksize;
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Replay a TX_WRITE ZIL transaction that didn't get committed
|
|
|
|
* after a system failure
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
zvol_replay_write(zvol_state_t *zv, lr_write_t *lr, boolean_t byteswap)
|
|
|
|
{
|
|
|
|
objset_t *os = zv->zv_objset;
|
|
|
|
char *data = (char *)(lr + 1); /* data follows lr_write_t */
|
|
|
|
uint64_t off = lr->lr_offset;
|
|
|
|
uint64_t len = lr->lr_length;
|
|
|
|
dmu_tx_t *tx;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (byteswap)
|
|
|
|
byteswap_uint64_array(lr, sizeof (*lr));
|
|
|
|
|
|
|
|
tx = dmu_tx_create(os);
|
|
|
|
dmu_tx_hold_write(tx, ZVOL_OBJ, off, len);
|
|
|
|
error = dmu_tx_assign(tx, TXG_WAIT);
|
|
|
|
if (error) {
|
|
|
|
dmu_tx_abort(tx);
|
|
|
|
} else {
|
|
|
|
dmu_write(os, ZVOL_OBJ, off, len, data, tx);
|
|
|
|
dmu_tx_commit(tx);
|
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_replay_err(zvol_state_t *zv, lr_t *lr, boolean_t byteswap)
|
|
|
|
{
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(ENOTSUP));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Callback vectors for replaying records.
|
|
|
|
* Only TX_WRITE is needed for zvol.
|
|
|
|
*/
|
2013-02-15 04:37:43 +00:00
|
|
|
zil_replay_func_t zvol_replay_vector[TX_MAX_TYPE] = {
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* no such transaction type */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_CREATE */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_MKDIR */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_MKXATTR */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_SYMLINK */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_REMOVE */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_RMDIR */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_LINK */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_RENAME */
|
|
|
|
(zil_replay_func_t)zvol_replay_write, /* TX_WRITE */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_TRUNCATE */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_SETATTR */
|
|
|
|
(zil_replay_func_t)zvol_replay_err, /* TX_ACL */
|
2010-08-26 18:45:02 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* zvol_log_write() handles synchronous writes using TX_WRITE ZIL transactions.
|
|
|
|
*
|
|
|
|
* We store data in the log buffers if it's small enough.
|
|
|
|
* Otherwise we will later flush the data out via dmu_sync().
|
|
|
|
*/
|
|
|
|
ssize_t zvol_immediate_write_sz = 32768;
|
|
|
|
|
|
|
|
static void
|
2013-12-12 21:04:40 +00:00
|
|
|
zvol_log_write(zvol_state_t *zv, dmu_tx_t *tx, uint64_t offset,
|
|
|
|
uint64_t size, int sync)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
uint32_t blocksize = zv->zv_volblocksize;
|
|
|
|
zilog_t *zilog = zv->zv_zilog;
|
|
|
|
boolean_t slogging;
|
2012-06-06 09:30:24 +00:00
|
|
|
ssize_t immediate_write_sz;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
if (zil_replaying(zilog, tx))
|
|
|
|
return;
|
|
|
|
|
2012-06-06 09:30:24 +00:00
|
|
|
immediate_write_sz = (zilog->zl_logbias == ZFS_LOGBIAS_THROUGHPUT)
|
|
|
|
? 0 : zvol_immediate_write_sz;
|
|
|
|
slogging = spa_has_slogs(zilog->zl_spa) &&
|
|
|
|
(zilog->zl_logbias == ZFS_LOGBIAS_LATENCY);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
while (size) {
|
|
|
|
itx_t *itx;
|
|
|
|
lr_write_t *lr;
|
|
|
|
ssize_t len;
|
|
|
|
itx_wr_state_t write_state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unlike zfs_log_write() we can be called with
|
|
|
|
* up to DMU_MAX_ACCESS/2 (5MB) writes.
|
|
|
|
*/
|
2012-06-06 09:30:24 +00:00
|
|
|
if (blocksize > immediate_write_sz && !slogging &&
|
2010-08-26 18:45:02 +00:00
|
|
|
size >= blocksize && offset % blocksize == 0) {
|
|
|
|
write_state = WR_INDIRECT; /* uses dmu_sync */
|
|
|
|
len = blocksize;
|
|
|
|
} else if (sync) {
|
|
|
|
write_state = WR_COPIED;
|
|
|
|
len = MIN(ZIL_MAX_LOG_DATA, size);
|
|
|
|
} else {
|
|
|
|
write_state = WR_NEED_COPY;
|
|
|
|
len = MIN(ZIL_MAX_LOG_DATA, size);
|
|
|
|
}
|
|
|
|
|
|
|
|
itx = zil_itx_create(TX_WRITE, sizeof (*lr) +
|
|
|
|
(write_state == WR_COPIED ? len : 0));
|
|
|
|
lr = (lr_write_t *)&itx->itx_lr;
|
|
|
|
if (write_state == WR_COPIED && dmu_read(zv->zv_objset,
|
|
|
|
ZVOL_OBJ, offset, len, lr+1, DMU_READ_NO_PREFETCH) != 0) {
|
|
|
|
zil_itx_destroy(itx);
|
|
|
|
itx = zil_itx_create(TX_WRITE, sizeof (*lr));
|
|
|
|
lr = (lr_write_t *)&itx->itx_lr;
|
|
|
|
write_state = WR_NEED_COPY;
|
|
|
|
}
|
|
|
|
|
|
|
|
itx->itx_wr_state = write_state;
|
|
|
|
if (write_state == WR_NEED_COPY)
|
|
|
|
itx->itx_sod += len;
|
|
|
|
lr->lr_foid = ZVOL_OBJ;
|
|
|
|
lr->lr_offset = offset;
|
|
|
|
lr->lr_length = len;
|
|
|
|
lr->lr_blkoff = 0;
|
|
|
|
BP_ZERO(&lr->lr_blkptr);
|
|
|
|
|
|
|
|
itx->itx_private = zv;
|
|
|
|
itx->itx_sync = sync;
|
|
|
|
|
|
|
|
(void) zil_itx_assign(zilog, itx, tx);
|
|
|
|
|
|
|
|
offset += len;
|
|
|
|
size -= len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
static int
|
|
|
|
zvol_write(struct bio *bio)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
zvol_state_t *zv = bio->bi_bdev->bd_disk->private_data;
|
|
|
|
uint64_t offset = BIO_BI_SECTOR(bio) << 9;
|
|
|
|
uint64_t size = BIO_BI_SIZE(bio);
|
2010-08-26 18:45:02 +00:00
|
|
|
int error = 0;
|
|
|
|
dmu_tx_t *tx;
|
|
|
|
rl_t *rl;
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (bio->bi_rw & VDEV_REQ_FLUSH)
|
2011-09-05 09:11:38 +00:00
|
|
|
zil_commit(zv->zv_zilog, ZVOL_OBJ);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some requests are just for flush and nothing else.
|
|
|
|
*/
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (size == 0)
|
2012-08-18 18:17:23 +00:00
|
|
|
goto out;
|
2011-09-05 09:11:38 +00:00
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
rl = zfs_range_lock(&zv->zv_znode, offset, size, RL_WRITER);
|
|
|
|
|
|
|
|
tx = dmu_tx_create(zv->zv_objset);
|
|
|
|
dmu_tx_hold_write(tx, ZVOL_OBJ, offset, size);
|
|
|
|
|
|
|
|
/* This will only fail for ENOSPC */
|
|
|
|
error = dmu_tx_assign(tx, TXG_WAIT);
|
|
|
|
if (error) {
|
|
|
|
dmu_tx_abort(tx);
|
|
|
|
zfs_range_unlock(rl);
|
2012-08-18 18:17:23 +00:00
|
|
|
goto out;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
error = dmu_write_bio(zv->zv_objset, ZVOL_OBJ, bio, tx);
|
2010-08-26 18:45:02 +00:00
|
|
|
if (error == 0)
|
2011-09-05 09:11:38 +00:00
|
|
|
zvol_log_write(zv, tx, offset, size,
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
!!(bio->bi_rw & VDEV_REQ_FUA));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
dmu_tx_commit(tx);
|
|
|
|
zfs_range_unlock(rl);
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if ((bio->bi_rw & VDEV_REQ_FUA) ||
|
2011-09-05 09:11:38 +00:00
|
|
|
zv->zv_objset->os_sync == ZFS_SYNC_ALWAYS)
|
2010-08-26 18:45:02 +00:00
|
|
|
zil_commit(zv->zv_zilog, ZVOL_OBJ);
|
|
|
|
|
2012-08-18 18:17:23 +00:00
|
|
|
out:
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
return (error);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
static int
|
|
|
|
zvol_discard(struct bio *bio)
|
2011-09-02 13:23:12 +00:00
|
|
|
{
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
zvol_state_t *zv = bio->bi_bdev->bd_disk->private_data;
|
|
|
|
uint64_t start = BIO_BI_SECTOR(bio) << 9;
|
|
|
|
uint64_t size = BIO_BI_SIZE(bio);
|
|
|
|
uint64_t end = start + size;
|
2011-09-02 13:23:12 +00:00
|
|
|
int error;
|
|
|
|
rl_t *rl;
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (end > zv->zv_volsize)
|
|
|
|
return (SET_ERROR(EIO));
|
2011-09-02 13:23:12 +00:00
|
|
|
|
2012-10-04 08:38:55 +00:00
|
|
|
/*
|
2014-10-10 15:23:23 +00:00
|
|
|
* Align the request to volume block boundaries when REQ_SECURE is
|
|
|
|
* available, but not requested. If we don't, then this will force
|
|
|
|
* dnode_free_range() to zero out the unaligned parts, which is slow
|
|
|
|
* (read-modify-write) and useless since we are not freeing any space
|
|
|
|
* by doing so. Kernels that do not support REQ_SECURE (2.6.32 through
|
|
|
|
* 2.6.35) will not receive this optimization.
|
2012-10-04 08:38:55 +00:00
|
|
|
*/
|
2014-10-10 15:23:23 +00:00
|
|
|
#ifdef REQ_SECURE
|
|
|
|
if (!(bio->bi_rw & REQ_SECURE)) {
|
|
|
|
start = P2ROUNDUP(start, zv->zv_volblocksize);
|
|
|
|
end = P2ALIGN(end, zv->zv_volblocksize);
|
2015-09-18 12:32:52 +00:00
|
|
|
size = end - start;
|
2014-10-10 15:23:23 +00:00
|
|
|
}
|
|
|
|
#endif
|
2012-10-04 08:38:55 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (start >= end)
|
|
|
|
return (0);
|
2011-09-02 13:23:12 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
rl = zfs_range_lock(&zv->zv_znode, start, size, RL_WRITER);
|
2011-09-02 13:23:12 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
error = dmu_free_long_range(zv->zv_objset, ZVOL_OBJ, start, size);
|
2011-09-02 13:23:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* TODO: maybe we should add the operation to the log.
|
|
|
|
*/
|
|
|
|
|
|
|
|
zfs_range_unlock(rl);
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
|
|
|
|
return (error);
|
2011-09-02 13:23:12 +00:00
|
|
|
}
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
static int
|
|
|
|
zvol_read(struct bio *bio)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
zvol_state_t *zv = bio->bi_bdev->bd_disk->private_data;
|
|
|
|
uint64_t offset = BIO_BI_SECTOR(bio) << 9;
|
|
|
|
uint64_t len = BIO_BI_SIZE(bio);
|
2010-08-26 18:45:02 +00:00
|
|
|
int error;
|
|
|
|
rl_t *rl;
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (len == 0)
|
|
|
|
return (0);
|
|
|
|
|
2011-09-05 09:11:38 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
rl = zfs_range_lock(&zv->zv_znode, offset, len, RL_READER);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
error = dmu_read_bio(zv->zv_objset, ZVOL_OBJ, bio);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
zfs_range_unlock(rl);
|
|
|
|
|
|
|
|
/* convert checksum errors into IO errors */
|
|
|
|
if (error == ECKSUM)
|
2013-03-08 18:41:28 +00:00
|
|
|
error = SET_ERROR(EIO);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
return (error);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
static MAKE_REQUEST_FN_RET
|
|
|
|
zvol_request(struct request_queue *q, struct bio *bio)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
zvol_state_t *zv = q->queuedata;
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
fstrans_cookie_t cookie = spl_fstrans_mark();
|
|
|
|
uint64_t offset = BIO_BI_SECTOR(bio);
|
|
|
|
unsigned int sectors = bio_sectors(bio);
|
2015-09-07 16:03:19 +00:00
|
|
|
int rw = bio_data_dir(bio);
|
|
|
|
#ifdef HAVE_GENERIC_IO_ACCT
|
|
|
|
unsigned long start = jiffies;
|
|
|
|
#endif
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
int error = 0;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (bio_has_data(bio) && offset + sectors >
|
|
|
|
get_capacity(zv->zv_disk)) {
|
|
|
|
printk(KERN_INFO
|
|
|
|
"%s: bad access: block=%llu, count=%lu\n",
|
|
|
|
zv->zv_disk->disk_name,
|
|
|
|
(long long unsigned)offset,
|
|
|
|
(long unsigned)sectors);
|
|
|
|
error = SET_ERROR(EIO);
|
2015-09-07 16:03:19 +00:00
|
|
|
goto out1;
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
}
|
|
|
|
|
2015-09-07 16:03:19 +00:00
|
|
|
generic_start_io_acct(rw, sectors, &zv->zv_disk->part0);
|
|
|
|
|
|
|
|
if (rw == WRITE) {
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (unlikely(zv->zv_flags & ZVOL_RDONLY)) {
|
|
|
|
error = SET_ERROR(EROFS);
|
2015-09-07 16:03:19 +00:00
|
|
|
goto out2;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
if (bio->bi_rw & VDEV_REQ_DISCARD) {
|
|
|
|
error = zvol_discard(bio);
|
2015-09-07 16:03:19 +00:00
|
|
|
goto out2;
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
}
|
2010-08-26 18:45:02 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
error = zvol_write(bio);
|
|
|
|
} else
|
|
|
|
error = zvol_read(bio);
|
2011-09-02 13:23:12 +00:00
|
|
|
|
2015-09-07 16:03:19 +00:00
|
|
|
out2:
|
|
|
|
generic_end_io_acct(rw, &zv->zv_disk->part0, start);
|
|
|
|
out1:
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
bio_endio(bio, -error);
|
|
|
|
spl_fstrans_unmark(cookie);
|
|
|
|
#ifdef HAVE_MAKE_REQUEST_FN_RET_INT
|
|
|
|
return (0);
|
|
|
|
#endif
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
zvol_get_done(zgd_t *zgd, int error)
|
|
|
|
{
|
|
|
|
if (zgd->zgd_db)
|
|
|
|
dmu_buf_rele(zgd->zgd_db, zgd);
|
|
|
|
|
|
|
|
zfs_range_unlock(zgd->zgd_rl);
|
|
|
|
|
|
|
|
if (error == 0 && zgd->zgd_bp)
|
|
|
|
zil_add_block(zgd->zgd_zilog, zgd->zgd_bp);
|
|
|
|
|
|
|
|
kmem_free(zgd, sizeof (zgd_t));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get data to generate a TX_WRITE intent log record.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
zvol_get_data(void *arg, lr_write_t *lr, char *buf, zio_t *zio)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = arg;
|
|
|
|
objset_t *os = zv->zv_objset;
|
2013-05-10 19:47:54 +00:00
|
|
|
uint64_t object = ZVOL_OBJ;
|
2010-08-26 18:45:02 +00:00
|
|
|
uint64_t offset = lr->lr_offset;
|
|
|
|
uint64_t size = lr->lr_length;
|
2013-05-10 19:47:54 +00:00
|
|
|
blkptr_t *bp = &lr->lr_blkptr;
|
2010-08-26 18:45:02 +00:00
|
|
|
dmu_buf_t *db;
|
|
|
|
zgd_t *zgd;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
ASSERT(zio != NULL);
|
|
|
|
ASSERT(size != 0);
|
|
|
|
|
2014-11-21 00:09:39 +00:00
|
|
|
zgd = (zgd_t *)kmem_zalloc(sizeof (zgd_t), KM_SLEEP);
|
2010-08-26 18:45:02 +00:00
|
|
|
zgd->zgd_zilog = zv->zv_zilog;
|
|
|
|
zgd->zgd_rl = zfs_range_lock(&zv->zv_znode, offset, size, RL_READER);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write records come in two flavors: immediate and indirect.
|
|
|
|
* For small writes it's cheaper to store the data with the
|
|
|
|
* log record (immediate); for large writes it's cheaper to
|
|
|
|
* sync the data and get a pointer to it (indirect) so that
|
|
|
|
* we don't have to write the data twice.
|
|
|
|
*/
|
|
|
|
if (buf != NULL) { /* immediate write */
|
2013-05-10 19:47:54 +00:00
|
|
|
error = dmu_read(os, object, offset, size, buf,
|
2010-08-26 18:45:02 +00:00
|
|
|
DMU_READ_NO_PREFETCH);
|
|
|
|
} else {
|
|
|
|
size = zv->zv_volblocksize;
|
|
|
|
offset = P2ALIGN_TYPED(offset, size, uint64_t);
|
2013-05-10 19:47:54 +00:00
|
|
|
error = dmu_buf_hold(os, object, offset, zgd, &db,
|
2010-08-26 18:45:02 +00:00
|
|
|
DMU_READ_NO_PREFETCH);
|
|
|
|
if (error == 0) {
|
2013-05-10 19:47:54 +00:00
|
|
|
blkptr_t *obp = dmu_buf_get_blkptr(db);
|
|
|
|
if (obp) {
|
|
|
|
ASSERT(BP_IS_HOLE(bp));
|
|
|
|
*bp = *obp;
|
|
|
|
}
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
zgd->zgd_db = db;
|
|
|
|
zgd->zgd_bp = &lr->lr_blkptr;
|
|
|
|
|
|
|
|
ASSERT(db != NULL);
|
|
|
|
ASSERT(db->db_offset == offset);
|
|
|
|
ASSERT(db->db_size == size);
|
|
|
|
|
|
|
|
error = dmu_sync(zio, lr->lr_common.lrc_txg,
|
|
|
|
zvol_get_done, zgd);
|
|
|
|
|
|
|
|
if (error == 0)
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
zvol_get_done(zgd, error);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The zvol_state_t's are inserted in increasing MINOR(dev_t) order.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
zvol_insert(zvol_state_t *zv_insert)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = NULL;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
ASSERT3U(MINOR(zv_insert->zv_dev) & ZVOL_MINOR_MASK, ==, 0);
|
|
|
|
for (zv = list_head(&zvol_state_list); zv != NULL;
|
2013-12-12 21:04:40 +00:00
|
|
|
zv = list_next(&zvol_state_list, zv)) {
|
2010-08-26 18:45:02 +00:00
|
|
|
if (MINOR(zv->zv_dev) > MINOR(zv_insert->zv_dev))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_insert_before(&zvol_state_list, zv, zv_insert);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Simply remove the zvol from to list of zvols.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
zvol_remove(zvol_state_t *zv_remove)
|
|
|
|
{
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
list_remove(&zvol_state_list, zv_remove);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_first_open(zvol_state_t *zv)
|
|
|
|
{
|
|
|
|
objset_t *os;
|
|
|
|
uint64_t volsize;
|
2012-12-19 21:51:44 +00:00
|
|
|
int locked = 0;
|
2010-08-26 18:45:02 +00:00
|
|
|
int error;
|
|
|
|
uint64_t ro;
|
|
|
|
|
2012-12-19 21:51:44 +00:00
|
|
|
/*
|
|
|
|
* In all other cases the spa_namespace_lock is taken before the
|
|
|
|
* bdev->bd_mutex lock. But in this case the Linux __blkdev_get()
|
|
|
|
* function calls fops->open() with the bdev->bd_mutex lock held.
|
|
|
|
*
|
|
|
|
* To avoid a potential lock inversion deadlock we preemptively
|
|
|
|
* try to take the spa_namespace_lock(). Normally it will not
|
|
|
|
* be contended and this is safe because spa_open_common() handles
|
|
|
|
* the case where the caller already holds the spa_namespace_lock.
|
|
|
|
*
|
|
|
|
* When it is contended we risk a lock inversion if we were to
|
|
|
|
* block waiting for the lock. Luckily, the __blkdev_get()
|
|
|
|
* function allows us to return -ERESTARTSYS which will result in
|
|
|
|
* bdev->bd_mutex being dropped, reacquired, and fops->open() being
|
|
|
|
* called again. This process can be repeated safely until both
|
|
|
|
* locks are acquired.
|
|
|
|
*/
|
|
|
|
if (!mutex_owned(&spa_namespace_lock)) {
|
|
|
|
locked = mutex_tryenter(&spa_namespace_lock);
|
|
|
|
if (!locked)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (-SET_ERROR(ERESTARTSYS));
|
2012-12-19 21:51:44 +00:00
|
|
|
}
|
|
|
|
|
2014-12-20 00:28:48 +00:00
|
|
|
error = dsl_prop_get_integer(zv->zv_name, "readonly", &ro, NULL);
|
|
|
|
if (error)
|
|
|
|
goto out_mutex;
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
/* lie and say we're read-only */
|
|
|
|
error = dmu_objset_own(zv->zv_name, DMU_OST_ZVOL, 1, zvol_tag, &os);
|
|
|
|
if (error)
|
2013-01-18 17:44:09 +00:00
|
|
|
goto out_mutex;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
error = zap_lookup(os, ZVOL_ZAP_OBJ, "size", 8, 1, &volsize);
|
|
|
|
if (error) {
|
2013-01-18 17:44:09 +00:00
|
|
|
dmu_objset_disown(os, zvol_tag);
|
|
|
|
goto out_mutex;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
zv->zv_objset = os;
|
|
|
|
error = dmu_bonus_hold(os, ZVOL_OBJ, zvol_tag, &zv->zv_dbuf);
|
|
|
|
if (error) {
|
2013-01-18 17:44:09 +00:00
|
|
|
dmu_objset_disown(os, zvol_tag);
|
|
|
|
goto out_mutex;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
set_capacity(zv->zv_disk, volsize >> 9);
|
|
|
|
zv->zv_volsize = volsize;
|
|
|
|
zv->zv_zilog = zil_open(os, zvol_get_data);
|
|
|
|
|
2013-03-03 05:57:39 +00:00
|
|
|
if (ro || dmu_objset_is_snapshot(os) ||
|
|
|
|
!spa_writeable(dmu_objset_spa(os))) {
|
2013-01-18 17:44:09 +00:00
|
|
|
set_disk_ro(zv->zv_disk, 1);
|
|
|
|
zv->zv_flags |= ZVOL_RDONLY;
|
2010-08-26 18:45:02 +00:00
|
|
|
} else {
|
2013-01-18 17:44:09 +00:00
|
|
|
set_disk_ro(zv->zv_disk, 0);
|
|
|
|
zv->zv_flags &= ~ZVOL_RDONLY;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-01-18 17:44:09 +00:00
|
|
|
out_mutex:
|
|
|
|
if (locked)
|
|
|
|
mutex_exit(&spa_namespace_lock);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(-error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
zvol_last_close(zvol_state_t *zv)
|
|
|
|
{
|
|
|
|
zil_close(zv->zv_zilog);
|
|
|
|
zv->zv_zilog = NULL;
|
2012-08-24 14:12:46 +00:00
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
dmu_buf_rele(zv->zv_dbuf, zvol_tag);
|
|
|
|
zv->zv_dbuf = NULL;
|
2012-08-24 14:12:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Evict cached data
|
|
|
|
*/
|
|
|
|
if (dsl_dataset_is_dirty(dmu_objset_ds(zv->zv_objset)) &&
|
|
|
|
!(zv->zv_flags & ZVOL_RDONLY))
|
|
|
|
txg_wait_synced(dmu_objset_pool(zv->zv_objset), 0);
|
|
|
|
(void) dmu_objset_evict_dbufs(zv->zv_objset);
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
dmu_objset_disown(zv->zv_objset, zvol_tag);
|
|
|
|
zv->zv_objset = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_open(struct block_device *bdev, fmode_t flag)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = bdev->bd_disk->private_data;
|
|
|
|
int error = 0, drop_mutex = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the caller is already holding the mutex do not take it
|
|
|
|
* again, this will happen as part of zvol_create_minor().
|
|
|
|
* Once add_disk() is called the device is live and the kernel
|
|
|
|
* will attempt to open it to read the partition information.
|
|
|
|
*/
|
|
|
|
if (!mutex_owned(&zvol_state_lock)) {
|
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
drop_mutex = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ASSERT3P(zv, !=, NULL);
|
|
|
|
|
|
|
|
if (zv->zv_open_count == 0) {
|
|
|
|
error = zvol_first_open(zv);
|
|
|
|
if (error)
|
|
|
|
goto out_mutex;
|
|
|
|
}
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
if ((flag & FMODE_WRITE) && (zv->zv_flags & ZVOL_RDONLY)) {
|
2010-08-26 18:45:02 +00:00
|
|
|
error = -EROFS;
|
|
|
|
goto out_open_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
zv->zv_open_count++;
|
|
|
|
|
|
|
|
out_open_count:
|
|
|
|
if (zv->zv_open_count == 0)
|
|
|
|
zvol_last_close(zv);
|
|
|
|
|
|
|
|
out_mutex:
|
|
|
|
if (drop_mutex)
|
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
|
|
|
|
check_disk_change(bdev);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-06-03 06:58:52 +00:00
|
|
|
#ifdef HAVE_BLOCK_DEVICE_OPERATIONS_RELEASE_VOID
|
|
|
|
static void
|
|
|
|
#else
|
2010-08-26 18:45:02 +00:00
|
|
|
static int
|
2013-06-03 06:58:52 +00:00
|
|
|
#endif
|
2010-08-26 18:45:02 +00:00
|
|
|
zvol_release(struct gendisk *disk, fmode_t mode)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = disk->private_data;
|
|
|
|
int drop_mutex = 0;
|
|
|
|
|
|
|
|
if (!mutex_owned(&zvol_state_lock)) {
|
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
drop_mutex = 1;
|
|
|
|
}
|
|
|
|
|
2013-03-08 18:48:18 +00:00
|
|
|
if (zv->zv_open_count > 0) {
|
|
|
|
zv->zv_open_count--;
|
|
|
|
if (zv->zv_open_count == 0)
|
|
|
|
zvol_last_close(zv);
|
|
|
|
}
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
if (drop_mutex)
|
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
|
2013-06-03 06:58:52 +00:00
|
|
|
#ifndef HAVE_BLOCK_DEVICE_OPERATIONS_RELEASE_VOID
|
2010-08-26 18:45:02 +00:00
|
|
|
return (0);
|
2013-06-03 06:58:52 +00:00
|
|
|
#endif
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_ioctl(struct block_device *bdev, fmode_t mode,
|
2013-12-12 21:04:40 +00:00
|
|
|
unsigned int cmd, unsigned long arg)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
zvol_state_t *zv = bdev->bd_disk->private_data;
|
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
if (zv == NULL)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(-ENXIO));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case BLKFLSBUF:
|
|
|
|
zil_commit(zv->zv_zilog, ZVOL_OBJ);
|
|
|
|
break;
|
2011-02-22 10:58:44 +00:00
|
|
|
case BLKZNAME:
|
|
|
|
error = copy_to_user((void *)arg, zv->zv_name, MAXNAMELEN);
|
|
|
|
break;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
default:
|
|
|
|
error = -ENOTTY;
|
|
|
|
break;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
static int
|
|
|
|
zvol_compat_ioctl(struct block_device *bdev, fmode_t mode,
|
2013-12-12 21:04:40 +00:00
|
|
|
unsigned cmd, unsigned long arg)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
2013-12-12 21:04:40 +00:00
|
|
|
return (zvol_ioctl(bdev, mode, cmd, arg));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
#else
|
2013-12-12 21:04:40 +00:00
|
|
|
#define zvol_compat_ioctl NULL
|
2010-08-26 18:45:02 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
static int zvol_media_changed(struct gendisk *disk)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = disk->private_data;
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (zv->zv_changed);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int zvol_revalidate_disk(struct gendisk *disk)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = disk->private_data;
|
|
|
|
|
|
|
|
zv->zv_changed = 0;
|
|
|
|
set_capacity(zv->zv_disk, zv->zv_volsize >> 9);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (0);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Provide a simple virtual geometry for legacy compatibility. For devices
|
|
|
|
* smaller than 1 MiB a small head and sector count is used to allow very
|
|
|
|
* tiny devices. For devices over 1 Mib a standard head and sector count
|
|
|
|
* is used to keep the cylinders count reasonable.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
zvol_getgeo(struct block_device *bdev, struct hd_geometry *geo)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv = bdev->bd_disk->private_data;
|
|
|
|
sector_t sectors = get_capacity(zv->zv_disk);
|
|
|
|
|
|
|
|
if (sectors > 2048) {
|
|
|
|
geo->heads = 16;
|
|
|
|
geo->sectors = 63;
|
|
|
|
} else {
|
|
|
|
geo->heads = 2;
|
|
|
|
geo->sectors = 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
geo->start = 0;
|
|
|
|
geo->cylinders = sectors / (geo->heads * geo->sectors);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (0);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct kobject *
|
|
|
|
zvol_probe(dev_t dev, int *part, void *arg)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
struct kobject *kobj;
|
|
|
|
|
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
zv = zvol_find_by_dev(dev);
|
2012-09-24 17:30:18 +00:00
|
|
|
kobj = zv ? get_disk(zv->zv_disk) : NULL;
|
2010-08-26 18:45:02 +00:00
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (kobj);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef HAVE_BDEV_BLOCK_DEVICE_OPERATIONS
|
|
|
|
static struct block_device_operations zvol_ops = {
|
2013-12-12 21:04:40 +00:00
|
|
|
.open = zvol_open,
|
|
|
|
.release = zvol_release,
|
|
|
|
.ioctl = zvol_ioctl,
|
|
|
|
.compat_ioctl = zvol_compat_ioctl,
|
|
|
|
.media_changed = zvol_media_changed,
|
|
|
|
.revalidate_disk = zvol_revalidate_disk,
|
|
|
|
.getgeo = zvol_getgeo,
|
|
|
|
.owner = THIS_MODULE,
|
2010-08-26 18:45:02 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#else /* HAVE_BDEV_BLOCK_DEVICE_OPERATIONS */
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_open_by_inode(struct inode *inode, struct file *file)
|
|
|
|
{
|
2013-12-12 21:04:40 +00:00
|
|
|
return (zvol_open(inode->i_bdev, file->f_mode));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_release_by_inode(struct inode *inode, struct file *file)
|
|
|
|
{
|
2013-12-12 21:04:40 +00:00
|
|
|
return (zvol_release(inode->i_bdev->bd_disk, file->f_mode));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
zvol_ioctl_by_inode(struct inode *inode, struct file *file,
|
2013-12-12 21:04:40 +00:00
|
|
|
unsigned int cmd, unsigned long arg)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
2010-10-29 19:13:52 +00:00
|
|
|
if (file == NULL || inode == NULL)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(-EINVAL));
|
|
|
|
|
|
|
|
return (zvol_ioctl(inode->i_bdev, file->f_mode, cmd, arg));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
#ifdef CONFIG_COMPAT
|
2010-08-26 18:45:02 +00:00
|
|
|
static long
|
|
|
|
zvol_compat_ioctl_by_inode(struct file *file,
|
2013-12-12 21:04:40 +00:00
|
|
|
unsigned int cmd, unsigned long arg)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
2010-10-29 19:13:52 +00:00
|
|
|
if (file == NULL)
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(-EINVAL));
|
|
|
|
|
|
|
|
return (zvol_compat_ioctl(file->f_dentry->d_inode->i_bdev,
|
|
|
|
file->f_mode, cmd, arg));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
2013-12-12 21:04:40 +00:00
|
|
|
#else
|
|
|
|
#define zvol_compat_ioctl_by_inode NULL
|
|
|
|
#endif
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
static struct block_device_operations zvol_ops = {
|
2013-12-12 21:04:40 +00:00
|
|
|
.open = zvol_open_by_inode,
|
|
|
|
.release = zvol_release_by_inode,
|
|
|
|
.ioctl = zvol_ioctl_by_inode,
|
|
|
|
.compat_ioctl = zvol_compat_ioctl_by_inode,
|
|
|
|
.media_changed = zvol_media_changed,
|
|
|
|
.revalidate_disk = zvol_revalidate_disk,
|
|
|
|
.getgeo = zvol_getgeo,
|
|
|
|
.owner = THIS_MODULE,
|
2010-08-26 18:45:02 +00:00
|
|
|
};
|
|
|
|
#endif /* HAVE_BDEV_BLOCK_DEVICE_OPERATIONS */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate memory for a new zvol_state_t and setup the required
|
|
|
|
* request queue and generic disk structures for the block device.
|
|
|
|
*/
|
|
|
|
static zvol_state_t *
|
|
|
|
zvol_alloc(dev_t dev, const char *name)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
|
2014-11-21 00:09:39 +00:00
|
|
|
zv = kmem_zalloc(sizeof (zvol_state_t), KM_SLEEP);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2013-07-02 18:59:10 +00:00
|
|
|
spin_lock_init(&zv->zv_lock);
|
|
|
|
list_link_init(&zv->zv_next);
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
zv->zv_queue = blk_alloc_queue(GFP_ATOMIC);
|
2010-08-26 18:45:02 +00:00
|
|
|
if (zv->zv_queue == NULL)
|
|
|
|
goto out_kmem;
|
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
blk_queue_make_request(zv->zv_queue, zvol_request);
|
2012-10-05 17:39:35 +00:00
|
|
|
|
2011-09-05 09:11:38 +00:00
|
|
|
#ifdef HAVE_BLK_QUEUE_FLUSH
|
|
|
|
blk_queue_flush(zv->zv_queue, VDEV_REQ_FLUSH | VDEV_REQ_FUA);
|
|
|
|
#else
|
|
|
|
blk_queue_ordered(zv->zv_queue, QUEUE_ORDERED_DRAIN, NULL);
|
|
|
|
#endif /* HAVE_BLK_QUEUE_FLUSH */
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
zv->zv_disk = alloc_disk(ZVOL_MINORS);
|
|
|
|
if (zv->zv_disk == NULL)
|
|
|
|
goto out_queue;
|
|
|
|
|
|
|
|
zv->zv_queue->queuedata = zv;
|
|
|
|
zv->zv_dev = dev;
|
|
|
|
zv->zv_open_count = 0;
|
2011-02-22 10:58:44 +00:00
|
|
|
strlcpy(zv->zv_name, name, MAXNAMELEN);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
mutex_init(&zv->zv_znode.z_range_lock, NULL, MUTEX_DEFAULT, NULL);
|
|
|
|
avl_create(&zv->zv_znode.z_range_avl, zfs_range_compare,
|
|
|
|
sizeof (rl_t), offsetof(rl_t, r_node));
|
2011-02-08 19:29:50 +00:00
|
|
|
zv->zv_znode.z_is_zvol = TRUE;
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
zv->zv_disk->major = zvol_major;
|
|
|
|
zv->zv_disk->first_minor = (dev & MINORMASK);
|
|
|
|
zv->zv_disk->fops = &zvol_ops;
|
|
|
|
zv->zv_disk->private_data = zv;
|
|
|
|
zv->zv_disk->queue = zv->zv_queue;
|
2011-02-22 10:58:44 +00:00
|
|
|
snprintf(zv->zv_disk->disk_name, DISK_NAME_LEN, "%s%d",
|
|
|
|
ZVOL_DEV_NAME, (dev & MINORMASK));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (zv);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
out_queue:
|
|
|
|
blk_cleanup_queue(zv->zv_queue);
|
|
|
|
out_kmem:
|
|
|
|
kmem_free(zv, sizeof (zvol_state_t));
|
2013-06-29 11:07:45 +00:00
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (NULL);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Cleanup then free a zvol_state_t which was created by zvol_alloc().
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
zvol_free(zvol_state_t *zv)
|
|
|
|
{
|
|
|
|
avl_destroy(&zv->zv_znode.z_range_avl);
|
|
|
|
mutex_destroy(&zv->zv_znode.z_range_lock);
|
|
|
|
|
|
|
|
del_gendisk(zv->zv_disk);
|
|
|
|
blk_cleanup_queue(zv->zv_queue);
|
|
|
|
put_disk(zv->zv_disk);
|
|
|
|
|
|
|
|
kmem_free(zv, sizeof (zvol_state_t));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2013-02-13 23:11:59 +00:00
|
|
|
__zvol_snapdev_hidden(const char *name)
|
|
|
|
{
|
2013-12-12 21:04:40 +00:00
|
|
|
uint64_t snapdev;
|
|
|
|
char *parent;
|
|
|
|
char *atp;
|
|
|
|
int error = 0;
|
|
|
|
|
2014-11-21 00:09:39 +00:00
|
|
|
parent = kmem_alloc(MAXPATHLEN, KM_SLEEP);
|
2013-12-12 21:04:40 +00:00
|
|
|
(void) strlcpy(parent, name, MAXPATHLEN);
|
|
|
|
|
|
|
|
if ((atp = strrchr(parent, '@')) != NULL) {
|
|
|
|
*atp = '\0';
|
|
|
|
error = dsl_prop_get_integer(parent, "snapdev", &snapdev, NULL);
|
|
|
|
if ((error == 0) && (snapdev == ZFS_SNAPDEV_HIDDEN))
|
|
|
|
error = SET_ERROR(ENODEV);
|
|
|
|
}
|
|
|
|
|
|
|
|
kmem_free(parent, MAXPATHLEN);
|
|
|
|
|
|
|
|
return (SET_ERROR(error));
|
2013-02-13 23:11:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
__zvol_create_minor(const char *name, boolean_t ignore_snapdev)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
objset_t *os;
|
|
|
|
dmu_object_info_t *doi;
|
|
|
|
uint64_t volsize;
|
2015-08-18 20:51:20 +00:00
|
|
|
uint64_t len;
|
2010-08-26 18:45:02 +00:00
|
|
|
unsigned minor = 0;
|
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
|
|
|
|
zv = zvol_find_by_name(name);
|
|
|
|
if (zv) {
|
2013-03-08 18:41:28 +00:00
|
|
|
error = SET_ERROR(EEXIST);
|
2010-08-26 18:45:02 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2013-02-13 23:11:59 +00:00
|
|
|
if (ignore_snapdev == B_FALSE) {
|
|
|
|
error = __zvol_snapdev_hidden(name);
|
|
|
|
if (error)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-11-21 00:09:39 +00:00
|
|
|
doi = kmem_alloc(sizeof (dmu_object_info_t), KM_SLEEP);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
error = dmu_objset_own(name, DMU_OST_ZVOL, B_TRUE, zvol_tag, &os);
|
|
|
|
if (error)
|
|
|
|
goto out_doi;
|
|
|
|
|
|
|
|
error = dmu_object_info(os, ZVOL_OBJ, doi);
|
|
|
|
if (error)
|
|
|
|
goto out_dmu_objset_disown;
|
|
|
|
|
|
|
|
error = zap_lookup(os, ZVOL_ZAP_OBJ, "size", 8, 1, &volsize);
|
|
|
|
if (error)
|
|
|
|
goto out_dmu_objset_disown;
|
|
|
|
|
|
|
|
error = zvol_find_minor(&minor);
|
|
|
|
if (error)
|
|
|
|
goto out_dmu_objset_disown;
|
|
|
|
|
|
|
|
zv = zvol_alloc(MKDEV(zvol_major, minor), name);
|
|
|
|
if (zv == NULL) {
|
2013-03-08 18:41:28 +00:00
|
|
|
error = SET_ERROR(EAGAIN);
|
2010-08-26 18:45:02 +00:00
|
|
|
goto out_dmu_objset_disown;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dmu_objset_is_snapshot(os))
|
|
|
|
zv->zv_flags |= ZVOL_RDONLY;
|
|
|
|
|
|
|
|
zv->zv_volblocksize = doi->doi_data_block_size;
|
|
|
|
zv->zv_volsize = volsize;
|
|
|
|
zv->zv_objset = os;
|
|
|
|
|
|
|
|
set_capacity(zv->zv_disk, zv->zv_volsize >> 9);
|
|
|
|
|
2015-08-28 00:01:59 +00:00
|
|
|
blk_queue_max_hw_sectors(zv->zv_queue, (DMU_MAX_ACCESS / 4) >> 9);
|
2011-09-05 13:15:45 +00:00
|
|
|
blk_queue_max_segments(zv->zv_queue, UINT16_MAX);
|
|
|
|
blk_queue_max_segment_size(zv->zv_queue, UINT_MAX);
|
|
|
|
blk_queue_physical_block_size(zv->zv_queue, zv->zv_volblocksize);
|
|
|
|
blk_queue_io_opt(zv->zv_queue, zv->zv_volblocksize);
|
Limit the number of blocks to discard at once.
The number of blocks that can be discarded in one BLKDISCARD ioctl on a
zvol is currently unlimited. Some applications, such as mkfs, discard
the whole volume at once and they use the maximum possible discard size
to do that. As a result, several gigabytes discard requests are not
uncommon.
Unfortunately, if a large amount of data is allocated in the zvol, ZFS
can be quite slow to process discard requests. This is especially true
if the volblocksize is low (e.g. the 8K default). As a result, very
large discard requests can take a very long time (seconds to minutes
under heavy load) to complete. This can cause a number of problems, most
notably if the zvol is accessed remotely (e.g. via iSCSI), in which case
the client has a high probability of timing out on the request.
This patch solves the issue by adding a new tunable module parameter:
zvol_max_discard_blocks. This indicates the maximum possible range, in
zvol blocks, of one discard operation. It is set by default to 16384
blocks, which appears to be a good tradeoff. Using the default
volblocksize of 8K this is equivalent to 128 MB. When using the maximum
volblocksize of 128K this is equivalent to 2 GB.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #858
2012-07-31 08:45:37 +00:00
|
|
|
blk_queue_max_discard_sectors(zv->zv_queue,
|
|
|
|
(zvol_max_discard_blocks * zv->zv_volblocksize) >> 9);
|
2012-08-01 08:29:59 +00:00
|
|
|
blk_queue_discard_granularity(zv->zv_queue, zv->zv_volblocksize);
|
2011-09-02 13:23:12 +00:00
|
|
|
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, zv->zv_queue);
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
#ifdef QUEUE_FLAG_NONROT
|
2011-09-05 13:15:45 +00:00
|
|
|
queue_flag_set_unlocked(QUEUE_FLAG_NONROT, zv->zv_queue);
|
|
|
|
#endif
|
2015-08-29 16:49:55 +00:00
|
|
|
#ifdef QUEUE_FLAG_ADD_RANDOM
|
|
|
|
queue_flag_clear_unlocked(QUEUE_FLAG_ADD_RANDOM, zv->zv_queue);
|
|
|
|
#endif
|
2011-09-05 13:15:45 +00:00
|
|
|
|
2013-03-03 05:57:39 +00:00
|
|
|
if (spa_writeable(dmu_objset_spa(os))) {
|
|
|
|
if (zil_replay_disable)
|
|
|
|
zil_destroy(dmu_objset_zil(os), B_FALSE);
|
|
|
|
else
|
|
|
|
zil_replay(os, zv, zvol_replay_vector);
|
|
|
|
}
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2015-08-18 20:51:20 +00:00
|
|
|
/*
|
|
|
|
* When udev detects the addition of the device it will immediately
|
|
|
|
* invoke blkid(8) to determine the type of content on the device.
|
|
|
|
* Prefetching the blocks commonly scanned by blkid(8) will speed
|
|
|
|
* up this process.
|
|
|
|
*/
|
|
|
|
len = MIN(MAX(zvol_prefetch_bytes, 0), SPA_MAXBLOCKSIZE);
|
|
|
|
if (len > 0) {
|
|
|
|
dmu_prefetch(os, ZVOL_OBJ, 0, len);
|
|
|
|
dmu_prefetch(os, ZVOL_OBJ, volsize - len, len);
|
|
|
|
}
|
|
|
|
|
2012-11-27 22:02:49 +00:00
|
|
|
zv->zv_objset = NULL;
|
2010-08-26 18:45:02 +00:00
|
|
|
out_dmu_objset_disown:
|
|
|
|
dmu_objset_disown(os, zvol_tag);
|
|
|
|
out_doi:
|
2013-12-12 21:04:40 +00:00
|
|
|
kmem_free(doi, sizeof (dmu_object_info_t));
|
2010-08-26 18:45:02 +00:00
|
|
|
out:
|
|
|
|
|
|
|
|
if (error == 0) {
|
|
|
|
zvol_insert(zv);
|
|
|
|
add_disk(zv->zv_disk);
|
|
|
|
}
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a block device minor node and setup the linkage between it
|
|
|
|
* and the specified volume. Once this function returns the block
|
|
|
|
* device is live and ready for use.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
zvol_create_minor(const char *name)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
mutex_enter(&zvol_state_lock);
|
2013-02-13 23:11:59 +00:00
|
|
|
error = __zvol_create_minor(name, B_FALSE);
|
2010-08-26 18:45:02 +00:00
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
__zvol_remove_minor(const char *name)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
|
|
|
|
zv = zvol_find_by_name(name);
|
|
|
|
if (zv == NULL)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(ENXIO));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
if (zv->zv_open_count > 0)
|
2013-03-08 18:41:28 +00:00
|
|
|
return (SET_ERROR(EBUSY));
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
zvol_remove(zv);
|
|
|
|
zvol_free(zv);
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove a block device minor node for the specified volume.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
zvol_remove_minor(const char *name)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
error = __zvol_remove_minor(name);
|
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
/*
|
|
|
|
* Rename a block device minor mode for the specified volume.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
__zvol_rename_minor(zvol_state_t *zv, const char *newname)
|
|
|
|
{
|
|
|
|
int readonly = get_disk_ro(zv->zv_disk);
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&zvol_state_lock));
|
|
|
|
|
|
|
|
strlcpy(zv->zv_name, newname, sizeof (zv->zv_name));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The block device's read-only state is briefly changed causing
|
|
|
|
* a KOBJ_CHANGE uevent to be issued. This ensures udev detects
|
|
|
|
* the name change and fixes the symlinks. This does not change
|
|
|
|
* ZVOL_RDONLY in zv->zv_flags so the actual read-only state never
|
|
|
|
* changes. This would normally be done using kobject_uevent() but
|
|
|
|
* that is a GPL-only symbol which is why we need this workaround.
|
|
|
|
*/
|
|
|
|
set_disk_ro(zv->zv_disk, !readonly);
|
|
|
|
set_disk_ro(zv->zv_disk, readonly);
|
|
|
|
}
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
static int
|
2013-09-04 12:00:57 +00:00
|
|
|
zvol_create_minors_cb(const char *dsname, void *arg)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
2013-12-06 22:20:22 +00:00
|
|
|
(void) zvol_create_minor(dsname);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2011-02-16 17:40:29 +00:00
|
|
|
return (0);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-12-06 22:20:22 +00:00
|
|
|
* Create minors for specified dataset including children and snapshots.
|
2010-08-26 18:45:02 +00:00
|
|
|
*/
|
|
|
|
int
|
2013-12-06 22:20:22 +00:00
|
|
|
zvol_create_minors(const char *name)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
int error = 0;
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
if (!zvol_inhibit_dev)
|
|
|
|
error = dmu_objset_find((char *)name, zvol_create_minors_cb,
|
|
|
|
NULL, DS_FIND_CHILDREN | DS_FIND_SNAPSHOTS);
|
|
|
|
|
|
|
|
return (SET_ERROR(error));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove minors for specified dataset including children and snapshots.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
zvol_remove_minors(const char *name)
|
|
|
|
{
|
|
|
|
zvol_state_t *zv, *zv_next;
|
|
|
|
int namelen = ((name) ? strlen(name) : 0);
|
|
|
|
|
2012-06-02 01:49:10 +00:00
|
|
|
if (zvol_inhibit_dev)
|
2013-12-06 22:20:22 +00:00
|
|
|
return;
|
2012-06-02 01:49:10 +00:00
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
mutex_enter(&zvol_state_lock);
|
2013-12-06 22:20:22 +00:00
|
|
|
|
|
|
|
for (zv = list_head(&zvol_state_list); zv != NULL; zv = zv_next) {
|
|
|
|
zv_next = list_next(&zvol_state_list, zv);
|
|
|
|
|
|
|
|
if (name == NULL || strcmp(zv->zv_name, name) == 0 ||
|
|
|
|
(strncmp(zv->zv_name, name, namelen) == 0 &&
|
|
|
|
zv->zv_name[namelen] == '/')) {
|
|
|
|
zvol_remove(zv);
|
|
|
|
zvol_free(zv);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
mutex_exit(&zvol_state_lock);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-12-06 22:20:22 +00:00
|
|
|
* Rename minors for specified dataset including children and snapshots.
|
2010-08-26 18:45:02 +00:00
|
|
|
*/
|
|
|
|
void
|
2013-12-06 22:20:22 +00:00
|
|
|
zvol_rename_minors(const char *oldname, const char *newname)
|
2010-08-26 18:45:02 +00:00
|
|
|
{
|
|
|
|
zvol_state_t *zv, *zv_next;
|
2013-12-06 22:20:22 +00:00
|
|
|
int oldnamelen, newnamelen;
|
|
|
|
char *name;
|
2010-08-26 18:45:02 +00:00
|
|
|
|
2012-06-02 01:49:10 +00:00
|
|
|
if (zvol_inhibit_dev)
|
|
|
|
return;
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
oldnamelen = strlen(oldname);
|
|
|
|
newnamelen = strlen(newname);
|
2014-11-21 00:09:39 +00:00
|
|
|
name = kmem_alloc(MAXNAMELEN, KM_SLEEP);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
mutex_enter(&zvol_state_lock);
|
2013-12-06 22:20:22 +00:00
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
for (zv = list_head(&zvol_state_list); zv != NULL; zv = zv_next) {
|
|
|
|
zv_next = list_next(&zvol_state_list, zv);
|
|
|
|
|
2013-12-06 22:20:22 +00:00
|
|
|
if (strcmp(zv->zv_name, oldname) == 0) {
|
|
|
|
__zvol_rename_minor(zv, newname);
|
|
|
|
} else if (strncmp(zv->zv_name, oldname, oldnamelen) == 0 &&
|
|
|
|
(zv->zv_name[oldnamelen] == '/' ||
|
|
|
|
zv->zv_name[oldnamelen] == '@')) {
|
|
|
|
snprintf(name, MAXNAMELEN, "%s%c%s", newname,
|
|
|
|
zv->zv_name[oldnamelen],
|
|
|
|
zv->zv_name + oldnamelen + 1);
|
|
|
|
__zvol_rename_minor(zv, name);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
}
|
2013-12-06 22:20:22 +00:00
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
mutex_exit(&zvol_state_lock);
|
2013-12-06 22:20:22 +00:00
|
|
|
|
|
|
|
kmem_free(name, MAXNAMELEN);
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
2013-02-13 23:11:59 +00:00
|
|
|
static int
|
|
|
|
snapdev_snapshot_changed_cb(const char *dsname, void *arg) {
|
|
|
|
uint64_t snapdev = *(uint64_t *) arg;
|
|
|
|
|
|
|
|
if (strchr(dsname, '@') == NULL)
|
2013-12-06 22:20:22 +00:00
|
|
|
return (0);
|
2013-02-13 23:11:59 +00:00
|
|
|
|
|
|
|
switch (snapdev) {
|
|
|
|
case ZFS_SNAPDEV_VISIBLE:
|
|
|
|
mutex_enter(&zvol_state_lock);
|
|
|
|
(void) __zvol_create_minor(dsname, B_TRUE);
|
|
|
|
mutex_exit(&zvol_state_lock);
|
|
|
|
break;
|
|
|
|
case ZFS_SNAPDEV_HIDDEN:
|
|
|
|
(void) zvol_remove_minor(dsname);
|
|
|
|
break;
|
|
|
|
}
|
2013-12-06 22:20:22 +00:00
|
|
|
|
|
|
|
return (0);
|
2013-02-13 23:11:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
zvol_set_snapdev(const char *dsname, uint64_t snapdev) {
|
|
|
|
(void) dmu_objset_find((char *) dsname, snapdev_snapshot_changed_cb,
|
|
|
|
&snapdev, DS_FIND_SNAPSHOTS | DS_FIND_CHILDREN);
|
|
|
|
/* caller should continue to modify snapdev property */
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
int
|
|
|
|
zvol_init(void)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
2013-07-02 18:59:10 +00:00
|
|
|
list_create(&zvol_state_list, sizeof (zvol_state_t),
|
2013-12-12 21:04:40 +00:00
|
|
|
offsetof(zvol_state_t, zv_next));
|
|
|
|
|
2013-07-02 18:59:10 +00:00
|
|
|
mutex_init(&zvol_state_lock, NULL, MUTEX_DEFAULT, NULL);
|
|
|
|
|
2010-08-26 18:45:02 +00:00
|
|
|
error = register_blkdev(zvol_major, ZVOL_DRIVER);
|
|
|
|
if (error) {
|
|
|
|
printk(KERN_INFO "ZFS: register_blkdev() failed %d\n", error);
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
goto out;
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
blk_register_region(MKDEV(zvol_major, 0), 1UL << MINORBITS,
|
2013-12-12 21:04:40 +00:00
|
|
|
THIS_MODULE, zvol_probe, NULL, NULL);
|
2010-08-26 18:45:02 +00:00
|
|
|
|
|
|
|
return (0);
|
2013-07-02 18:59:10 +00:00
|
|
|
|
zvol processing should use struct bio
Internally, zvols are files exposed through the block device API. This
is intended to reduce overhead when things require block devices.
However, the ZoL zvol code emulates a traditional block device in that
it has a top half and a bottom half. This is an unnecessary source of
overhead that does not exist on any other OpenZFS platform does this.
This patch removes it. Early users of this patch reported double digit
performance gains in IOPS on zvols in the range of 50% to 80%.
Comments in the code suggest that the current implementation was done to
obtain IO merging from Linux's IO elevator. However, the DMU already
does write merging while arc_read() should implicitly merge read IOs
because only 1 thread is permitted to fetch the buffer into ARC. In
addition, commercial ZFSOnLinux distributions report that regular files
are more performant than zvols under the current implementation, and the
main consumers of zvols are VMs and iSCSI targets, which have their own
elevators to merge IOs.
Some minor refactoring allows us to register zfs_request() as our
->make_request() handler in place of the generic_make_request()
function. This eliminates the layer of code that broke IO requests on
zvols into a top half and a bottom half. This has several benefits:
1. No per zvol spinlocks.
2. No redundant IO elevator processing.
3. Interrupts are disabled only when actually necessary.
4. No redispatching of IOs when all taskq threads are busy.
5. Linux's page out routines will properly block.
6. Many autotools checks become obsolete.
An unfortunate consequence of eliminating the layer that
generic_make_request() is that we no longer calls the instrumentation
hooks for block IO accounting. Those hooks are GPL-exported, so we
cannot call them ourselves and consequently, we lose the ability to do
IO monitoring via iostat. Since zvols are internally files mapped as
block devices, this should be okay. Anyone who is willing to accept the
performance penalty for the block IO layer's accounting could use the
loop device in between the zvol and its consumer. Alternatively, perf
and ftrace likely could be used. Also, tools like latencytop will still
work. Tools such as latencytop sometimes provide a better view of
performance bottlenecks than the traditional block IO accounting tools
do.
Lastly, if direct reclaim occurs during spacemap loading and swap is on
a zvol, this code will deadlock. That deadlock could already occur with
sync=always on zvols. Given that swap on zvols is not yet production
ready, this is not a blocker.
Signed-off-by: Richard Yao <ryao@gentoo.org>
2014-07-04 22:43:47 +00:00
|
|
|
out:
|
2013-07-02 18:59:10 +00:00
|
|
|
mutex_destroy(&zvol_state_lock);
|
|
|
|
list_destroy(&zvol_state_list);
|
|
|
|
|
2013-12-12 21:04:40 +00:00
|
|
|
return (SET_ERROR(error));
|
2010-08-26 18:45:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
zvol_fini(void)
|
|
|
|
{
|
|
|
|
zvol_remove_minors(NULL);
|
|
|
|
blk_unregister_region(MKDEV(zvol_major, 0), 1UL << MINORBITS);
|
|
|
|
unregister_blkdev(zvol_major, ZVOL_DRIVER);
|
|
|
|
mutex_destroy(&zvol_state_lock);
|
|
|
|
list_destroy(&zvol_state_list);
|
|
|
|
}
|
|
|
|
|
2012-06-02 01:49:10 +00:00
|
|
|
module_param(zvol_inhibit_dev, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(zvol_inhibit_dev, "Do not create zvol device nodes");
|
|
|
|
|
2011-12-07 17:23:44 +00:00
|
|
|
module_param(zvol_major, uint, 0444);
|
2010-08-26 18:45:02 +00:00
|
|
|
MODULE_PARM_DESC(zvol_major, "Major number for zvol device");
|
|
|
|
|
Limit the number of blocks to discard at once.
The number of blocks that can be discarded in one BLKDISCARD ioctl on a
zvol is currently unlimited. Some applications, such as mkfs, discard
the whole volume at once and they use the maximum possible discard size
to do that. As a result, several gigabytes discard requests are not
uncommon.
Unfortunately, if a large amount of data is allocated in the zvol, ZFS
can be quite slow to process discard requests. This is especially true
if the volblocksize is low (e.g. the 8K default). As a result, very
large discard requests can take a very long time (seconds to minutes
under heavy load) to complete. This can cause a number of problems, most
notably if the zvol is accessed remotely (e.g. via iSCSI), in which case
the client has a high probability of timing out on the request.
This patch solves the issue by adding a new tunable module parameter:
zvol_max_discard_blocks. This indicates the maximum possible range, in
zvol blocks, of one discard operation. It is set by default to 16384
blocks, which appears to be a good tradeoff. Using the default
volblocksize of 8K this is equivalent to 128 MB. When using the maximum
volblocksize of 128K this is equivalent to 2 GB.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #858
2012-07-31 08:45:37 +00:00
|
|
|
module_param(zvol_max_discard_blocks, ulong, 0444);
|
2013-12-12 21:04:40 +00:00
|
|
|
MODULE_PARM_DESC(zvol_max_discard_blocks, "Max number of blocks to discard");
|
2015-08-18 20:51:20 +00:00
|
|
|
|
|
|
|
module_param(zvol_prefetch_bytes, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(zvol_prefetch_bytes, "Prefetch N bytes at zvol start+end");
|