2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* linux/drivers/block/loop.c
|
|
|
|
*
|
|
|
|
* Written by Theodore Ts'o, 3/29/93
|
|
|
|
*
|
|
|
|
* Copyright 1993 by Theodore Ts'o. Redistribution of this file is
|
|
|
|
* permitted under the GNU General Public License.
|
|
|
|
*
|
|
|
|
* DES encryption plus some minor changes by Werner Almesberger, 30-MAY-1993
|
|
|
|
* more DES encryption plus IDEA encryption by Nicholas J. Leon, June 20, 1996
|
|
|
|
*
|
|
|
|
* Modularized and updated for 1.1.16 kernel - Mitch Dsouza 28th May 1994
|
|
|
|
* Adapted for 1.3.59 kernel - Andries Brouwer, 1 Feb 1996
|
|
|
|
*
|
|
|
|
* Fixed do_loop_request() re-entrancy - Vincent.Renardias@waw.com Mar 20, 1997
|
|
|
|
*
|
|
|
|
* Added devfs support - Richard Gooch <rgooch@atnf.csiro.au> 16-Jan-1998
|
|
|
|
*
|
|
|
|
* Handle sparse backing files correctly - Kenn Humborg, Jun 28, 1998
|
|
|
|
*
|
|
|
|
* Loadable modules and other fixes by AK, 1998
|
|
|
|
*
|
|
|
|
* Make real block number available to downstream transfer functions, enables
|
|
|
|
* CBC (and relatives) mode encryption requiring unique IVs per data block.
|
|
|
|
* Reed H. Petty, rhp@draper.net
|
|
|
|
*
|
|
|
|
* Maximum number of loop devices now dynamic via max_loop module parameter.
|
|
|
|
* Russell Kroll <rkroll@exploits.org> 19990701
|
|
|
|
*
|
|
|
|
* Maximum number of loop devices when compiled-in now selectable by passing
|
|
|
|
* max_loop=<1-255> to the kernel on boot.
|
2007-10-20 01:21:04 +04:00
|
|
|
* Erik I. Bolsø, <eriki@himolde.no>, Oct 31, 1999
|
2005-04-17 02:20:36 +04:00
|
|
|
*
|
|
|
|
* Completely rewrite request handling to be make_request_fn style and
|
|
|
|
* non blocking, pushing work to a helper thread. Lots of fixes from
|
|
|
|
* Al Viro too.
|
|
|
|
* Jens Axboe <axboe@suse.de>, Nov 2000
|
|
|
|
*
|
|
|
|
* Support up to 256 loop devices
|
|
|
|
* Heinz Mauelshagen <mge@sistina.com>, Feb 2002
|
|
|
|
*
|
|
|
|
* Support for falling back on the write file operation when the address space
|
2008-10-30 00:00:55 +03:00
|
|
|
* operations write_begin is not available on the backing filesystem.
|
2005-04-17 02:20:36 +04:00
|
|
|
* Anton Altaparmakov, 16 Feb 2005
|
|
|
|
*
|
|
|
|
* Still To Fix:
|
|
|
|
* - Advisory locking is ignored here.
|
|
|
|
* - Should use an own CAP_* category instead of CAP_SYS_ADMIN
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/moduleparam.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/stat.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/major.h>
|
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/blkpg.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/swap.h>
|
|
|
|
#include <linux/slab.h>
|
2006-08-29 22:06:14 +04:00
|
|
|
#include <linux/compat.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/suspend.h>
|
2007-07-17 15:03:35 +04:00
|
|
|
#include <linux/freezer.h>
|
2010-06-02 16:28:52 +04:00
|
|
|
#include <linux/mutex.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/writeback.h>
|
|
|
|
#include <linux/completion.h>
|
|
|
|
#include <linux/highmem.h>
|
2006-09-29 12:59:11 +04:00
|
|
|
#include <linux/kthread.h>
|
2007-06-04 11:59:47 +04:00
|
|
|
#include <linux/splice.h>
|
2010-08-23 17:16:00 +04:00
|
|
|
#include <linux/sysfs.h>
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
#include <linux/miscdevice.h>
|
2011-08-19 16:50:46 +04:00
|
|
|
#include <linux/falloc.h>
|
2015-04-03 22:21:59 +03:00
|
|
|
#include <linux/uio.h>
|
2013-05-12 18:14:07 +04:00
|
|
|
#include "loop.h"
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2016-12-24 22:46:01 +03:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
static DEFINE_IDR(loop_index_idr);
|
|
|
|
static DEFINE_MUTEX(loop_index_mutex);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
loop: manage partitions in disk image
This patch allows to use loop device with partitionned disk image.
Original behavior of loop is not modified.
A new parameter is introduced to define how many partition we want to be
able to manage per loop device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
# modprobe loop max_part=63
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
And to attach a raw partitionned disk image, the original losetup is used:
# losetup -f etch.img
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-03-05 14:57 /dev/loop0p1
brw-rw---- 1 root disk 7, 2 2008-03-05 14:57 /dev/loop0p2
brw-rw---- 1 root disk 7, 5 2008-03-05 14:57 /dev/loop0p5
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /mnt
bench cdrom home lib mnt root srv usr
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
# umount /mnt
# losetup -d /dev/loop0
Of course, the same behavior can be done using kpartx on a loop device,
but modifying loop avoids to stack several layers of block device (loop +
device mapper), this is a very light modification (40% of modifications
are to manage the new parameter).
Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-03-26 14:11:53 +03:00
|
|
|
static int max_part;
|
|
|
|
static int part_shift;
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
static int transfer_xor(struct loop_device *lo, int cmd,
|
|
|
|
struct page *raw_page, unsigned raw_off,
|
|
|
|
struct page *loop_page, unsigned loop_off,
|
|
|
|
int size, sector_t real_block)
|
|
|
|
{
|
2011-11-25 19:14:18 +04:00
|
|
|
char *raw_buf = kmap_atomic(raw_page) + raw_off;
|
|
|
|
char *loop_buf = kmap_atomic(loop_page) + loop_off;
|
2005-04-17 02:20:36 +04:00
|
|
|
char *in, *out, *key;
|
|
|
|
int i, keysize;
|
|
|
|
|
|
|
|
if (cmd == READ) {
|
|
|
|
in = raw_buf;
|
|
|
|
out = loop_buf;
|
|
|
|
} else {
|
|
|
|
in = loop_buf;
|
|
|
|
out = raw_buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
key = lo->lo_encrypt_key;
|
|
|
|
keysize = lo->lo_encrypt_key_size;
|
|
|
|
for (i = 0; i < size; i++)
|
|
|
|
*out++ = *in++ ^ key[(i & 511) % keysize];
|
|
|
|
|
2011-11-25 19:14:18 +04:00
|
|
|
kunmap_atomic(loop_buf);
|
|
|
|
kunmap_atomic(raw_buf);
|
2005-04-17 02:20:36 +04:00
|
|
|
cond_resched();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int xor_init(struct loop_device *lo, const struct loop_info64 *info)
|
|
|
|
{
|
|
|
|
if (unlikely(info->lo_encrypt_key_size <= 0))
|
|
|
|
return -EINVAL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct loop_func_table none_funcs = {
|
|
|
|
.number = LO_CRYPT_NONE,
|
2015-04-07 19:23:29 +03:00
|
|
|
};
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
static struct loop_func_table xor_funcs = {
|
|
|
|
.number = LO_CRYPT_XOR,
|
|
|
|
.transfer = transfer_xor,
|
|
|
|
.init = xor_init
|
2015-04-07 19:23:29 +03:00
|
|
|
};
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/* xfer_funcs[0] is special - its release function is never called */
|
|
|
|
static struct loop_func_table *xfer_funcs[MAX_LO_CRYPT] = {
|
|
|
|
&none_funcs,
|
|
|
|
&xor_funcs
|
|
|
|
};
|
|
|
|
|
2011-11-16 12:21:49 +04:00
|
|
|
static loff_t get_size(loff_t offset, loff_t sizelimit, struct file *file)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2013-02-22 03:16:50 +04:00
|
|
|
loff_t loopsize;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/* Compute loopsize in bytes */
|
2013-02-22 03:16:50 +04:00
|
|
|
loopsize = i_size_read(file->f_mapping->host);
|
|
|
|
if (offset > 0)
|
|
|
|
loopsize -= offset;
|
|
|
|
/* offset is beyond i_size, weird but possible */
|
2011-11-16 12:21:49 +04:00
|
|
|
if (loopsize < 0)
|
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-11-16 12:21:49 +04:00
|
|
|
if (sizelimit > 0 && sizelimit < loopsize)
|
|
|
|
loopsize = sizelimit;
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* Unfortunately, if we want to do I/O on the device,
|
|
|
|
* the number of 512-byte sectors has to fit into a sector_t.
|
|
|
|
*/
|
|
|
|
return loopsize >> 9;
|
|
|
|
}
|
|
|
|
|
2011-11-16 12:21:49 +04:00
|
|
|
static loff_t get_loop_size(struct loop_device *lo, struct file *file)
|
|
|
|
{
|
|
|
|
return get_size(lo->lo_offset, lo->lo_sizelimit, file);
|
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:49 +03:00
|
|
|
static void __loop_update_dio(struct loop_device *lo, bool dio)
|
|
|
|
{
|
|
|
|
struct file *file = lo->lo_backing_file;
|
|
|
|
struct address_space *mapping = file->f_mapping;
|
|
|
|
struct inode *inode = mapping->host;
|
|
|
|
unsigned short sb_bsize = 0;
|
|
|
|
unsigned dio_align = 0;
|
|
|
|
bool use_dio;
|
|
|
|
|
|
|
|
if (inode->i_sb->s_bdev) {
|
|
|
|
sb_bsize = bdev_logical_block_size(inode->i_sb->s_bdev);
|
|
|
|
dio_align = sb_bsize - 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We support direct I/O only if lo_offset is aligned with the
|
|
|
|
* logical I/O size of backing device, and the logical block
|
|
|
|
* size of loop is bigger than the backing device's and the loop
|
|
|
|
* needn't transform transfer.
|
|
|
|
*
|
|
|
|
* TODO: the above condition may be loosed in the future, and
|
|
|
|
* direct I/O may be switched runtime at that time because most
|
2017-02-28 01:29:01 +03:00
|
|
|
* of requests in sane applications should be PAGE_SIZE aligned
|
2015-08-17 05:31:49 +03:00
|
|
|
*/
|
|
|
|
if (dio) {
|
|
|
|
if (queue_logical_block_size(lo->lo_queue) >= sb_bsize &&
|
|
|
|
!(lo->lo_offset & dio_align) &&
|
|
|
|
mapping->a_ops->direct_IO &&
|
|
|
|
!lo->transfer)
|
|
|
|
use_dio = true;
|
|
|
|
else
|
|
|
|
use_dio = false;
|
|
|
|
} else {
|
|
|
|
use_dio = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (lo->use_dio == use_dio)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* flush dirty pages before changing direct IO */
|
|
|
|
vfs_fsync(file, 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The flag of LO_FLAGS_DIRECT_IO is handled similarly with
|
|
|
|
* LO_FLAGS_READ_ONLY, both are set from kernel, and losetup
|
|
|
|
* will get updated by ioctl(LOOP_GET_STATUS)
|
|
|
|
*/
|
|
|
|
blk_mq_freeze_queue(lo->lo_queue);
|
|
|
|
lo->use_dio = use_dio;
|
2017-09-01 08:09:46 +03:00
|
|
|
if (use_dio) {
|
|
|
|
queue_flag_clear_unlocked(QUEUE_FLAG_NOMERGES, lo->lo_queue);
|
2015-08-17 05:31:49 +03:00
|
|
|
lo->lo_flags |= LO_FLAGS_DIRECT_IO;
|
2017-09-01 08:09:46 +03:00
|
|
|
} else {
|
|
|
|
queue_flag_set_unlocked(QUEUE_FLAG_NOMERGES, lo->lo_queue);
|
2015-08-17 05:31:49 +03:00
|
|
|
lo->lo_flags &= ~LO_FLAGS_DIRECT_IO;
|
2017-09-01 08:09:46 +03:00
|
|
|
}
|
2015-08-17 05:31:49 +03:00
|
|
|
blk_mq_unfreeze_queue(lo->lo_queue);
|
|
|
|
}
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
static int
|
2017-08-24 00:54:59 +03:00
|
|
|
figure_loop_size(struct loop_device *lo, loff_t offset, loff_t sizelimit)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2011-11-16 12:21:49 +04:00
|
|
|
loff_t size = get_size(offset, sizelimit, lo->lo_backing_file);
|
2005-04-17 02:20:36 +04:00
|
|
|
sector_t x = (sector_t)size;
|
2013-02-22 03:16:47 +04:00
|
|
|
struct block_device *bdev = lo->lo_device;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (unlikely((loff_t)x != size))
|
|
|
|
return -EFBIG;
|
2011-11-16 12:21:49 +04:00
|
|
|
if (lo->lo_offset != offset)
|
|
|
|
lo->lo_offset = offset;
|
|
|
|
if (lo->lo_sizelimit != sizelimit)
|
|
|
|
lo->lo_sizelimit = sizelimit;
|
2007-05-08 11:28:20 +04:00
|
|
|
set_capacity(lo->lo_disk, x);
|
2013-02-22 03:16:47 +04:00
|
|
|
bd_set_size(bdev, (loff_t)get_capacity(bdev->bd_disk) << 9);
|
|
|
|
/* let user-space know about the new size */
|
|
|
|
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
|
2011-11-16 12:21:49 +04:00
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
lo_do_transfer(struct loop_device *lo, int cmd,
|
|
|
|
struct page *rpage, unsigned roffs,
|
|
|
|
struct page *lpage, unsigned loffs,
|
|
|
|
int size, sector_t rblock)
|
|
|
|
{
|
2015-04-07 19:23:29 +03:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = lo->transfer(lo, cmd, rpage, roffs, lpage, loffs, size, rblock);
|
|
|
|
if (likely(!ret))
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
printk_ratelimited(KERN_ERR
|
|
|
|
"loop: Transfer error at byte offset %llu, length %i.\n",
|
|
|
|
(unsigned long long)rblock << 9, size);
|
|
|
|
return ret;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
static int lo_write_bvec(struct file *file, struct bio_vec *bvec, loff_t *ppos)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2015-04-07 19:23:29 +03:00
|
|
|
struct iov_iter i;
|
2005-04-17 02:20:36 +04:00
|
|
|
ssize_t bw;
|
2015-04-03 22:21:59 +03:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2013-03-20 21:04:20 +04:00
|
|
|
file_start_write(file);
|
2017-05-27 11:16:52 +03:00
|
|
|
bw = vfs_iter_write(file, &i, ppos, 0);
|
2013-03-20 21:04:20 +04:00
|
|
|
file_end_write(file);
|
2015-04-07 19:23:29 +03:00
|
|
|
|
|
|
|
if (likely(bw == bvec->bv_len))
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
2015-04-07 19:23:29 +03:00
|
|
|
|
|
|
|
printk_ratelimited(KERN_ERR
|
|
|
|
"loop: Write error at byte offset %llu, length %i.\n",
|
|
|
|
(unsigned long long)*ppos, bvec->bv_len);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (bw >= 0)
|
|
|
|
bw = -EIO;
|
|
|
|
return bw;
|
|
|
|
}
|
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
static int lo_write_simple(struct loop_device *lo, struct request *rq,
|
|
|
|
loff_t pos)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2015-04-07 19:23:29 +03:00
|
|
|
struct bio_vec bvec;
|
|
|
|
struct req_iterator iter;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
rq_for_each_segment(bvec, rq, iter) {
|
|
|
|
ret = lo_write_bvec(lo->lo_backing_file, &bvec, &pos);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
/*
|
2011-10-17 14:57:20 +04:00
|
|
|
* This is the slow, transforming version that needs to double buffer the
|
|
|
|
* data as it cannot do the transformations in place without having direct
|
|
|
|
* access to the destination pages of the backing file.
|
2005-04-17 02:20:36 +04:00
|
|
|
*/
|
2015-04-07 19:23:29 +03:00
|
|
|
static int lo_write_transfer(struct loop_device *lo, struct request *rq,
|
|
|
|
loff_t pos)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2015-04-07 19:23:29 +03:00
|
|
|
struct bio_vec bvec, b;
|
2014-12-31 16:22:58 +03:00
|
|
|
struct req_iterator iter;
|
2015-04-07 19:23:29 +03:00
|
|
|
struct page *page;
|
2013-11-24 05:19:00 +04:00
|
|
|
int ret = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
page = alloc_page(GFP_NOIO);
|
|
|
|
if (unlikely(!page))
|
|
|
|
return -ENOMEM;
|
2011-10-17 14:57:20 +04:00
|
|
|
|
2014-12-31 16:22:58 +03:00
|
|
|
rq_for_each_segment(bvec, rq, iter) {
|
2015-04-07 19:23:29 +03:00
|
|
|
ret = lo_do_transfer(lo, WRITE, page, 0, bvec.bv_page,
|
|
|
|
bvec.bv_offset, bvec.bv_len, pos >> 9);
|
|
|
|
if (unlikely(ret))
|
|
|
|
break;
|
|
|
|
|
|
|
|
b.bv_page = page;
|
|
|
|
b.bv_offset = 0;
|
|
|
|
b.bv_len = bvec.bv_len;
|
|
|
|
ret = lo_write_bvec(lo->lo_backing_file, &b, &pos);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
}
|
2015-04-07 19:23:29 +03:00
|
|
|
|
|
|
|
__free_page(page);
|
2005-04-17 02:20:36 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
static int lo_read_simple(struct loop_device *lo, struct request *rq,
|
|
|
|
loff_t pos)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2015-04-07 19:23:29 +03:00
|
|
|
struct bio_vec bvec;
|
|
|
|
struct req_iterator iter;
|
|
|
|
struct iov_iter i;
|
|
|
|
ssize_t len;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
rq_for_each_segment(bvec, rq, iter) {
|
|
|
|
iov_iter_bvec(&i, ITER_BVEC, &bvec, 1, bvec.bv_len);
|
2017-05-27 11:16:51 +03:00
|
|
|
len = vfs_iter_read(lo->lo_backing_file, &i, &pos, 0);
|
2015-04-07 19:23:29 +03:00
|
|
|
if (len < 0)
|
|
|
|
return len;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
flush_dcache_page(bvec.bv_page);
|
2007-06-12 23:20:37 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
if (len != bvec.bv_len) {
|
|
|
|
struct bio *bio;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
__rq_for_each_bio(bio, rq)
|
|
|
|
zero_fill_bio(bio);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2007-06-12 23:20:37 +04:00
|
|
|
}
|
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
static int lo_read_transfer(struct loop_device *lo, struct request *rq,
|
|
|
|
loff_t pos)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2015-04-07 19:23:29 +03:00
|
|
|
struct bio_vec bvec, b;
|
|
|
|
struct req_iterator iter;
|
|
|
|
struct iov_iter i;
|
|
|
|
struct page *page;
|
|
|
|
ssize_t len;
|
|
|
|
int ret = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
page = alloc_page(GFP_NOIO);
|
|
|
|
if (unlikely(!page))
|
|
|
|
return -ENOMEM;
|
2007-06-12 23:20:37 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
rq_for_each_segment(bvec, rq, iter) {
|
|
|
|
loff_t offset = pos;
|
2007-06-12 23:20:37 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
b.bv_page = page;
|
|
|
|
b.bv_offset = 0;
|
|
|
|
b.bv_len = bvec.bv_len;
|
2007-06-12 23:20:37 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
iov_iter_bvec(&i, ITER_BVEC, &b, 1, b.bv_len);
|
2017-05-27 11:16:51 +03:00
|
|
|
len = vfs_iter_read(lo->lo_backing_file, &i, &pos, 0);
|
2015-04-07 19:23:29 +03:00
|
|
|
if (len < 0) {
|
|
|
|
ret = len;
|
|
|
|
goto out_free_page;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
ret = lo_do_transfer(lo, READ, page, 0, bvec.bv_page,
|
|
|
|
bvec.bv_offset, len, offset >> 9);
|
|
|
|
if (ret)
|
|
|
|
goto out_free_page;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
flush_dcache_page(bvec.bv_page);
|
2012-02-09 01:07:19 +04:00
|
|
|
|
2015-04-07 19:23:29 +03:00
|
|
|
if (len != bvec.bv_len) {
|
2014-12-31 16:22:58 +03:00
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
__rq_for_each_bio(bio, rq)
|
|
|
|
zero_fill_bio(bio);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
2012-02-09 01:07:19 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
2015-04-07 19:23:29 +03:00
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
out_free_page:
|
|
|
|
__free_page(page);
|
|
|
|
return ret;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2014-12-31 16:22:59 +03:00
|
|
|
static int lo_discard(struct loop_device *lo, struct request *rq, loff_t pos)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We use punch hole to reclaim the free space used by the
|
|
|
|
* image a.k.a. discard. However we do not support discard if
|
|
|
|
* encryption is enabled, because it may give an attacker
|
|
|
|
* useful information.
|
|
|
|
*/
|
|
|
|
struct file *file = lo->lo_backing_file;
|
|
|
|
int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if ((!file->f_op->fallocate) || lo->lo_encrypt_key_size) {
|
|
|
|
ret = -EOPNOTSUPP;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = file->f_op->fallocate(file, mode, pos, blk_rq_bytes(rq));
|
|
|
|
if (unlikely(ret && ret != -EINVAL && ret != -EOPNOTSUPP))
|
|
|
|
ret = -EIO;
|
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int lo_req_flush(struct loop_device *lo, struct request *rq)
|
|
|
|
{
|
|
|
|
struct file *file = lo->lo_backing_file;
|
|
|
|
int ret = vfs_fsync(file, 0);
|
|
|
|
if (unlikely(ret && ret != -EINVAL))
|
|
|
|
ret = -EIO;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-04-20 17:03:02 +03:00
|
|
|
static void lo_complete_rq(struct request *rq)
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
{
|
2017-04-20 17:03:02 +03:00
|
|
|
struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
2017-04-20 17:03:02 +03:00
|
|
|
if (unlikely(req_op(cmd->rq) == REQ_OP_READ && cmd->use_aio &&
|
|
|
|
cmd->ret >= 0 && cmd->ret < blk_rq_bytes(cmd->rq))) {
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
struct bio *bio = cmd->rq->bio;
|
|
|
|
|
2017-04-20 17:03:02 +03:00
|
|
|
bio_advance(bio, cmd->ret);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
zero_fill_bio(bio);
|
|
|
|
}
|
2017-04-20 17:03:02 +03:00
|
|
|
|
2017-06-03 10:38:04 +03:00
|
|
|
blk_mq_end_request(rq, cmd->ret < 0 ? BLK_STS_IOERR : BLK_STS_OK);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
}
|
|
|
|
|
2017-09-01 21:15:17 +03:00
|
|
|
static void lo_rw_aio_do_completion(struct loop_cmd *cmd)
|
|
|
|
{
|
|
|
|
if (!atomic_dec_and_test(&cmd->ref))
|
|
|
|
return;
|
|
|
|
kfree(cmd->bvec);
|
|
|
|
cmd->bvec = NULL;
|
|
|
|
blk_mq_complete_request(cmd->rq);
|
|
|
|
}
|
|
|
|
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
static void lo_rw_aio_complete(struct kiocb *iocb, long ret, long ret2)
|
|
|
|
{
|
|
|
|
struct loop_cmd *cmd = container_of(iocb, struct loop_cmd, iocb);
|
|
|
|
|
2017-09-25 22:07:22 +03:00
|
|
|
if (cmd->css)
|
|
|
|
css_put(cmd->css);
|
2017-04-20 17:03:02 +03:00
|
|
|
cmd->ret = ret;
|
2017-09-01 21:15:17 +03:00
|
|
|
lo_rw_aio_do_completion(cmd);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
|
|
|
|
loff_t pos, bool rw)
|
|
|
|
{
|
|
|
|
struct iov_iter iter;
|
|
|
|
struct bio_vec *bvec;
|
2017-09-01 08:09:46 +03:00
|
|
|
struct request *rq = cmd->rq;
|
|
|
|
struct bio *bio = rq->bio;
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
struct file *file = lo->lo_backing_file;
|
2017-09-01 08:09:46 +03:00
|
|
|
unsigned int offset;
|
|
|
|
int segments = 0;
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
int ret;
|
|
|
|
|
2017-09-01 08:09:46 +03:00
|
|
|
if (rq->bio != rq->biotail) {
|
|
|
|
struct req_iterator iter;
|
|
|
|
struct bio_vec tmp;
|
|
|
|
|
|
|
|
__rq_for_each_bio(bio, rq)
|
|
|
|
segments += bio_segments(bio);
|
|
|
|
bvec = kmalloc(sizeof(struct bio_vec) * segments, GFP_NOIO);
|
|
|
|
if (!bvec)
|
|
|
|
return -EIO;
|
|
|
|
cmd->bvec = bvec;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The bios of the request may be started from the middle of
|
|
|
|
* the 'bvec' because of bio splitting, so we can't directly
|
|
|
|
* copy bio->bi_iov_vec to new bvec. The rq_for_each_segment
|
|
|
|
* API will take care of all details for us.
|
|
|
|
*/
|
|
|
|
rq_for_each_segment(tmp, rq, iter) {
|
|
|
|
*bvec = tmp;
|
|
|
|
bvec++;
|
|
|
|
}
|
|
|
|
bvec = cmd->bvec;
|
|
|
|
offset = 0;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Same here, this bio may be started from the middle of the
|
|
|
|
* 'bvec' because of bio splitting, so offset from the bvec
|
|
|
|
* must be passed to iov iterator
|
|
|
|
*/
|
|
|
|
offset = bio->bi_iter.bi_bvec_done;
|
|
|
|
bvec = __bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter);
|
|
|
|
segments = bio_segments(bio);
|
|
|
|
}
|
2017-09-01 21:15:17 +03:00
|
|
|
atomic_set(&cmd->ref, 2);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
|
|
|
iov_iter_bvec(&iter, ITER_BVEC | rw, bvec,
|
2017-09-01 08:09:46 +03:00
|
|
|
segments, blk_rq_bytes(rq));
|
|
|
|
iter.iov_offset = offset;
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
|
|
|
cmd->iocb.ki_pos = pos;
|
|
|
|
cmd->iocb.ki_filp = file;
|
|
|
|
cmd->iocb.ki_complete = lo_rw_aio_complete;
|
|
|
|
cmd->iocb.ki_flags = IOCB_DIRECT;
|
2017-09-25 22:07:22 +03:00
|
|
|
if (cmd->css)
|
|
|
|
kthread_associate_blkcg(cmd->css);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
|
|
|
if (rw == WRITE)
|
2017-02-20 18:51:23 +03:00
|
|
|
ret = call_write_iter(file, &cmd->iocb, &iter);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
else
|
2017-02-20 18:51:23 +03:00
|
|
|
ret = call_read_iter(file, &cmd->iocb, &iter);
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
2017-09-01 21:15:17 +03:00
|
|
|
lo_rw_aio_do_completion(cmd);
|
2017-09-25 22:07:22 +03:00
|
|
|
kthread_associate_blkcg(NULL);
|
2017-09-01 21:15:17 +03:00
|
|
|
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
if (ret != -EIOCBQUEUED)
|
|
|
|
cmd->iocb.ki_complete(&cmd->iocb, ret, 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-04 17:10:01 +03:00
|
|
|
static int do_req_filebacked(struct loop_device *lo, struct request *rq)
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
{
|
|
|
|
struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
|
2016-08-04 17:10:01 +03:00
|
|
|
loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset;
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* lo_write_simple and lo_read_simple should have been covered
|
|
|
|
* by io submit style function like lo_rw_aio(), one blocker
|
|
|
|
* is that lo_read_simple() need to call flush_dcache_page after
|
|
|
|
* the page is written from kernel, and it isn't easy to handle
|
|
|
|
* this in io submit style function which submits all segments
|
|
|
|
* of the req at one time. And direct read IO doesn't need to
|
|
|
|
* run flush_dcache_page().
|
|
|
|
*/
|
2016-08-04 17:10:01 +03:00
|
|
|
switch (req_op(rq)) {
|
|
|
|
case REQ_OP_FLUSH:
|
|
|
|
return lo_req_flush(lo, rq);
|
|
|
|
case REQ_OP_DISCARD:
|
2017-04-05 20:21:15 +03:00
|
|
|
case REQ_OP_WRITE_ZEROES:
|
2016-08-04 17:10:01 +03:00
|
|
|
return lo_discard(lo, rq, pos);
|
|
|
|
case REQ_OP_WRITE:
|
|
|
|
if (lo->transfer)
|
|
|
|
return lo_write_transfer(lo, rq, pos);
|
|
|
|
else if (cmd->use_aio)
|
|
|
|
return lo_rw_aio(lo, cmd, pos, WRITE);
|
2014-12-31 16:23:00 +03:00
|
|
|
else
|
2016-08-04 17:10:01 +03:00
|
|
|
return lo_write_simple(lo, rq, pos);
|
|
|
|
case REQ_OP_READ:
|
2015-04-07 19:23:29 +03:00
|
|
|
if (lo->transfer)
|
2016-08-04 17:10:01 +03:00
|
|
|
return lo_read_transfer(lo, rq, pos);
|
|
|
|
else if (cmd->use_aio)
|
|
|
|
return lo_rw_aio(lo, cmd, pos, READ);
|
2015-04-07 19:23:29 +03:00
|
|
|
else
|
2016-08-04 17:10:01 +03:00
|
|
|
return lo_read_simple(lo, rq, pos);
|
|
|
|
default:
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return -EIO;
|
|
|
|
break;
|
2015-04-07 19:23:29 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:49 +03:00
|
|
|
static inline void loop_update_dio(struct loop_device *lo)
|
|
|
|
{
|
|
|
|
__loop_update_dio(lo, io_is_direct(lo->lo_backing_file) |
|
|
|
|
lo->use_dio);
|
|
|
|
}
|
|
|
|
|
2015-05-06 07:26:24 +03:00
|
|
|
static void loop_reread_partitions(struct loop_device *lo,
|
|
|
|
struct block_device *bdev)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* bd_mutex has been held already in release path, so don't
|
|
|
|
* acquire it if this function is called in such case.
|
|
|
|
*
|
|
|
|
* If the reread partition isn't from release path, lo_refcnt
|
|
|
|
* must be at least one and it can only become zero when the
|
|
|
|
* current holder is released.
|
|
|
|
*/
|
|
|
|
if (!atomic_read(&lo->lo_refcnt))
|
|
|
|
rc = __blkdev_reread_part(bdev);
|
|
|
|
else
|
|
|
|
rc = blkdev_reread_part(bdev);
|
|
|
|
if (rc)
|
|
|
|
pr_warn("%s: partition scan of loop%d (%s) failed (rc=%d)\n",
|
|
|
|
__func__, lo->lo_number, lo->lo_file_name, rc);
|
|
|
|
}
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* loop_change_fd switched the backing store of a loopback device to
|
|
|
|
* a new file. This is useful for operating system installers to free up
|
|
|
|
* the original file and in High Availability environments to switch to
|
|
|
|
* an alternative location for the content in case of server meltdown.
|
|
|
|
* This can only work if the loop device is used read-only, and if the
|
|
|
|
* new backing store is the same size and type as the old backing store.
|
|
|
|
*/
|
2008-03-02 17:29:48 +03:00
|
|
|
static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,
|
|
|
|
unsigned int arg)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct file *file, *old_file;
|
|
|
|
struct inode *inode;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = -ENXIO;
|
|
|
|
if (lo->lo_state != Lo_bound)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* the loop device has to be read-only */
|
|
|
|
error = -EINVAL;
|
|
|
|
if (!(lo->lo_flags & LO_FLAGS_READ_ONLY))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
error = -EBADF;
|
|
|
|
file = fget(arg);
|
|
|
|
if (!file)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
inode = file->f_mapping->host;
|
|
|
|
old_file = lo->lo_backing_file;
|
|
|
|
|
|
|
|
error = -EINVAL;
|
|
|
|
|
|
|
|
if (!S_ISREG(inode->i_mode) && !S_ISBLK(inode->i_mode))
|
|
|
|
goto out_putf;
|
|
|
|
|
|
|
|
/* size of the new backing store needs to be the same */
|
|
|
|
if (get_loop_size(lo, file) != get_loop_size(lo, old_file))
|
|
|
|
goto out_putf;
|
|
|
|
|
|
|
|
/* and ... switch */
|
2017-08-24 10:03:44 +03:00
|
|
|
blk_mq_freeze_queue(lo->lo_queue);
|
|
|
|
mapping_set_gfp_mask(old_file->f_mapping, lo->old_gfp_mask);
|
|
|
|
lo->lo_backing_file = file;
|
|
|
|
lo->old_gfp_mask = mapping_gfp_mask(file->f_mapping);
|
|
|
|
mapping_set_gfp_mask(file->f_mapping,
|
|
|
|
lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
|
|
|
|
loop_update_dio(lo);
|
|
|
|
blk_mq_unfreeze_queue(lo->lo_queue);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
fput(old_file);
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
if (lo->lo_flags & LO_FLAGS_PARTSCAN)
|
2015-05-06 07:26:24 +03:00
|
|
|
loop_reread_partitions(lo, bdev);
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_putf:
|
|
|
|
fput(file);
|
|
|
|
out:
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int is_loop_device(struct file *file)
|
|
|
|
{
|
|
|
|
struct inode *i = file->f_mapping->host;
|
|
|
|
|
|
|
|
return i && S_ISBLK(i->i_mode) && MAJOR(i->i_rdev) == LOOP_MAJOR;
|
|
|
|
}
|
|
|
|
|
2010-08-23 17:16:00 +04:00
|
|
|
/* loop sysfs attributes */
|
|
|
|
|
|
|
|
static ssize_t loop_attr_show(struct device *dev, char *page,
|
|
|
|
ssize_t (*callback)(struct loop_device *, char *))
|
|
|
|
{
|
2011-08-01 00:08:04 +04:00
|
|
|
struct gendisk *disk = dev_to_disk(dev);
|
|
|
|
struct loop_device *lo = disk->private_data;
|
2010-08-23 17:16:00 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
return callback(lo, page);
|
2010-08-23 17:16:00 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
#define LOOP_ATTR_RO(_name) \
|
|
|
|
static ssize_t loop_attr_##_name##_show(struct loop_device *, char *); \
|
|
|
|
static ssize_t loop_attr_do_show_##_name(struct device *d, \
|
|
|
|
struct device_attribute *attr, char *b) \
|
|
|
|
{ \
|
|
|
|
return loop_attr_show(d, b, loop_attr_##_name##_show); \
|
|
|
|
} \
|
|
|
|
static struct device_attribute loop_attr_##_name = \
|
|
|
|
__ATTR(_name, S_IRUGO, loop_attr_do_show_##_name, NULL);
|
|
|
|
|
|
|
|
static ssize_t loop_attr_backing_file_show(struct loop_device *lo, char *buf)
|
|
|
|
{
|
|
|
|
ssize_t ret;
|
|
|
|
char *p = NULL;
|
|
|
|
|
2011-08-01 00:21:35 +04:00
|
|
|
spin_lock_irq(&lo->lo_lock);
|
2010-08-23 17:16:00 +04:00
|
|
|
if (lo->lo_backing_file)
|
2015-06-19 11:29:13 +03:00
|
|
|
p = file_path(lo->lo_backing_file, buf, PAGE_SIZE - 1);
|
2011-08-01 00:21:35 +04:00
|
|
|
spin_unlock_irq(&lo->lo_lock);
|
2010-08-23 17:16:00 +04:00
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(p))
|
|
|
|
ret = PTR_ERR(p);
|
|
|
|
else {
|
|
|
|
ret = strlen(p);
|
|
|
|
memmove(buf, p, ret);
|
|
|
|
buf[ret++] = '\n';
|
|
|
|
buf[ret] = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t loop_attr_offset_show(struct loop_device *lo, char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%llu\n", (unsigned long long)lo->lo_offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t loop_attr_sizelimit_show(struct loop_device *lo, char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%llu\n", (unsigned long long)lo->lo_sizelimit);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t loop_attr_autoclear_show(struct loop_device *lo, char *buf)
|
|
|
|
{
|
|
|
|
int autoclear = (lo->lo_flags & LO_FLAGS_AUTOCLEAR);
|
|
|
|
|
|
|
|
return sprintf(buf, "%s\n", autoclear ? "1" : "0");
|
|
|
|
}
|
|
|
|
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
static ssize_t loop_attr_partscan_show(struct loop_device *lo, char *buf)
|
|
|
|
{
|
|
|
|
int partscan = (lo->lo_flags & LO_FLAGS_PARTSCAN);
|
|
|
|
|
|
|
|
return sprintf(buf, "%s\n", partscan ? "1" : "0");
|
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:49 +03:00
|
|
|
static ssize_t loop_attr_dio_show(struct loop_device *lo, char *buf)
|
|
|
|
{
|
|
|
|
int dio = (lo->lo_flags & LO_FLAGS_DIRECT_IO);
|
|
|
|
|
|
|
|
return sprintf(buf, "%s\n", dio ? "1" : "0");
|
|
|
|
}
|
|
|
|
|
2010-08-23 17:16:00 +04:00
|
|
|
LOOP_ATTR_RO(backing_file);
|
|
|
|
LOOP_ATTR_RO(offset);
|
|
|
|
LOOP_ATTR_RO(sizelimit);
|
|
|
|
LOOP_ATTR_RO(autoclear);
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
LOOP_ATTR_RO(partscan);
|
2015-08-17 05:31:49 +03:00
|
|
|
LOOP_ATTR_RO(dio);
|
2010-08-23 17:16:00 +04:00
|
|
|
|
|
|
|
static struct attribute *loop_attrs[] = {
|
|
|
|
&loop_attr_backing_file.attr,
|
|
|
|
&loop_attr_offset.attr,
|
|
|
|
&loop_attr_sizelimit.attr,
|
|
|
|
&loop_attr_autoclear.attr,
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
&loop_attr_partscan.attr,
|
2015-08-17 05:31:49 +03:00
|
|
|
&loop_attr_dio.attr,
|
2010-08-23 17:16:00 +04:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group loop_attribute_group = {
|
|
|
|
.name = "loop",
|
|
|
|
.attrs= loop_attrs,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int loop_sysfs_init(struct loop_device *lo)
|
|
|
|
{
|
|
|
|
return sysfs_create_group(&disk_to_dev(lo->lo_disk)->kobj,
|
|
|
|
&loop_attribute_group);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void loop_sysfs_exit(struct loop_device *lo)
|
|
|
|
{
|
|
|
|
sysfs_remove_group(&disk_to_dev(lo->lo_disk)->kobj,
|
|
|
|
&loop_attribute_group);
|
|
|
|
}
|
|
|
|
|
2011-08-19 16:50:46 +04:00
|
|
|
static void loop_config_discard(struct loop_device *lo)
|
|
|
|
{
|
|
|
|
struct file *file = lo->lo_backing_file;
|
|
|
|
struct inode *inode = file->f_mapping->host;
|
|
|
|
struct request_queue *q = lo->lo_queue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We use punch hole to reclaim the free space used by the
|
2014-01-22 02:39:24 +04:00
|
|
|
* image a.k.a. discard. However we do not support discard if
|
2011-08-19 16:50:46 +04:00
|
|
|
* encryption is enabled, because it may give an attacker
|
|
|
|
* useful information.
|
|
|
|
*/
|
|
|
|
if ((!file->f_op->fallocate) ||
|
|
|
|
lo->lo_encrypt_key_size) {
|
|
|
|
q->limits.discard_granularity = 0;
|
|
|
|
q->limits.discard_alignment = 0;
|
2015-07-14 17:15:12 +03:00
|
|
|
blk_queue_max_discard_sectors(q, 0);
|
2017-04-05 20:21:15 +03:00
|
|
|
blk_queue_max_write_zeroes_sectors(q, 0);
|
2011-08-19 16:50:46 +04:00
|
|
|
queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, q);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
q->limits.discard_granularity = inode->i_sb->s_blocksize;
|
2011-12-02 17:47:03 +04:00
|
|
|
q->limits.discard_alignment = 0;
|
2017-06-08 14:46:45 +03:00
|
|
|
|
2017-08-24 00:54:59 +03:00
|
|
|
blk_queue_max_discard_sectors(q, UINT_MAX >> 9);
|
|
|
|
blk_queue_max_write_zeroes_sectors(q, UINT_MAX >> 9);
|
2011-08-19 16:50:46 +04:00
|
|
|
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
|
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:48 +03:00
|
|
|
static void loop_unprepare_queue(struct loop_device *lo)
|
|
|
|
{
|
2016-10-11 23:55:20 +03:00
|
|
|
kthread_flush_worker(&lo->worker);
|
2015-08-17 05:31:48 +03:00
|
|
|
kthread_stop(lo->worker_task);
|
|
|
|
}
|
|
|
|
|
loop: Add PF_LESS_THROTTLE to block/loop device thread.
When a filesystem is mounted from a loop device, writes are
throttled by balance_dirty_pages() twice: once when writing
to the filesystem and once when the loop_handle_cmd() writes
to the backing file. This double-throttling can trigger
positive feedback loops that create significant delays. The
throttling at the lower level is seen by the upper level as
a slow device, so it throttles extra hard.
The PF_LESS_THROTTLE flag was created to handle exactly this
circumstance, though with an NFS filesystem mounted from a
local NFS server. It reduces the throttling on the lower
layer so that it can proceed largely unthrottled.
To demonstrate this, create a filesystem on a loop device
and write (e.g. with dd) several large files which combine
to consume significantly more than the limit set by
/proc/sys/vm/dirty_ratio or dirty_bytes. Measure the total
time taken.
When I do this directly on a device (no loop device) the
total time for several runs (mkfs, mount, write 200 files,
umount) is fairly stable: 28-35 seconds.
When I do this over a loop device the times are much worse
and less stable. 52-460 seconds. Half below 100seconds,
half above.
When I apply this patch, the times become stable again,
though not as fast as the no-loop-back case: 53-72 seconds.
There may be room for further improvement as the total overhead still
seems too high, but this is a big improvement.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-16 08:02:09 +03:00
|
|
|
static int loop_kthread_worker_fn(void *worker_ptr)
|
|
|
|
{
|
|
|
|
current->flags |= PF_LESS_THROTTLE;
|
|
|
|
return kthread_worker_fn(worker_ptr);
|
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:48 +03:00
|
|
|
static int loop_prepare_queue(struct loop_device *lo)
|
|
|
|
{
|
2016-10-11 23:55:20 +03:00
|
|
|
kthread_init_worker(&lo->worker);
|
loop: Add PF_LESS_THROTTLE to block/loop device thread.
When a filesystem is mounted from a loop device, writes are
throttled by balance_dirty_pages() twice: once when writing
to the filesystem and once when the loop_handle_cmd() writes
to the backing file. This double-throttling can trigger
positive feedback loops that create significant delays. The
throttling at the lower level is seen by the upper level as
a slow device, so it throttles extra hard.
The PF_LESS_THROTTLE flag was created to handle exactly this
circumstance, though with an NFS filesystem mounted from a
local NFS server. It reduces the throttling on the lower
layer so that it can proceed largely unthrottled.
To demonstrate this, create a filesystem on a loop device
and write (e.g. with dd) several large files which combine
to consume significantly more than the limit set by
/proc/sys/vm/dirty_ratio or dirty_bytes. Measure the total
time taken.
When I do this directly on a device (no loop device) the
total time for several runs (mkfs, mount, write 200 files,
umount) is fairly stable: 28-35 seconds.
When I do this over a loop device the times are much worse
and less stable. 52-460 seconds. Half below 100seconds,
half above.
When I apply this patch, the times become stable again,
though not as fast as the no-loop-back case: 53-72 seconds.
There may be room for further improvement as the total overhead still
seems too high, but this is a big improvement.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-06-16 08:02:09 +03:00
|
|
|
lo->worker_task = kthread_run(loop_kthread_worker_fn,
|
2015-08-17 05:31:48 +03:00
|
|
|
&lo->worker, "loop%d", lo->lo_number);
|
|
|
|
if (IS_ERR(lo->worker_task))
|
|
|
|
return -ENOMEM;
|
|
|
|
set_user_nice(lo->worker_task, MIN_NICE);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-03-02 17:29:48 +03:00
|
|
|
static int loop_set_fd(struct loop_device *lo, fmode_t mode,
|
2005-04-17 02:20:36 +04:00
|
|
|
struct block_device *bdev, unsigned int arg)
|
|
|
|
{
|
|
|
|
struct file *file, *f;
|
|
|
|
struct inode *inode;
|
|
|
|
struct address_space *mapping;
|
|
|
|
int lo_flags = 0;
|
|
|
|
int error;
|
|
|
|
loff_t size;
|
|
|
|
|
|
|
|
/* This is safe, since we have a reference from open(). */
|
|
|
|
__module_get(THIS_MODULE);
|
|
|
|
|
|
|
|
error = -EBADF;
|
|
|
|
file = fget(arg);
|
|
|
|
if (!file)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
error = -EBUSY;
|
|
|
|
if (lo->lo_state != Lo_unbound)
|
|
|
|
goto out_putf;
|
|
|
|
|
|
|
|
/* Avoid recursion */
|
|
|
|
f = file;
|
|
|
|
while (is_loop_device(f)) {
|
|
|
|
struct loop_device *l;
|
|
|
|
|
2008-03-02 17:29:48 +03:00
|
|
|
if (f->f_mapping->host->i_bdev == bdev)
|
2005-04-17 02:20:36 +04:00
|
|
|
goto out_putf;
|
|
|
|
|
|
|
|
l = f->f_mapping->host->i_bdev->bd_disk->private_data;
|
|
|
|
if (l->lo_state == Lo_unbound) {
|
|
|
|
error = -EINVAL;
|
|
|
|
goto out_putf;
|
|
|
|
}
|
|
|
|
f = l->lo_backing_file;
|
|
|
|
}
|
|
|
|
|
|
|
|
mapping = file->f_mapping;
|
|
|
|
inode = mapping->host;
|
|
|
|
|
|
|
|
error = -EINVAL;
|
2011-10-17 14:57:20 +04:00
|
|
|
if (!S_ISREG(inode->i_mode) && !S_ISBLK(inode->i_mode))
|
|
|
|
goto out_putf;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-10-17 14:57:20 +04:00
|
|
|
if (!(file->f_mode & FMODE_WRITE) || !(mode & FMODE_WRITE) ||
|
2015-04-03 22:21:59 +03:00
|
|
|
!file->f_op->write_iter)
|
2011-10-17 14:57:20 +04:00
|
|
|
lo_flags |= LO_FLAGS_READ_ONLY;
|
2006-09-27 12:50:49 +04:00
|
|
|
|
2011-10-17 14:57:20 +04:00
|
|
|
error = -EFBIG;
|
2005-04-17 02:20:36 +04:00
|
|
|
size = get_loop_size(lo, file);
|
2011-10-17 14:57:20 +04:00
|
|
|
if ((loff_t)(sector_t)size != size)
|
2005-04-17 02:20:36 +04:00
|
|
|
goto out_putf;
|
2015-08-17 05:31:48 +03:00
|
|
|
error = loop_prepare_queue(lo);
|
|
|
|
if (error)
|
2015-05-05 14:49:54 +03:00
|
|
|
goto out_putf;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-10-17 14:57:20 +04:00
|
|
|
error = 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
set_device_ro(bdev, (lo_flags & LO_FLAGS_READ_ONLY) != 0);
|
|
|
|
|
2015-08-17 05:31:49 +03:00
|
|
|
lo->use_dio = false;
|
2005-04-17 02:20:36 +04:00
|
|
|
lo->lo_device = bdev;
|
|
|
|
lo->lo_flags = lo_flags;
|
|
|
|
lo->lo_backing_file = file;
|
2015-04-07 19:23:29 +03:00
|
|
|
lo->transfer = NULL;
|
2005-04-17 02:20:36 +04:00
|
|
|
lo->ioctl = NULL;
|
|
|
|
lo->lo_sizelimit = 0;
|
|
|
|
lo->old_gfp_mask = mapping_gfp_mask(mapping);
|
|
|
|
mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS));
|
|
|
|
|
2009-03-24 14:29:54 +03:00
|
|
|
if (!(lo_flags & LO_FLAGS_READ_ONLY) && file->f_op->fsync)
|
2016-03-30 19:09:35 +03:00
|
|
|
blk_queue_write_cache(lo->lo_queue, true, false);
|
2009-03-24 14:29:54 +03:00
|
|
|
|
2015-08-17 05:31:49 +03:00
|
|
|
loop_update_dio(lo);
|
2007-05-08 11:28:20 +04:00
|
|
|
set_capacity(lo->lo_disk, size);
|
2005-04-17 02:20:36 +04:00
|
|
|
bd_set_size(bdev, size << 9);
|
2010-08-23 17:16:00 +04:00
|
|
|
loop_sysfs_init(lo);
|
2010-05-03 16:08:59 +04:00
|
|
|
/* let user-space know about the new size */
|
|
|
|
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2017-08-24 10:03:41 +03:00
|
|
|
set_blocksize(bdev, S_ISBLK(inode->i_mode) ?
|
|
|
|
block_size(inode->i_bdev) : PAGE_SIZE);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2006-09-29 12:59:11 +04:00
|
|
|
lo->lo_state = Lo_bound;
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
if (part_shift)
|
|
|
|
lo->lo_flags |= LO_FLAGS_PARTSCAN;
|
|
|
|
if (lo->lo_flags & LO_FLAGS_PARTSCAN)
|
2015-05-06 07:26:24 +03:00
|
|
|
loop_reread_partitions(lo, bdev);
|
2013-04-01 20:47:56 +04:00
|
|
|
|
|
|
|
/* Grab the block_device to prevent its destruction after we
|
|
|
|
* put /dev/loopXX inode. Later in loop_clr_fd() we bdput(bdev).
|
|
|
|
*/
|
|
|
|
bdgrab(bdev);
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_putf:
|
|
|
|
fput(file);
|
|
|
|
out:
|
|
|
|
/* This is safe: open() is still holding a reference. */
|
|
|
|
module_put(THIS_MODULE);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_release_xfer(struct loop_device *lo)
|
|
|
|
{
|
|
|
|
int err = 0;
|
|
|
|
struct loop_func_table *xfer = lo->lo_encryption;
|
|
|
|
|
|
|
|
if (xfer) {
|
|
|
|
if (xfer->release)
|
|
|
|
err = xfer->release(lo);
|
|
|
|
lo->transfer = NULL;
|
|
|
|
lo->lo_encryption = NULL;
|
|
|
|
module_put(xfer->owner);
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_init_xfer(struct loop_device *lo, struct loop_func_table *xfer,
|
|
|
|
const struct loop_info64 *i)
|
|
|
|
{
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (xfer) {
|
|
|
|
struct module *owner = xfer->owner;
|
|
|
|
|
|
|
|
if (!try_module_get(owner))
|
|
|
|
return -EINVAL;
|
|
|
|
if (xfer->init)
|
|
|
|
err = xfer->init(lo, i);
|
|
|
|
if (err)
|
|
|
|
module_put(owner);
|
|
|
|
else
|
|
|
|
lo->lo_encryption = xfer;
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2011-09-21 12:02:13 +04:00
|
|
|
static int loop_clr_fd(struct loop_device *lo)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
|
|
|
struct file *filp = lo->lo_backing_file;
|
2005-10-21 11:22:34 +04:00
|
|
|
gfp_t gfp = lo->old_gfp_mask;
|
2011-09-21 12:02:13 +04:00
|
|
|
struct block_device *bdev = lo->lo_device;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (lo->lo_state != Lo_bound)
|
|
|
|
return -ENXIO;
|
|
|
|
|
loop: Make explicit loop device destruction lazy
xfstests has always had random failures of tests due to loop devices
failing to be torn down and hence leaving filesytems that cannot be
unmounted. This causes test runs to immediately stop.
Over the past 6 or 7 years we've added hacks like explicit unmount
-d commands for loop mounts, losetup -d after unmount -d fails, etc,
but still the problems persist. Recently, the frequency of loop
related failures increased again to the point that xfstests 259 will
reliably fail with a stray loop device that was not torn down.
That is despite the fact the test is above as simple as it gets -
loop 5 or 6 times running mkfs.xfs with different paramters:
lofile=$(losetup -f)
losetup $lofile "$testfile"
"$MKFS_XFS_PROG" -b size=512 $lofile >/dev/null || echo "mkfs failed!"
sync
losetup -d $lofile
And losteup -d $lofile is failing with EBUSY on 1-3 of these loops
every time the test is run.
Turns out that blkid is running simultaneously with losetup -d, and
so it sees an elevated reference count and returns EBUSY. But why
is blkid running? It's obvious, isn't it? udev has decided to try
and find out what is on the block device as a result of a creation
notification. And it is racing with mkfs, so might still be scanning
the device when mkfs finishes and we try to tear it down.
So, make losetup -d force autoremove behaviour. That is, when the
last reference goes away, tear down the device. xfstests wants it
*gone*, not causing random teardown failures when we know that all
the operations the tests have specifically run on the device have
completed and are no longer referencing the loop device.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-09-28 12:42:23 +04:00
|
|
|
/*
|
|
|
|
* If we've explicitly asked to tear down the loop device,
|
|
|
|
* and it has an elevated reference count, set it for auto-teardown when
|
|
|
|
* the last reference goes away. This stops $!~#$@ udev from
|
|
|
|
* preventing teardown because it decided that it needs to run blkid on
|
|
|
|
* the loopback device whenever they appear. xfstests is notorious for
|
|
|
|
* failing tests because blkid via udev races with a losetup
|
|
|
|
* <dev>/do something like mkfs/losetup -d <dev> causing the losetup -d
|
|
|
|
* command to fail with EBUSY.
|
|
|
|
*/
|
2015-05-06 07:26:23 +03:00
|
|
|
if (atomic_read(&lo->lo_refcnt) > 1) {
|
loop: Make explicit loop device destruction lazy
xfstests has always had random failures of tests due to loop devices
failing to be torn down and hence leaving filesytems that cannot be
unmounted. This causes test runs to immediately stop.
Over the past 6 or 7 years we've added hacks like explicit unmount
-d commands for loop mounts, losetup -d after unmount -d fails, etc,
but still the problems persist. Recently, the frequency of loop
related failures increased again to the point that xfstests 259 will
reliably fail with a stray loop device that was not torn down.
That is despite the fact the test is above as simple as it gets -
loop 5 or 6 times running mkfs.xfs with different paramters:
lofile=$(losetup -f)
losetup $lofile "$testfile"
"$MKFS_XFS_PROG" -b size=512 $lofile >/dev/null || echo "mkfs failed!"
sync
losetup -d $lofile
And losteup -d $lofile is failing with EBUSY on 1-3 of these loops
every time the test is run.
Turns out that blkid is running simultaneously with losetup -d, and
so it sees an elevated reference count and returns EBUSY. But why
is blkid running? It's obvious, isn't it? udev has decided to try
and find out what is on the block device as a result of a creation
notification. And it is racing with mkfs, so might still be scanning
the device when mkfs finishes and we try to tear it down.
So, make losetup -d force autoremove behaviour. That is, when the
last reference goes away, tear down the device. xfstests wants it
*gone*, not causing random teardown failures when we know that all
the operations the tests have specifically run on the device have
completed and are no longer referencing the loop device.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-09-28 12:42:23 +04:00
|
|
|
lo->lo_flags |= LO_FLAGS_AUTOCLEAR;
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (filp == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2015-05-06 07:26:23 +03:00
|
|
|
/* freeze request queue during the transition */
|
|
|
|
blk_mq_freeze_queue(lo->lo_queue);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
spin_lock_irq(&lo->lo_lock);
|
|
|
|
lo->lo_state = Lo_rundown;
|
|
|
|
lo->lo_backing_file = NULL;
|
2011-08-01 00:21:35 +04:00
|
|
|
spin_unlock_irq(&lo->lo_lock);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
loop_release_xfer(lo);
|
|
|
|
lo->transfer = NULL;
|
|
|
|
lo->ioctl = NULL;
|
|
|
|
lo->lo_device = NULL;
|
|
|
|
lo->lo_encryption = NULL;
|
|
|
|
lo->lo_offset = 0;
|
|
|
|
lo->lo_sizelimit = 0;
|
|
|
|
lo->lo_encrypt_key_size = 0;
|
|
|
|
memset(lo->lo_encrypt_key, 0, LO_KEY_SIZE);
|
|
|
|
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
|
|
|
|
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
|
2017-08-24 10:03:43 +03:00
|
|
|
blk_queue_logical_block_size(lo->lo_queue, 512);
|
2017-09-06 00:24:47 +03:00
|
|
|
blk_queue_physical_block_size(lo->lo_queue, 512);
|
|
|
|
blk_queue_io_min(lo->lo_queue, 512);
|
2013-04-01 20:47:56 +04:00
|
|
|
if (bdev) {
|
|
|
|
bdput(bdev);
|
2008-03-02 17:29:48 +03:00
|
|
|
invalidate_bdev(bdev);
|
2013-04-01 20:47:56 +04:00
|
|
|
}
|
2007-05-08 11:28:20 +04:00
|
|
|
set_capacity(lo->lo_disk, 0);
|
2010-10-28 05:51:30 +04:00
|
|
|
loop_sysfs_exit(lo);
|
2010-05-03 16:08:59 +04:00
|
|
|
if (bdev) {
|
2008-03-02 17:29:48 +03:00
|
|
|
bd_set_size(bdev, 0);
|
2010-05-03 16:08:59 +04:00
|
|
|
/* let user-space know about this change */
|
|
|
|
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
mapping_set_gfp_mask(filp->f_mapping, gfp);
|
|
|
|
lo->lo_state = Lo_unbound;
|
|
|
|
/* This is safe: open() is still holding a reference. */
|
|
|
|
module_put(THIS_MODULE);
|
2015-05-06 07:26:23 +03:00
|
|
|
blk_mq_unfreeze_queue(lo->lo_queue);
|
|
|
|
|
2013-04-08 12:12:11 +04:00
|
|
|
if (lo->lo_flags & LO_FLAGS_PARTSCAN && bdev)
|
2015-05-06 07:26:24 +03:00
|
|
|
loop_reread_partitions(lo, bdev);
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
lo->lo_flags = 0;
|
|
|
|
if (!part_shift)
|
|
|
|
lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
|
2015-08-17 05:31:48 +03:00
|
|
|
loop_unprepare_queue(lo);
|
loop: fix circular locking in loop_clr_fd()
With CONFIG_PROVE_LOCKING enabled
$ losetup /dev/loop0 file
$ losetup -o 32256 /dev/loop1 /dev/loop0
$ losetup -d /dev/loop1
$ losetup -d /dev/loop0
triggers a [ INFO: possible circular locking dependency detected ]
I think this warning is a false positive.
Open/close on a loop device acquires bd_mutex of the device before
acquiring lo_ctl_mutex of the same device. For ioctl(LOOP_CLR_FD) after
acquiring lo_ctl_mutex, fput on the backing_file might acquire the bd_mutex of
a device, if backing file is a device and this is the last reference to the
file being dropped . But it is guaranteed that it is impossible to have a
circular list of backing devices.(say loop2->loop1->loop0->loop2 is not
possible), which guarantees that this can never deadlock.
So this warning should be suppressed. It is very difficult to annotate lockdep
not to warn here in the correct way. A simple way to silence lockdep could be
to mark the lo_ctl_mutex in ioctl to be a sub class, but this might mask some
other real bugs.
@@ -1164,7 +1164,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode,
struct loop_device *lo = bdev->bd_disk->private_data;
int err;
- mutex_lock(&lo->lo_ctl_mutex);
+ mutex_lock_nested(&lo->lo_ctl_mutex, 1);
switch (cmd) {
case LOOP_SET_FD:
err = loop_set_fd(lo, mode, bdev, arg);
Or actually marking the bd_mutex after lo_ctl_mutex as a sub class could be
a better solution.
Luckily it is easy to avoid calling fput on backing file with lo_ctl_mutex
held, so no lockdep annotation is required.
If you do not like the special handling of the lo_ctl_mutex just for the
LOOP_CLR_FD ioctl in lo_ioctl(), the mutex handling could be moved inside
each of the individual ioctl handlers and I could send you another patch.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-03-24 14:33:41 +03:00
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
/*
|
|
|
|
* Need not hold lo_ctl_mutex to fput backing file.
|
|
|
|
* Calling fput holding lo_ctl_mutex triggers a circular
|
|
|
|
* lock dependency possibility warning as fput can take
|
|
|
|
* bd_mutex which is usually taken before lo_ctl_mutex.
|
|
|
|
*/
|
|
|
|
fput(filp);
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
struct loop_func_table *xfer;
|
2012-02-11 23:23:51 +04:00
|
|
|
kuid_t uid = current_uid();
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2008-11-14 02:38:41 +03:00
|
|
|
if (lo->lo_encrypt_key_size &&
|
2012-02-11 23:23:51 +04:00
|
|
|
!uid_eq(lo->lo_key_owner, uid) &&
|
2005-04-17 02:20:36 +04:00
|
|
|
!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
if (lo->lo_state != Lo_bound)
|
|
|
|
return -ENXIO;
|
|
|
|
if ((unsigned int) info->lo_encrypt_key_size > LO_KEY_SIZE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-02-11 06:40:45 +03:00
|
|
|
/* I/O need to be drained during transfer transition */
|
|
|
|
blk_mq_freeze_queue(lo->lo_queue);
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
err = loop_release_xfer(lo);
|
|
|
|
if (err)
|
2017-02-11 06:40:45 +03:00
|
|
|
goto exit;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (info->lo_encrypt_type) {
|
|
|
|
unsigned int type = info->lo_encrypt_type;
|
|
|
|
|
|
|
|
if (type >= MAX_LO_CRYPT)
|
|
|
|
return -EINVAL;
|
|
|
|
xfer = xfer_funcs[type];
|
|
|
|
if (xfer == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
} else
|
|
|
|
xfer = NULL;
|
|
|
|
|
|
|
|
err = loop_init_xfer(lo, xfer, info);
|
|
|
|
if (err)
|
2017-02-11 06:40:45 +03:00
|
|
|
goto exit;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
if (lo->lo_offset != info->lo_offset ||
|
2017-08-24 00:54:59 +03:00
|
|
|
lo->lo_sizelimit != info->lo_sizelimit) {
|
|
|
|
if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit)) {
|
2017-02-11 06:40:45 +03:00
|
|
|
err = -EFBIG;
|
|
|
|
goto exit;
|
|
|
|
}
|
2017-06-09 13:19:18 +03:00
|
|
|
}
|
2013-02-22 03:16:46 +04:00
|
|
|
|
2011-08-19 16:50:46 +04:00
|
|
|
loop_config_discard(lo);
|
2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
memcpy(lo->lo_file_name, info->lo_file_name, LO_NAME_SIZE);
|
|
|
|
memcpy(lo->lo_crypt_name, info->lo_crypt_name, LO_NAME_SIZE);
|
|
|
|
lo->lo_file_name[LO_NAME_SIZE-1] = 0;
|
|
|
|
lo->lo_crypt_name[LO_NAME_SIZE-1] = 0;
|
|
|
|
|
|
|
|
if (!xfer)
|
|
|
|
xfer = &none_funcs;
|
|
|
|
lo->transfer = xfer->transfer;
|
|
|
|
lo->ioctl = xfer->ioctl;
|
|
|
|
|
2008-02-06 12:36:27 +03:00
|
|
|
if ((lo->lo_flags & LO_FLAGS_AUTOCLEAR) !=
|
|
|
|
(info->lo_flags & LO_FLAGS_AUTOCLEAR))
|
|
|
|
lo->lo_flags ^= LO_FLAGS_AUTOCLEAR;
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
lo->lo_encrypt_key_size = info->lo_encrypt_key_size;
|
|
|
|
lo->lo_init[0] = info->lo_init[0];
|
|
|
|
lo->lo_init[1] = info->lo_init[1];
|
|
|
|
if (info->lo_encrypt_key_size) {
|
|
|
|
memcpy(lo->lo_encrypt_key, info->lo_encrypt_key,
|
|
|
|
info->lo_encrypt_key_size);
|
2008-11-14 02:38:41 +03:00
|
|
|
lo->lo_key_owner = uid;
|
2015-04-07 19:23:29 +03:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-08-17 05:31:49 +03:00
|
|
|
/* update dio if lo_offset or transfer is changed */
|
|
|
|
__loop_update_dio(lo, lo->use_dio);
|
|
|
|
|
2017-02-11 06:40:45 +03:00
|
|
|
exit:
|
|
|
|
blk_mq_unfreeze_queue(lo->lo_queue);
|
2017-03-01 21:42:38 +03:00
|
|
|
|
|
|
|
if (!err && (info->lo_flags & LO_FLAGS_PARTSCAN) &&
|
|
|
|
!(lo->lo_flags & LO_FLAGS_PARTSCAN)) {
|
|
|
|
lo->lo_flags |= LO_FLAGS_PARTSCAN;
|
|
|
|
lo->lo_disk->flags &= ~GENHD_FL_NO_PART_SCAN;
|
|
|
|
loop_reread_partitions(lo, lo->lo_device);
|
|
|
|
}
|
|
|
|
|
2017-02-11 06:40:45 +03:00
|
|
|
return err;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_get_status(struct loop_device *lo, struct loop_info64 *info)
|
|
|
|
{
|
|
|
|
struct file *file = lo->lo_backing_file;
|
|
|
|
struct kstat stat;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (lo->lo_state != Lo_bound)
|
|
|
|
return -ENXIO;
|
statx: Add a system call to make enhanced file info available
Add a system call to make extended file information available, including
file creation and some attribute flags where available through the
underlying filesystem.
The getattr inode operation is altered to take two additional arguments: a
u32 request_mask and an unsigned int flags that indicate the
synchronisation mode. This change is propagated to the vfs_getattr*()
function.
Functions like vfs_stat() are now inline wrappers around new functions
vfs_statx() and vfs_statx_fd() to reduce stack usage.
========
OVERVIEW
========
The idea was initially proposed as a set of xattrs that could be retrieved
with getxattr(), but the general preference proved to be for a new syscall
with an extended stat structure.
A number of requests were gathered for features to be included. The
following have been included:
(1) Make the fields a consistent size on all arches and make them large.
(2) Spare space, request flags and information flags are provided for
future expansion.
(3) Better support for the y2038 problem [Arnd Bergmann] (tv_sec is an
__s64).
(4) Creation time: The SMB protocol carries the creation time, which could
be exported by Samba, which will in turn help CIFS make use of
FS-Cache as that can be used for coherency data (stx_btime).
This is also specified in NFSv4 as a recommended attribute and could
be exported by NFSD [Steve French].
(5) Lightweight stat: Ask for just those details of interest, and allow a
netfs (such as NFS) to approximate anything not of interest, possibly
without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
Dilger] (AT_STATX_DONT_SYNC).
(6) Heavyweight stat: Force a netfs to go to the server, even if it thinks
its cached attributes are up to date [Trond Myklebust]
(AT_STATX_FORCE_SYNC).
And the following have been left out for future extension:
(7) Data version number: Could be used by userspace NFS servers [Aneesh
Kumar].
Can also be used to modify fill_post_wcc() in NFSD which retrieves
i_version directly, but has just called vfs_getattr(). It could get
it from the kstat struct if it used vfs_xgetattr() instead.
(There's disagreement on the exact semantics of a single field, since
not all filesystems do this the same way).
(8) BSD stat compatibility: Including more fields from the BSD stat such
as creation time (st_btime) and inode generation number (st_gen)
[Jeremy Allison, Bernd Schubert].
(9) Inode generation number: Useful for FUSE and userspace NFS servers
[Bernd Schubert].
(This was asked for but later deemed unnecessary with the
open-by-handle capability available and caused disagreement as to
whether it's a security hole or not).
(10) Extra coherency data may be useful in making backups [Andreas Dilger].
(No particular data were offered, but things like last backup
timestamp, the data version number and the DOS archive bit would come
into this category).
(11) Allow the filesystem to indicate what it can/cannot provide: A
filesystem can now say it doesn't support a standard stat feature if
that isn't available, so if, for instance, inode numbers or UIDs don't
exist or are fabricated locally...
(This requires a separate system call - I have an fsinfo() call idea
for this).
(12) Store a 16-byte volume ID in the superblock that can be returned in
struct xstat [Steve French].
(Deferred to fsinfo).
(13) Include granularity fields in the time data to indicate the
granularity of each of the times (NFSv4 time_delta) [Steve French].
(Deferred to fsinfo).
(14) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.
Note that the Linux IOC flags are a mess and filesystems such as Ext4
define flags that aren't in linux/fs.h, so translation in the kernel
may be a necessity (or, possibly, we provide the filesystem type too).
(Some attributes are made available in stx_attributes, but the general
feeling was that the IOC flags were to ext[234]-specific and shouldn't
be exposed through statx this way).
(15) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
Michael Kerrisk].
(Deferred, probably to fsinfo. Finding out if there's an ACL or
seclabal might require extra filesystem operations).
(16) Femtosecond-resolution timestamps [Dave Chinner].
(A __reserved field has been left in the statx_timestamp struct for
this - if there proves to be a need).
(17) A set multiple attributes syscall to go with this.
===============
NEW SYSTEM CALL
===============
The new system call is:
int ret = statx(int dfd,
const char *filename,
unsigned int flags,
unsigned int mask,
struct statx *buffer);
The dfd, filename and flags parameters indicate the file to query, in a
similar way to fstatat(). There is no equivalent of lstat() as that can be
emulated with statx() by passing AT_SYMLINK_NOFOLLOW in flags. There is
also no equivalent of fstat() as that can be emulated by passing a NULL
filename to statx() with the fd of interest in dfd.
Whether or not statx() synchronises the attributes with the backing store
can be controlled by OR'ing a value into the flags argument (this typically
only affects network filesystems):
(1) AT_STATX_SYNC_AS_STAT tells statx() to behave as stat() does in this
respect.
(2) AT_STATX_FORCE_SYNC will require a network filesystem to synchronise
its attributes with the server - which might require data writeback to
occur to get the timestamps correct.
(3) AT_STATX_DONT_SYNC will suppress synchronisation with the server in a
network filesystem. The resulting values should be considered
approximate.
mask is a bitmask indicating the fields in struct statx that are of
interest to the caller. The user should set this to STATX_BASIC_STATS to
get the basic set returned by stat(). It should be noted that asking for
more information may entail extra I/O operations.
buffer points to the destination for the data. This must be 256 bytes in
size.
======================
MAIN ATTRIBUTES RECORD
======================
The following structures are defined in which to return the main attribute
set:
struct statx_timestamp {
__s64 tv_sec;
__s32 tv_nsec;
__s32 __reserved;
};
struct statx {
__u32 stx_mask;
__u32 stx_blksize;
__u64 stx_attributes;
__u32 stx_nlink;
__u32 stx_uid;
__u32 stx_gid;
__u16 stx_mode;
__u16 __spare0[1];
__u64 stx_ino;
__u64 stx_size;
__u64 stx_blocks;
__u64 __spare1[1];
struct statx_timestamp stx_atime;
struct statx_timestamp stx_btime;
struct statx_timestamp stx_ctime;
struct statx_timestamp stx_mtime;
__u32 stx_rdev_major;
__u32 stx_rdev_minor;
__u32 stx_dev_major;
__u32 stx_dev_minor;
__u64 __spare2[14];
};
The defined bits in request_mask and stx_mask are:
STATX_TYPE Want/got stx_mode & S_IFMT
STATX_MODE Want/got stx_mode & ~S_IFMT
STATX_NLINK Want/got stx_nlink
STATX_UID Want/got stx_uid
STATX_GID Want/got stx_gid
STATX_ATIME Want/got stx_atime{,_ns}
STATX_MTIME Want/got stx_mtime{,_ns}
STATX_CTIME Want/got stx_ctime{,_ns}
STATX_INO Want/got stx_ino
STATX_SIZE Want/got stx_size
STATX_BLOCKS Want/got stx_blocks
STATX_BASIC_STATS [The stuff in the normal stat struct]
STATX_BTIME Want/got stx_btime{,_ns}
STATX_ALL [All currently available stuff]
stx_btime is the file creation time, stx_mask is a bitmask indicating the
data provided and __spares*[] are where as-yet undefined fields can be
placed.
Time fields are structures with separate seconds and nanoseconds fields
plus a reserved field in case we want to add even finer resolution. Note
that times will be negative if before 1970; in such a case, the nanosecond
fields will also be negative if not zero.
The bits defined in the stx_attributes field convey information about a
file, how it is accessed, where it is and what it does. The following
attributes map to FS_*_FL flags and are the same numerical value:
STATX_ATTR_COMPRESSED File is compressed by the fs
STATX_ATTR_IMMUTABLE File is marked immutable
STATX_ATTR_APPEND File is append-only
STATX_ATTR_NODUMP File is not to be dumped
STATX_ATTR_ENCRYPTED File requires key to decrypt in fs
Within the kernel, the supported flags are listed by:
KSTAT_ATTR_FS_IOC_FLAGS
[Are any other IOC flags of sufficient general interest to be exposed
through this interface?]
New flags include:
STATX_ATTR_AUTOMOUNT Object is an automount trigger
These are for the use of GUI tools that might want to mark files specially,
depending on what they are.
Fields in struct statx come in a number of classes:
(0) stx_dev_*, stx_blksize.
These are local system information and are always available.
(1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time, stx_ino,
stx_size, stx_blocks.
These will be returned whether the caller asks for them or not. The
corresponding bits in stx_mask will be set to indicate whether they
actually have valid values.
If the caller didn't ask for them, then they may be approximated. For
example, NFS won't waste any time updating them from the server,
unless as a byproduct of updating something requested.
If the values don't actually exist for the underlying object (such as
UID or GID on a DOS file), then the bit won't be set in the stx_mask,
even if the caller asked for the value. In such a case, the returned
value will be a fabrication.
Note that there are instances where the type might not be valid, for
instance Windows reparse points.
(2) stx_rdev_*.
This will be set only if stx_mode indicates we're looking at a
blockdev or a chardev, otherwise will be 0.
(3) stx_btime.
Similar to (1), except this will be set to 0 if it doesn't exist.
=======
TESTING
=======
The following test program can be used to test the statx system call:
samples/statx/test-statx.c
Just compile and run, passing it paths to the files you want to examine.
The file is built automatically if CONFIG_SAMPLES is enabled.
Here's some example output. Firstly, an NFS directory that crosses to
another FSID. Note that the AUTOMOUNT attribute is set because transiting
this directory will cause d_automount to be invoked by the VFS.
[root@andromeda ~]# /tmp/test-statx -A /warthog/data
statx(/warthog/data) = 0
results=7ff
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:26 Inode: 1703937 Links: 125
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2016-11-24 09:02:12.219699527+0000
Modify: 2016-11-17 10:44:36.225653653+0000
Change: 2016-11-17 10:44:36.225653653+0000
Attributes: 0000000000001000 (-------- -------- -------- -------- -------- -------- ---m---- --------)
Secondly, the result of automounting on that directory.
[root@andromeda ~]# /tmp/test-statx /warthog/data
statx(/warthog/data) = 0
results=7ff
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:27 Inode: 2 Links: 125
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2016-11-24 09:02:12.219699527+0000
Modify: 2016-11-17 10:44:36.225653653+0000
Change: 2016-11-17 10:44:36.225653653+0000
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-01-31 19:46:22 +03:00
|
|
|
error = vfs_getattr(&file->f_path, &stat,
|
|
|
|
STATX_INO, AT_STATX_SYNC_AS_STAT);
|
2005-04-17 02:20:36 +04:00
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
memset(info, 0, sizeof(*info));
|
|
|
|
info->lo_number = lo->lo_number;
|
|
|
|
info->lo_device = huge_encode_dev(stat.dev);
|
|
|
|
info->lo_inode = stat.ino;
|
|
|
|
info->lo_rdevice = huge_encode_dev(lo->lo_device ? stat.rdev : stat.dev);
|
|
|
|
info->lo_offset = lo->lo_offset;
|
|
|
|
info->lo_sizelimit = lo->lo_sizelimit;
|
|
|
|
info->lo_flags = lo->lo_flags;
|
|
|
|
memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE);
|
|
|
|
memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE);
|
|
|
|
info->lo_encrypt_type =
|
|
|
|
lo->lo_encryption ? lo->lo_encryption->number : 0;
|
|
|
|
if (lo->lo_encrypt_key_size && capable(CAP_SYS_ADMIN)) {
|
|
|
|
info->lo_encrypt_key_size = lo->lo_encrypt_key_size;
|
|
|
|
memcpy(info->lo_encrypt_key, lo->lo_encrypt_key,
|
|
|
|
lo->lo_encrypt_key_size);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
loop_info64_from_old(const struct loop_info *info, struct loop_info64 *info64)
|
|
|
|
{
|
|
|
|
memset(info64, 0, sizeof(*info64));
|
|
|
|
info64->lo_number = info->lo_number;
|
|
|
|
info64->lo_device = info->lo_device;
|
|
|
|
info64->lo_inode = info->lo_inode;
|
|
|
|
info64->lo_rdevice = info->lo_rdevice;
|
|
|
|
info64->lo_offset = info->lo_offset;
|
|
|
|
info64->lo_sizelimit = 0;
|
|
|
|
info64->lo_encrypt_type = info->lo_encrypt_type;
|
|
|
|
info64->lo_encrypt_key_size = info->lo_encrypt_key_size;
|
|
|
|
info64->lo_flags = info->lo_flags;
|
|
|
|
info64->lo_init[0] = info->lo_init[0];
|
|
|
|
info64->lo_init[1] = info->lo_init[1];
|
|
|
|
if (info->lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
|
|
|
|
memcpy(info64->lo_crypt_name, info->lo_name, LO_NAME_SIZE);
|
|
|
|
else
|
|
|
|
memcpy(info64->lo_file_name, info->lo_name, LO_NAME_SIZE);
|
|
|
|
memcpy(info64->lo_encrypt_key, info->lo_encrypt_key, LO_KEY_SIZE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_info64_to_old(const struct loop_info64 *info64, struct loop_info *info)
|
|
|
|
{
|
|
|
|
memset(info, 0, sizeof(*info));
|
|
|
|
info->lo_number = info64->lo_number;
|
|
|
|
info->lo_device = info64->lo_device;
|
|
|
|
info->lo_inode = info64->lo_inode;
|
|
|
|
info->lo_rdevice = info64->lo_rdevice;
|
|
|
|
info->lo_offset = info64->lo_offset;
|
|
|
|
info->lo_encrypt_type = info64->lo_encrypt_type;
|
|
|
|
info->lo_encrypt_key_size = info64->lo_encrypt_key_size;
|
|
|
|
info->lo_flags = info64->lo_flags;
|
|
|
|
info->lo_init[0] = info64->lo_init[0];
|
|
|
|
info->lo_init[1] = info64->lo_init[1];
|
|
|
|
if (info->lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
|
|
|
|
memcpy(info->lo_name, info64->lo_crypt_name, LO_NAME_SIZE);
|
|
|
|
else
|
|
|
|
memcpy(info->lo_name, info64->lo_file_name, LO_NAME_SIZE);
|
|
|
|
memcpy(info->lo_encrypt_key, info64->lo_encrypt_key, LO_KEY_SIZE);
|
|
|
|
|
|
|
|
/* error in case values were truncated */
|
|
|
|
if (info->lo_device != info64->lo_device ||
|
|
|
|
info->lo_rdevice != info64->lo_rdevice ||
|
|
|
|
info->lo_inode != info64->lo_inode ||
|
|
|
|
info->lo_offset != info64->lo_offset)
|
|
|
|
return -EOVERFLOW;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_set_status_old(struct loop_device *lo, const struct loop_info __user *arg)
|
|
|
|
{
|
|
|
|
struct loop_info info;
|
|
|
|
struct loop_info64 info64;
|
|
|
|
|
|
|
|
if (copy_from_user(&info, arg, sizeof (struct loop_info)))
|
|
|
|
return -EFAULT;
|
|
|
|
loop_info64_from_old(&info, &info64);
|
|
|
|
return loop_set_status(lo, &info64);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_set_status64(struct loop_device *lo, const struct loop_info64 __user *arg)
|
|
|
|
{
|
|
|
|
struct loop_info64 info64;
|
|
|
|
|
|
|
|
if (copy_from_user(&info64, arg, sizeof (struct loop_info64)))
|
|
|
|
return -EFAULT;
|
|
|
|
return loop_set_status(lo, &info64);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_get_status_old(struct loop_device *lo, struct loop_info __user *arg) {
|
|
|
|
struct loop_info info;
|
|
|
|
struct loop_info64 info64;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (!arg)
|
|
|
|
err = -EINVAL;
|
|
|
|
if (!err)
|
|
|
|
err = loop_get_status(lo, &info64);
|
|
|
|
if (!err)
|
|
|
|
err = loop_info64_to_old(&info64, &info);
|
|
|
|
if (!err && copy_to_user(arg, &info, sizeof(info)))
|
|
|
|
err = -EFAULT;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_get_status64(struct loop_device *lo, struct loop_info64 __user *arg) {
|
|
|
|
struct loop_info64 info64;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (!arg)
|
|
|
|
err = -EINVAL;
|
|
|
|
if (!err)
|
|
|
|
err = loop_get_status(lo, &info64);
|
|
|
|
if (!err && copy_to_user(arg, &info64, sizeof(info64)))
|
|
|
|
err = -EFAULT;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-06-08 14:46:44 +03:00
|
|
|
static int loop_set_capacity(struct loop_device *lo)
|
loop: add ioctl to resize a loop device
Add the ability to 'resize' the loop device on the fly.
One practical application is a loop file with XFS filesystem, already
mounted: You can easily enlarge the file (append some bytes) and then call
ioctl(fd, LOOP_SET_CAPACITY, new); The loop driver will learn about the
new size and you can use xfs_growfs later on, which will allow you to use
full capacity of the loop file without the need to unmount.
Test app:
#include <linux/fs.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define _GNU_SOURCE
#include <getopt.h>
char *me;
void usage(FILE *f)
{
fprintf(f, "%s [options] loop_dev [backend_file]\n"
"-s, --set new_size_in_bytes\n"
"\twhen backend_file is given, "
"it will be expanded too while keeping the original contents\n",
me);
}
struct option opts[] = {
{
.name = "set",
.has_arg = 1,
.flag = NULL,
.val = 's'
},
{
.name = "help",
.has_arg = 0,
.flag = NULL,
.val = 'h'
}
};
void err_size(char *name, __u64 old)
{
fprintf(stderr, "size must be larger than current %s (%llu)\n",
name, old);
}
int main(int argc, char *argv[])
{
int fd, err, c, i, bfd;
ssize_t ssz;
size_t sz;
__u64 old, new, append;
char a[BUFSIZ];
struct stat st;
FILE *out;
char *backend, *dev;
err = EINVAL;
out = stderr;
me = argv[0];
new = 0;
while ((c = getopt_long(argc, argv, "s:h", opts, &i)) != -1) {
switch (c) {
case 's':
errno = 0;
new = strtoull(optarg, NULL, 0);
if (errno) {
err = errno;
perror(argv[i]);
goto out;
}
break;
case 'h':
err = 0;
out = stdout;
goto err;
default:
perror(argv[i]);
goto err;
}
}
if (optind < argc)
dev = argv[optind++];
else
goto err;
fd = open(dev, O_RDONLY);
if (fd < 0) {
err = errno;
perror(dev);
goto out;
}
err = ioctl(fd, BLKGETSIZE64, &old);
if (err) {
err = errno;
perror("ioctl BLKGETSIZE64");
goto out;
}
if (!new) {
printf("%llu\n", old);
goto out;
}
if (new < old) {
err = EINVAL;
err_size(dev, old);
goto out;
}
if (optind < argc) {
backend = argv[optind++];
bfd = open(backend, O_WRONLY|O_APPEND);
if (bfd < 0) {
err = errno;
perror(backend);
goto out;
}
err = fstat(bfd, &st);
if (err) {
err = errno;
perror(backend);
goto out;
}
if (new < st.st_size) {
err = EINVAL;
err_size(backend, st.st_size);
goto out;
}
append = new - st.st_size;
sz = sizeof(a);
while (append > 0) {
if (append < sz)
sz = append;
ssz = write(bfd, a, sz);
if (ssz != sz) {
err = errno;
perror(backend);
goto out;
}
append -= sz;
}
err = fsync(bfd);
if (err) {
err = errno;
perror(backend);
goto out;
}
}
err = ioctl(fd, LOOP_SET_CAPACITY, new);
if (err) {
err = errno;
perror("ioctl LOOP_SET_CAPACITY");
}
goto out;
err:
usage(out);
out:
return err;
}
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Tomas Matejicek <tomas@slax.org>
Cc: <util-linux-ng@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <linux-api@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 02:23:43 +04:00
|
|
|
{
|
|
|
|
if (unlikely(lo->lo_state != Lo_bound))
|
2013-02-22 03:16:47 +04:00
|
|
|
return -ENXIO;
|
loop: add ioctl to resize a loop device
Add the ability to 'resize' the loop device on the fly.
One practical application is a loop file with XFS filesystem, already
mounted: You can easily enlarge the file (append some bytes) and then call
ioctl(fd, LOOP_SET_CAPACITY, new); The loop driver will learn about the
new size and you can use xfs_growfs later on, which will allow you to use
full capacity of the loop file without the need to unmount.
Test app:
#include <linux/fs.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define _GNU_SOURCE
#include <getopt.h>
char *me;
void usage(FILE *f)
{
fprintf(f, "%s [options] loop_dev [backend_file]\n"
"-s, --set new_size_in_bytes\n"
"\twhen backend_file is given, "
"it will be expanded too while keeping the original contents\n",
me);
}
struct option opts[] = {
{
.name = "set",
.has_arg = 1,
.flag = NULL,
.val = 's'
},
{
.name = "help",
.has_arg = 0,
.flag = NULL,
.val = 'h'
}
};
void err_size(char *name, __u64 old)
{
fprintf(stderr, "size must be larger than current %s (%llu)\n",
name, old);
}
int main(int argc, char *argv[])
{
int fd, err, c, i, bfd;
ssize_t ssz;
size_t sz;
__u64 old, new, append;
char a[BUFSIZ];
struct stat st;
FILE *out;
char *backend, *dev;
err = EINVAL;
out = stderr;
me = argv[0];
new = 0;
while ((c = getopt_long(argc, argv, "s:h", opts, &i)) != -1) {
switch (c) {
case 's':
errno = 0;
new = strtoull(optarg, NULL, 0);
if (errno) {
err = errno;
perror(argv[i]);
goto out;
}
break;
case 'h':
err = 0;
out = stdout;
goto err;
default:
perror(argv[i]);
goto err;
}
}
if (optind < argc)
dev = argv[optind++];
else
goto err;
fd = open(dev, O_RDONLY);
if (fd < 0) {
err = errno;
perror(dev);
goto out;
}
err = ioctl(fd, BLKGETSIZE64, &old);
if (err) {
err = errno;
perror("ioctl BLKGETSIZE64");
goto out;
}
if (!new) {
printf("%llu\n", old);
goto out;
}
if (new < old) {
err = EINVAL;
err_size(dev, old);
goto out;
}
if (optind < argc) {
backend = argv[optind++];
bfd = open(backend, O_WRONLY|O_APPEND);
if (bfd < 0) {
err = errno;
perror(backend);
goto out;
}
err = fstat(bfd, &st);
if (err) {
err = errno;
perror(backend);
goto out;
}
if (new < st.st_size) {
err = EINVAL;
err_size(backend, st.st_size);
goto out;
}
append = new - st.st_size;
sz = sizeof(a);
while (append > 0) {
if (append < sz)
sz = append;
ssz = write(bfd, a, sz);
if (ssz != sz) {
err = errno;
perror(backend);
goto out;
}
append -= sz;
}
err = fsync(bfd);
if (err) {
err = errno;
perror(backend);
goto out;
}
}
err = ioctl(fd, LOOP_SET_CAPACITY, new);
if (err) {
err = errno;
perror("ioctl LOOP_SET_CAPACITY");
}
goto out;
err:
usage(out);
out:
return err;
}
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Tomas Matejicek <tomas@slax.org>
Cc: <util-linux-ng@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <linux-api@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 02:23:43 +04:00
|
|
|
|
2017-08-24 00:54:59 +03:00
|
|
|
return figure_loop_size(lo, lo->lo_offset, lo->lo_sizelimit);
|
loop: add ioctl to resize a loop device
Add the ability to 'resize' the loop device on the fly.
One practical application is a loop file with XFS filesystem, already
mounted: You can easily enlarge the file (append some bytes) and then call
ioctl(fd, LOOP_SET_CAPACITY, new); The loop driver will learn about the
new size and you can use xfs_growfs later on, which will allow you to use
full capacity of the loop file without the need to unmount.
Test app:
#include <linux/fs.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define _GNU_SOURCE
#include <getopt.h>
char *me;
void usage(FILE *f)
{
fprintf(f, "%s [options] loop_dev [backend_file]\n"
"-s, --set new_size_in_bytes\n"
"\twhen backend_file is given, "
"it will be expanded too while keeping the original contents\n",
me);
}
struct option opts[] = {
{
.name = "set",
.has_arg = 1,
.flag = NULL,
.val = 's'
},
{
.name = "help",
.has_arg = 0,
.flag = NULL,
.val = 'h'
}
};
void err_size(char *name, __u64 old)
{
fprintf(stderr, "size must be larger than current %s (%llu)\n",
name, old);
}
int main(int argc, char *argv[])
{
int fd, err, c, i, bfd;
ssize_t ssz;
size_t sz;
__u64 old, new, append;
char a[BUFSIZ];
struct stat st;
FILE *out;
char *backend, *dev;
err = EINVAL;
out = stderr;
me = argv[0];
new = 0;
while ((c = getopt_long(argc, argv, "s:h", opts, &i)) != -1) {
switch (c) {
case 's':
errno = 0;
new = strtoull(optarg, NULL, 0);
if (errno) {
err = errno;
perror(argv[i]);
goto out;
}
break;
case 'h':
err = 0;
out = stdout;
goto err;
default:
perror(argv[i]);
goto err;
}
}
if (optind < argc)
dev = argv[optind++];
else
goto err;
fd = open(dev, O_RDONLY);
if (fd < 0) {
err = errno;
perror(dev);
goto out;
}
err = ioctl(fd, BLKGETSIZE64, &old);
if (err) {
err = errno;
perror("ioctl BLKGETSIZE64");
goto out;
}
if (!new) {
printf("%llu\n", old);
goto out;
}
if (new < old) {
err = EINVAL;
err_size(dev, old);
goto out;
}
if (optind < argc) {
backend = argv[optind++];
bfd = open(backend, O_WRONLY|O_APPEND);
if (bfd < 0) {
err = errno;
perror(backend);
goto out;
}
err = fstat(bfd, &st);
if (err) {
err = errno;
perror(backend);
goto out;
}
if (new < st.st_size) {
err = EINVAL;
err_size(backend, st.st_size);
goto out;
}
append = new - st.st_size;
sz = sizeof(a);
while (append > 0) {
if (append < sz)
sz = append;
ssz = write(bfd, a, sz);
if (ssz != sz) {
err = errno;
perror(backend);
goto out;
}
append -= sz;
}
err = fsync(bfd);
if (err) {
err = errno;
perror(backend);
goto out;
}
}
err = ioctl(fd, LOOP_SET_CAPACITY, new);
if (err) {
err = errno;
perror("ioctl LOOP_SET_CAPACITY");
}
goto out;
err:
usage(out);
out:
return err;
}
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Tomas Matejicek <tomas@slax.org>
Cc: <util-linux-ng@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <linux-api@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 02:23:43 +04:00
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:50 +03:00
|
|
|
static int loop_set_dio(struct loop_device *lo, unsigned long arg)
|
|
|
|
{
|
|
|
|
int error = -ENXIO;
|
|
|
|
if (lo->lo_state != Lo_bound)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
__loop_update_dio(lo, !!arg);
|
|
|
|
if (lo->use_dio == !!arg)
|
|
|
|
return 0;
|
|
|
|
error = -EINVAL;
|
|
|
|
out:
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2017-08-24 10:03:43 +03:00
|
|
|
static int loop_set_block_size(struct loop_device *lo, unsigned long arg)
|
|
|
|
{
|
|
|
|
if (lo->lo_state != Lo_bound)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
if (arg < 512 || arg > PAGE_SIZE || !is_power_of_2(arg))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
blk_mq_freeze_queue(lo->lo_queue);
|
|
|
|
|
|
|
|
blk_queue_logical_block_size(lo->lo_queue, arg);
|
2017-09-06 00:24:47 +03:00
|
|
|
blk_queue_physical_block_size(lo->lo_queue, arg);
|
|
|
|
blk_queue_io_min(lo->lo_queue, arg);
|
2017-08-24 10:03:43 +03:00
|
|
|
loop_update_dio(lo);
|
|
|
|
|
|
|
|
blk_mq_unfreeze_queue(lo->lo_queue);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-03-02 17:29:48 +03:00
|
|
|
static int lo_ioctl(struct block_device *bdev, fmode_t mode,
|
2005-04-17 02:20:36 +04:00
|
|
|
unsigned int cmd, unsigned long arg)
|
|
|
|
{
|
2008-03-02 17:29:48 +03:00
|
|
|
struct loop_device *lo = bdev->bd_disk->private_data;
|
2005-04-17 02:20:36 +04:00
|
|
|
int err;
|
|
|
|
|
loop: fix circular locking in loop_clr_fd()
With CONFIG_PROVE_LOCKING enabled
$ losetup /dev/loop0 file
$ losetup -o 32256 /dev/loop1 /dev/loop0
$ losetup -d /dev/loop1
$ losetup -d /dev/loop0
triggers a [ INFO: possible circular locking dependency detected ]
I think this warning is a false positive.
Open/close on a loop device acquires bd_mutex of the device before
acquiring lo_ctl_mutex of the same device. For ioctl(LOOP_CLR_FD) after
acquiring lo_ctl_mutex, fput on the backing_file might acquire the bd_mutex of
a device, if backing file is a device and this is the last reference to the
file being dropped . But it is guaranteed that it is impossible to have a
circular list of backing devices.(say loop2->loop1->loop0->loop2 is not
possible), which guarantees that this can never deadlock.
So this warning should be suppressed. It is very difficult to annotate lockdep
not to warn here in the correct way. A simple way to silence lockdep could be
to mark the lo_ctl_mutex in ioctl to be a sub class, but this might mask some
other real bugs.
@@ -1164,7 +1164,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode,
struct loop_device *lo = bdev->bd_disk->private_data;
int err;
- mutex_lock(&lo->lo_ctl_mutex);
+ mutex_lock_nested(&lo->lo_ctl_mutex, 1);
switch (cmd) {
case LOOP_SET_FD:
err = loop_set_fd(lo, mode, bdev, arg);
Or actually marking the bd_mutex after lo_ctl_mutex as a sub class could be
a better solution.
Luckily it is easy to avoid calling fput on backing file with lo_ctl_mutex
held, so no lockdep annotation is required.
If you do not like the special handling of the lo_ctl_mutex just for the
LOOP_CLR_FD ioctl in lo_ioctl(), the mutex handling could be moved inside
each of the individual ioctl handlers and I could send you another patch.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-03-24 14:33:41 +03:00
|
|
|
mutex_lock_nested(&lo->lo_ctl_mutex, 1);
|
2005-04-17 02:20:36 +04:00
|
|
|
switch (cmd) {
|
|
|
|
case LOOP_SET_FD:
|
2008-03-02 17:29:48 +03:00
|
|
|
err = loop_set_fd(lo, mode, bdev, arg);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case LOOP_CHANGE_FD:
|
2008-03-02 17:29:48 +03:00
|
|
|
err = loop_change_fd(lo, bdev, arg);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case LOOP_CLR_FD:
|
loop: fix circular locking in loop_clr_fd()
With CONFIG_PROVE_LOCKING enabled
$ losetup /dev/loop0 file
$ losetup -o 32256 /dev/loop1 /dev/loop0
$ losetup -d /dev/loop1
$ losetup -d /dev/loop0
triggers a [ INFO: possible circular locking dependency detected ]
I think this warning is a false positive.
Open/close on a loop device acquires bd_mutex of the device before
acquiring lo_ctl_mutex of the same device. For ioctl(LOOP_CLR_FD) after
acquiring lo_ctl_mutex, fput on the backing_file might acquire the bd_mutex of
a device, if backing file is a device and this is the last reference to the
file being dropped . But it is guaranteed that it is impossible to have a
circular list of backing devices.(say loop2->loop1->loop0->loop2 is not
possible), which guarantees that this can never deadlock.
So this warning should be suppressed. It is very difficult to annotate lockdep
not to warn here in the correct way. A simple way to silence lockdep could be
to mark the lo_ctl_mutex in ioctl to be a sub class, but this might mask some
other real bugs.
@@ -1164,7 +1164,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode,
struct loop_device *lo = bdev->bd_disk->private_data;
int err;
- mutex_lock(&lo->lo_ctl_mutex);
+ mutex_lock_nested(&lo->lo_ctl_mutex, 1);
switch (cmd) {
case LOOP_SET_FD:
err = loop_set_fd(lo, mode, bdev, arg);
Or actually marking the bd_mutex after lo_ctl_mutex as a sub class could be
a better solution.
Luckily it is easy to avoid calling fput on backing file with lo_ctl_mutex
held, so no lockdep annotation is required.
If you do not like the special handling of the lo_ctl_mutex just for the
LOOP_CLR_FD ioctl in lo_ioctl(), the mutex handling could be moved inside
each of the individual ioctl handlers and I could send you another patch.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-03-24 14:33:41 +03:00
|
|
|
/* loop_clr_fd would have unlocked lo_ctl_mutex on success */
|
2011-09-21 12:02:13 +04:00
|
|
|
err = loop_clr_fd(lo);
|
loop: fix circular locking in loop_clr_fd()
With CONFIG_PROVE_LOCKING enabled
$ losetup /dev/loop0 file
$ losetup -o 32256 /dev/loop1 /dev/loop0
$ losetup -d /dev/loop1
$ losetup -d /dev/loop0
triggers a [ INFO: possible circular locking dependency detected ]
I think this warning is a false positive.
Open/close on a loop device acquires bd_mutex of the device before
acquiring lo_ctl_mutex of the same device. For ioctl(LOOP_CLR_FD) after
acquiring lo_ctl_mutex, fput on the backing_file might acquire the bd_mutex of
a device, if backing file is a device and this is the last reference to the
file being dropped . But it is guaranteed that it is impossible to have a
circular list of backing devices.(say loop2->loop1->loop0->loop2 is not
possible), which guarantees that this can never deadlock.
So this warning should be suppressed. It is very difficult to annotate lockdep
not to warn here in the correct way. A simple way to silence lockdep could be
to mark the lo_ctl_mutex in ioctl to be a sub class, but this might mask some
other real bugs.
@@ -1164,7 +1164,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode,
struct loop_device *lo = bdev->bd_disk->private_data;
int err;
- mutex_lock(&lo->lo_ctl_mutex);
+ mutex_lock_nested(&lo->lo_ctl_mutex, 1);
switch (cmd) {
case LOOP_SET_FD:
err = loop_set_fd(lo, mode, bdev, arg);
Or actually marking the bd_mutex after lo_ctl_mutex as a sub class could be
a better solution.
Luckily it is easy to avoid calling fput on backing file with lo_ctl_mutex
held, so no lockdep annotation is required.
If you do not like the special handling of the lo_ctl_mutex just for the
LOOP_CLR_FD ioctl in lo_ioctl(), the mutex handling could be moved inside
each of the individual ioctl handlers and I could send you another patch.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-03-24 14:33:41 +03:00
|
|
|
if (!err)
|
|
|
|
goto out_unlocked;
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case LOOP_SET_STATUS:
|
2011-11-16 12:21:49 +04:00
|
|
|
err = -EPERM;
|
|
|
|
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
|
|
|
|
err = loop_set_status_old(lo,
|
|
|
|
(struct loop_info __user *)arg);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case LOOP_GET_STATUS:
|
|
|
|
err = loop_get_status_old(lo, (struct loop_info __user *) arg);
|
|
|
|
break;
|
|
|
|
case LOOP_SET_STATUS64:
|
2011-11-16 12:21:49 +04:00
|
|
|
err = -EPERM;
|
|
|
|
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
|
|
|
|
err = loop_set_status64(lo,
|
|
|
|
(struct loop_info64 __user *) arg);
|
2005-04-17 02:20:36 +04:00
|
|
|
break;
|
|
|
|
case LOOP_GET_STATUS64:
|
|
|
|
err = loop_get_status64(lo, (struct loop_info64 __user *) arg);
|
|
|
|
break;
|
loop: add ioctl to resize a loop device
Add the ability to 'resize' the loop device on the fly.
One practical application is a loop file with XFS filesystem, already
mounted: You can easily enlarge the file (append some bytes) and then call
ioctl(fd, LOOP_SET_CAPACITY, new); The loop driver will learn about the
new size and you can use xfs_growfs later on, which will allow you to use
full capacity of the loop file without the need to unmount.
Test app:
#include <linux/fs.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define _GNU_SOURCE
#include <getopt.h>
char *me;
void usage(FILE *f)
{
fprintf(f, "%s [options] loop_dev [backend_file]\n"
"-s, --set new_size_in_bytes\n"
"\twhen backend_file is given, "
"it will be expanded too while keeping the original contents\n",
me);
}
struct option opts[] = {
{
.name = "set",
.has_arg = 1,
.flag = NULL,
.val = 's'
},
{
.name = "help",
.has_arg = 0,
.flag = NULL,
.val = 'h'
}
};
void err_size(char *name, __u64 old)
{
fprintf(stderr, "size must be larger than current %s (%llu)\n",
name, old);
}
int main(int argc, char *argv[])
{
int fd, err, c, i, bfd;
ssize_t ssz;
size_t sz;
__u64 old, new, append;
char a[BUFSIZ];
struct stat st;
FILE *out;
char *backend, *dev;
err = EINVAL;
out = stderr;
me = argv[0];
new = 0;
while ((c = getopt_long(argc, argv, "s:h", opts, &i)) != -1) {
switch (c) {
case 's':
errno = 0;
new = strtoull(optarg, NULL, 0);
if (errno) {
err = errno;
perror(argv[i]);
goto out;
}
break;
case 'h':
err = 0;
out = stdout;
goto err;
default:
perror(argv[i]);
goto err;
}
}
if (optind < argc)
dev = argv[optind++];
else
goto err;
fd = open(dev, O_RDONLY);
if (fd < 0) {
err = errno;
perror(dev);
goto out;
}
err = ioctl(fd, BLKGETSIZE64, &old);
if (err) {
err = errno;
perror("ioctl BLKGETSIZE64");
goto out;
}
if (!new) {
printf("%llu\n", old);
goto out;
}
if (new < old) {
err = EINVAL;
err_size(dev, old);
goto out;
}
if (optind < argc) {
backend = argv[optind++];
bfd = open(backend, O_WRONLY|O_APPEND);
if (bfd < 0) {
err = errno;
perror(backend);
goto out;
}
err = fstat(bfd, &st);
if (err) {
err = errno;
perror(backend);
goto out;
}
if (new < st.st_size) {
err = EINVAL;
err_size(backend, st.st_size);
goto out;
}
append = new - st.st_size;
sz = sizeof(a);
while (append > 0) {
if (append < sz)
sz = append;
ssz = write(bfd, a, sz);
if (ssz != sz) {
err = errno;
perror(backend);
goto out;
}
append -= sz;
}
err = fsync(bfd);
if (err) {
err = errno;
perror(backend);
goto out;
}
}
err = ioctl(fd, LOOP_SET_CAPACITY, new);
if (err) {
err = errno;
perror("ioctl LOOP_SET_CAPACITY");
}
goto out;
err:
usage(out);
out:
return err;
}
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Tomas Matejicek <tomas@slax.org>
Cc: <util-linux-ng@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <linux-api@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 02:23:43 +04:00
|
|
|
case LOOP_SET_CAPACITY:
|
|
|
|
err = -EPERM;
|
|
|
|
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
|
2017-06-08 14:46:44 +03:00
|
|
|
err = loop_set_capacity(lo);
|
loop: add ioctl to resize a loop device
Add the ability to 'resize' the loop device on the fly.
One practical application is a loop file with XFS filesystem, already
mounted: You can easily enlarge the file (append some bytes) and then call
ioctl(fd, LOOP_SET_CAPACITY, new); The loop driver will learn about the
new size and you can use xfs_growfs later on, which will allow you to use
full capacity of the loop file without the need to unmount.
Test app:
#include <linux/fs.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define _GNU_SOURCE
#include <getopt.h>
char *me;
void usage(FILE *f)
{
fprintf(f, "%s [options] loop_dev [backend_file]\n"
"-s, --set new_size_in_bytes\n"
"\twhen backend_file is given, "
"it will be expanded too while keeping the original contents\n",
me);
}
struct option opts[] = {
{
.name = "set",
.has_arg = 1,
.flag = NULL,
.val = 's'
},
{
.name = "help",
.has_arg = 0,
.flag = NULL,
.val = 'h'
}
};
void err_size(char *name, __u64 old)
{
fprintf(stderr, "size must be larger than current %s (%llu)\n",
name, old);
}
int main(int argc, char *argv[])
{
int fd, err, c, i, bfd;
ssize_t ssz;
size_t sz;
__u64 old, new, append;
char a[BUFSIZ];
struct stat st;
FILE *out;
char *backend, *dev;
err = EINVAL;
out = stderr;
me = argv[0];
new = 0;
while ((c = getopt_long(argc, argv, "s:h", opts, &i)) != -1) {
switch (c) {
case 's':
errno = 0;
new = strtoull(optarg, NULL, 0);
if (errno) {
err = errno;
perror(argv[i]);
goto out;
}
break;
case 'h':
err = 0;
out = stdout;
goto err;
default:
perror(argv[i]);
goto err;
}
}
if (optind < argc)
dev = argv[optind++];
else
goto err;
fd = open(dev, O_RDONLY);
if (fd < 0) {
err = errno;
perror(dev);
goto out;
}
err = ioctl(fd, BLKGETSIZE64, &old);
if (err) {
err = errno;
perror("ioctl BLKGETSIZE64");
goto out;
}
if (!new) {
printf("%llu\n", old);
goto out;
}
if (new < old) {
err = EINVAL;
err_size(dev, old);
goto out;
}
if (optind < argc) {
backend = argv[optind++];
bfd = open(backend, O_WRONLY|O_APPEND);
if (bfd < 0) {
err = errno;
perror(backend);
goto out;
}
err = fstat(bfd, &st);
if (err) {
err = errno;
perror(backend);
goto out;
}
if (new < st.st_size) {
err = EINVAL;
err_size(backend, st.st_size);
goto out;
}
append = new - st.st_size;
sz = sizeof(a);
while (append > 0) {
if (append < sz)
sz = append;
ssz = write(bfd, a, sz);
if (ssz != sz) {
err = errno;
perror(backend);
goto out;
}
append -= sz;
}
err = fsync(bfd);
if (err) {
err = errno;
perror(backend);
goto out;
}
}
err = ioctl(fd, LOOP_SET_CAPACITY, new);
if (err) {
err = errno;
perror("ioctl LOOP_SET_CAPACITY");
}
goto out;
err:
usage(out);
out:
return err;
}
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Tomas Matejicek <tomas@slax.org>
Cc: <util-linux-ng@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <linux-api@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 02:23:43 +04:00
|
|
|
break;
|
2015-08-17 05:31:50 +03:00
|
|
|
case LOOP_SET_DIRECT_IO:
|
|
|
|
err = -EPERM;
|
|
|
|
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
|
|
|
|
err = loop_set_dio(lo, arg);
|
|
|
|
break;
|
2017-08-24 10:03:43 +03:00
|
|
|
case LOOP_SET_BLOCK_SIZE:
|
|
|
|
err = -EPERM;
|
|
|
|
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
|
|
|
|
err = loop_set_block_size(lo, arg);
|
|
|
|
break;
|
2005-04-17 02:20:36 +04:00
|
|
|
default:
|
|
|
|
err = lo->ioctl ? lo->ioctl(lo, cmd, arg) : -EINVAL;
|
|
|
|
}
|
2006-03-23 14:00:38 +03:00
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
loop: fix circular locking in loop_clr_fd()
With CONFIG_PROVE_LOCKING enabled
$ losetup /dev/loop0 file
$ losetup -o 32256 /dev/loop1 /dev/loop0
$ losetup -d /dev/loop1
$ losetup -d /dev/loop0
triggers a [ INFO: possible circular locking dependency detected ]
I think this warning is a false positive.
Open/close on a loop device acquires bd_mutex of the device before
acquiring lo_ctl_mutex of the same device. For ioctl(LOOP_CLR_FD) after
acquiring lo_ctl_mutex, fput on the backing_file might acquire the bd_mutex of
a device, if backing file is a device and this is the last reference to the
file being dropped . But it is guaranteed that it is impossible to have a
circular list of backing devices.(say loop2->loop1->loop0->loop2 is not
possible), which guarantees that this can never deadlock.
So this warning should be suppressed. It is very difficult to annotate lockdep
not to warn here in the correct way. A simple way to silence lockdep could be
to mark the lo_ctl_mutex in ioctl to be a sub class, but this might mask some
other real bugs.
@@ -1164,7 +1164,7 @@ static int lo_ioctl(struct block_device *bdev, fmode_t mode,
struct loop_device *lo = bdev->bd_disk->private_data;
int err;
- mutex_lock(&lo->lo_ctl_mutex);
+ mutex_lock_nested(&lo->lo_ctl_mutex, 1);
switch (cmd) {
case LOOP_SET_FD:
err = loop_set_fd(lo, mode, bdev, arg);
Or actually marking the bd_mutex after lo_ctl_mutex as a sub class could be
a better solution.
Luckily it is easy to avoid calling fput on backing file with lo_ctl_mutex
held, so no lockdep annotation is required.
If you do not like the special handling of the lo_ctl_mutex just for the
LOOP_CLR_FD ioctl in lo_ioctl(), the mutex handling could be moved inside
each of the individual ioctl handlers and I could send you another patch.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-03-24 14:33:41 +03:00
|
|
|
|
|
|
|
out_unlocked:
|
2005-04-17 02:20:36 +04:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2006-08-29 22:06:14 +04:00
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
struct compat_loop_info {
|
|
|
|
compat_int_t lo_number; /* ioctl r/o */
|
|
|
|
compat_dev_t lo_device; /* ioctl r/o */
|
|
|
|
compat_ulong_t lo_inode; /* ioctl r/o */
|
|
|
|
compat_dev_t lo_rdevice; /* ioctl r/o */
|
|
|
|
compat_int_t lo_offset;
|
|
|
|
compat_int_t lo_encrypt_type;
|
|
|
|
compat_int_t lo_encrypt_key_size; /* ioctl w/o */
|
|
|
|
compat_int_t lo_flags; /* ioctl r/o */
|
|
|
|
char lo_name[LO_NAME_SIZE];
|
|
|
|
unsigned char lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
|
|
|
|
compat_ulong_t lo_init[2];
|
|
|
|
char reserved[4];
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Transfer 32-bit compatibility structure in userspace to 64-bit loop info
|
|
|
|
* - noinlined to reduce stack space usage in main part of driver
|
|
|
|
*/
|
|
|
|
static noinline int
|
2006-10-11 01:48:27 +04:00
|
|
|
loop_info64_from_compat(const struct compat_loop_info __user *arg,
|
2006-08-29 22:06:14 +04:00
|
|
|
struct loop_info64 *info64)
|
|
|
|
{
|
|
|
|
struct compat_loop_info info;
|
|
|
|
|
|
|
|
if (copy_from_user(&info, arg, sizeof(info)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
memset(info64, 0, sizeof(*info64));
|
|
|
|
info64->lo_number = info.lo_number;
|
|
|
|
info64->lo_device = info.lo_device;
|
|
|
|
info64->lo_inode = info.lo_inode;
|
|
|
|
info64->lo_rdevice = info.lo_rdevice;
|
|
|
|
info64->lo_offset = info.lo_offset;
|
|
|
|
info64->lo_sizelimit = 0;
|
|
|
|
info64->lo_encrypt_type = info.lo_encrypt_type;
|
|
|
|
info64->lo_encrypt_key_size = info.lo_encrypt_key_size;
|
|
|
|
info64->lo_flags = info.lo_flags;
|
|
|
|
info64->lo_init[0] = info.lo_init[0];
|
|
|
|
info64->lo_init[1] = info.lo_init[1];
|
|
|
|
if (info.lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
|
|
|
|
memcpy(info64->lo_crypt_name, info.lo_name, LO_NAME_SIZE);
|
|
|
|
else
|
|
|
|
memcpy(info64->lo_file_name, info.lo_name, LO_NAME_SIZE);
|
|
|
|
memcpy(info64->lo_encrypt_key, info.lo_encrypt_key, LO_KEY_SIZE);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Transfer 64-bit loop info to 32-bit compatibility structure in userspace
|
|
|
|
* - noinlined to reduce stack space usage in main part of driver
|
|
|
|
*/
|
|
|
|
static noinline int
|
|
|
|
loop_info64_to_compat(const struct loop_info64 *info64,
|
|
|
|
struct compat_loop_info __user *arg)
|
|
|
|
{
|
|
|
|
struct compat_loop_info info;
|
|
|
|
|
|
|
|
memset(&info, 0, sizeof(info));
|
|
|
|
info.lo_number = info64->lo_number;
|
|
|
|
info.lo_device = info64->lo_device;
|
|
|
|
info.lo_inode = info64->lo_inode;
|
|
|
|
info.lo_rdevice = info64->lo_rdevice;
|
|
|
|
info.lo_offset = info64->lo_offset;
|
|
|
|
info.lo_encrypt_type = info64->lo_encrypt_type;
|
|
|
|
info.lo_encrypt_key_size = info64->lo_encrypt_key_size;
|
|
|
|
info.lo_flags = info64->lo_flags;
|
|
|
|
info.lo_init[0] = info64->lo_init[0];
|
|
|
|
info.lo_init[1] = info64->lo_init[1];
|
|
|
|
if (info.lo_encrypt_type == LO_CRYPT_CRYPTOAPI)
|
|
|
|
memcpy(info.lo_name, info64->lo_crypt_name, LO_NAME_SIZE);
|
|
|
|
else
|
|
|
|
memcpy(info.lo_name, info64->lo_file_name, LO_NAME_SIZE);
|
|
|
|
memcpy(info.lo_encrypt_key, info64->lo_encrypt_key, LO_KEY_SIZE);
|
|
|
|
|
|
|
|
/* error in case values were truncated */
|
|
|
|
if (info.lo_device != info64->lo_device ||
|
|
|
|
info.lo_rdevice != info64->lo_rdevice ||
|
|
|
|
info.lo_inode != info64->lo_inode ||
|
|
|
|
info.lo_offset != info64->lo_offset ||
|
|
|
|
info.lo_init[0] != info64->lo_init[0] ||
|
|
|
|
info.lo_init[1] != info64->lo_init[1])
|
|
|
|
return -EOVERFLOW;
|
|
|
|
|
|
|
|
if (copy_to_user(arg, &info, sizeof(info)))
|
|
|
|
return -EFAULT;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_set_status_compat(struct loop_device *lo,
|
|
|
|
const struct compat_loop_info __user *arg)
|
|
|
|
{
|
|
|
|
struct loop_info64 info64;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = loop_info64_from_compat(arg, &info64);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
return loop_set_status(lo, &info64);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
loop_get_status_compat(struct loop_device *lo,
|
|
|
|
struct compat_loop_info __user *arg)
|
|
|
|
{
|
|
|
|
struct loop_info64 info64;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (!arg)
|
|
|
|
err = -EINVAL;
|
|
|
|
if (!err)
|
|
|
|
err = loop_get_status(lo, &info64);
|
|
|
|
if (!err)
|
|
|
|
err = loop_info64_to_compat(&info64, arg);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2008-03-02 17:29:48 +03:00
|
|
|
static int lo_compat_ioctl(struct block_device *bdev, fmode_t mode,
|
|
|
|
unsigned int cmd, unsigned long arg)
|
2006-08-29 22:06:14 +04:00
|
|
|
{
|
2008-03-02 17:29:48 +03:00
|
|
|
struct loop_device *lo = bdev->bd_disk->private_data;
|
2006-08-29 22:06:14 +04:00
|
|
|
int err;
|
|
|
|
|
|
|
|
switch(cmd) {
|
|
|
|
case LOOP_SET_STATUS:
|
|
|
|
mutex_lock(&lo->lo_ctl_mutex);
|
|
|
|
err = loop_set_status_compat(
|
|
|
|
lo, (const struct compat_loop_info __user *) arg);
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
break;
|
|
|
|
case LOOP_GET_STATUS:
|
|
|
|
mutex_lock(&lo->lo_ctl_mutex);
|
|
|
|
err = loop_get_status_compat(
|
|
|
|
lo, (struct compat_loop_info __user *) arg);
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
break;
|
loop: add ioctl to resize a loop device
Add the ability to 'resize' the loop device on the fly.
One practical application is a loop file with XFS filesystem, already
mounted: You can easily enlarge the file (append some bytes) and then call
ioctl(fd, LOOP_SET_CAPACITY, new); The loop driver will learn about the
new size and you can use xfs_growfs later on, which will allow you to use
full capacity of the loop file without the need to unmount.
Test app:
#include <linux/fs.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <assert.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define _GNU_SOURCE
#include <getopt.h>
char *me;
void usage(FILE *f)
{
fprintf(f, "%s [options] loop_dev [backend_file]\n"
"-s, --set new_size_in_bytes\n"
"\twhen backend_file is given, "
"it will be expanded too while keeping the original contents\n",
me);
}
struct option opts[] = {
{
.name = "set",
.has_arg = 1,
.flag = NULL,
.val = 's'
},
{
.name = "help",
.has_arg = 0,
.flag = NULL,
.val = 'h'
}
};
void err_size(char *name, __u64 old)
{
fprintf(stderr, "size must be larger than current %s (%llu)\n",
name, old);
}
int main(int argc, char *argv[])
{
int fd, err, c, i, bfd;
ssize_t ssz;
size_t sz;
__u64 old, new, append;
char a[BUFSIZ];
struct stat st;
FILE *out;
char *backend, *dev;
err = EINVAL;
out = stderr;
me = argv[0];
new = 0;
while ((c = getopt_long(argc, argv, "s:h", opts, &i)) != -1) {
switch (c) {
case 's':
errno = 0;
new = strtoull(optarg, NULL, 0);
if (errno) {
err = errno;
perror(argv[i]);
goto out;
}
break;
case 'h':
err = 0;
out = stdout;
goto err;
default:
perror(argv[i]);
goto err;
}
}
if (optind < argc)
dev = argv[optind++];
else
goto err;
fd = open(dev, O_RDONLY);
if (fd < 0) {
err = errno;
perror(dev);
goto out;
}
err = ioctl(fd, BLKGETSIZE64, &old);
if (err) {
err = errno;
perror("ioctl BLKGETSIZE64");
goto out;
}
if (!new) {
printf("%llu\n", old);
goto out;
}
if (new < old) {
err = EINVAL;
err_size(dev, old);
goto out;
}
if (optind < argc) {
backend = argv[optind++];
bfd = open(backend, O_WRONLY|O_APPEND);
if (bfd < 0) {
err = errno;
perror(backend);
goto out;
}
err = fstat(bfd, &st);
if (err) {
err = errno;
perror(backend);
goto out;
}
if (new < st.st_size) {
err = EINVAL;
err_size(backend, st.st_size);
goto out;
}
append = new - st.st_size;
sz = sizeof(a);
while (append > 0) {
if (append < sz)
sz = append;
ssz = write(bfd, a, sz);
if (ssz != sz) {
err = errno;
perror(backend);
goto out;
}
append -= sz;
}
err = fsync(bfd);
if (err) {
err = errno;
perror(backend);
goto out;
}
}
err = ioctl(fd, LOOP_SET_CAPACITY, new);
if (err) {
err = errno;
perror("ioctl LOOP_SET_CAPACITY");
}
goto out;
err:
usage(out);
out:
return err;
}
Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Signed-off-by: Tomas Matejicek <tomas@slax.org>
Cc: <util-linux-ng@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <linux-api@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 02:23:43 +04:00
|
|
|
case LOOP_SET_CAPACITY:
|
2006-08-29 22:06:14 +04:00
|
|
|
case LOOP_CLR_FD:
|
|
|
|
case LOOP_GET_STATUS64:
|
|
|
|
case LOOP_SET_STATUS64:
|
|
|
|
arg = (unsigned long) compat_ptr(arg);
|
|
|
|
case LOOP_SET_FD:
|
|
|
|
case LOOP_CHANGE_FD:
|
2008-03-02 17:29:48 +03:00
|
|
|
err = lo_ioctl(bdev, mode, cmd, arg);
|
2006-08-29 22:06:14 +04:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
err = -ENOIOCTLCMD;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-03-02 17:29:48 +03:00
|
|
|
static int lo_open(struct block_device *bdev, fmode_t mode)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
struct loop_device *lo;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
mutex_lock(&loop_index_mutex);
|
|
|
|
lo = bdev->bd_disk->private_data;
|
|
|
|
if (!lo) {
|
|
|
|
err = -ENXIO;
|
|
|
|
goto out;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-05-06 07:26:23 +03:00
|
|
|
atomic_inc(&lo->lo_refcnt);
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
out:
|
|
|
|
mutex_unlock(&loop_index_mutex);
|
|
|
|
return err;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2018-01-06 03:26:00 +03:00
|
|
|
static void __lo_release(struct loop_device *lo)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2009-04-07 15:48:21 +04:00
|
|
|
int err;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2015-05-06 07:26:23 +03:00
|
|
|
if (atomic_dec_return(&lo->lo_refcnt))
|
|
|
|
return;
|
2008-12-12 16:48:27 +03:00
|
|
|
|
2015-05-06 07:26:23 +03:00
|
|
|
mutex_lock(&lo->lo_ctl_mutex);
|
2008-12-12 16:48:27 +03:00
|
|
|
if (lo->lo_flags & LO_FLAGS_AUTOCLEAR) {
|
|
|
|
/*
|
|
|
|
* In autoclear mode, stop the loop thread
|
|
|
|
* and remove configuration after last close.
|
|
|
|
*/
|
2011-09-21 12:02:13 +04:00
|
|
|
err = loop_clr_fd(lo);
|
2009-04-07 15:48:21 +04:00
|
|
|
if (!err)
|
2013-05-06 05:52:57 +04:00
|
|
|
return;
|
2017-08-24 10:03:44 +03:00
|
|
|
} else if (lo->lo_state == Lo_bound) {
|
2008-12-12 16:48:27 +03:00
|
|
|
/*
|
|
|
|
* Otherwise keep thread (if running) and config,
|
|
|
|
* but flush possible ongoing bios in thread.
|
|
|
|
*/
|
2017-08-24 10:03:44 +03:00
|
|
|
blk_mq_freeze_queue(lo->lo_queue);
|
|
|
|
blk_mq_unfreeze_queue(lo->lo_queue);
|
2008-12-12 16:48:27 +03:00
|
|
|
}
|
2008-02-06 12:36:27 +03:00
|
|
|
|
2006-03-23 14:00:38 +03:00
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2018-01-06 03:26:00 +03:00
|
|
|
static void lo_release(struct gendisk *disk, fmode_t mode)
|
|
|
|
{
|
|
|
|
mutex_lock(&loop_index_mutex);
|
|
|
|
__lo_release(disk->private_data);
|
|
|
|
mutex_unlock(&loop_index_mutex);
|
|
|
|
}
|
|
|
|
|
2009-09-22 04:01:13 +04:00
|
|
|
static const struct block_device_operations lo_fops = {
|
2005-04-17 02:20:36 +04:00
|
|
|
.owner = THIS_MODULE,
|
2008-03-02 17:29:48 +03:00
|
|
|
.open = lo_open,
|
|
|
|
.release = lo_release,
|
|
|
|
.ioctl = lo_ioctl,
|
2006-08-29 22:06:14 +04:00
|
|
|
#ifdef CONFIG_COMPAT
|
2008-03-02 17:29:48 +03:00
|
|
|
.compat_ioctl = lo_compat_ioctl,
|
2006-08-29 22:06:14 +04:00
|
|
|
#endif
|
2005-04-17 02:20:36 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And now the modules code and kernel interface.
|
|
|
|
*/
|
2007-05-08 11:28:20 +04:00
|
|
|
static int max_loop;
|
2011-05-27 09:59:25 +04:00
|
|
|
module_param(max_loop, int, S_IRUGO);
|
2007-06-09 00:46:44 +04:00
|
|
|
MODULE_PARM_DESC(max_loop, "Maximum number of loop devices");
|
2011-05-27 09:59:25 +04:00
|
|
|
module_param(max_part, int, S_IRUGO);
|
loop: manage partitions in disk image
This patch allows to use loop device with partitionned disk image.
Original behavior of loop is not modified.
A new parameter is introduced to define how many partition we want to be
able to manage per loop device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
# modprobe loop max_part=63
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
And to attach a raw partitionned disk image, the original losetup is used:
# losetup -f etch.img
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-03-05 14:57 /dev/loop0p1
brw-rw---- 1 root disk 7, 2 2008-03-05 14:57 /dev/loop0p2
brw-rw---- 1 root disk 7, 5 2008-03-05 14:57 /dev/loop0p5
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /mnt
bench cdrom home lib mnt root srv usr
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
# umount /mnt
# losetup -d /dev/loop0
Of course, the same behavior can be done using kpartx on a loop device,
but modifying loop avoids to stack several layers of block device (loop +
device mapper), this is a very light modification (40% of modifications
are to manage the new parameter).
Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-03-26 14:11:53 +03:00
|
|
|
MODULE_PARM_DESC(max_part, "Maximum number of partitions per loop device");
|
2005-04-17 02:20:36 +04:00
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
|
|
|
|
|
|
|
|
int loop_register_transfer(struct loop_func_table *funcs)
|
|
|
|
{
|
|
|
|
unsigned int n = funcs->number;
|
|
|
|
|
|
|
|
if (n >= MAX_LO_CRYPT || xfer_funcs[n])
|
|
|
|
return -EINVAL;
|
|
|
|
xfer_funcs[n] = funcs;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
static int unregister_transfer_cb(int id, void *ptr, void *data)
|
|
|
|
{
|
|
|
|
struct loop_device *lo = ptr;
|
|
|
|
struct loop_func_table *xfer = data;
|
|
|
|
|
|
|
|
mutex_lock(&lo->lo_ctl_mutex);
|
|
|
|
if (lo->lo_encryption == xfer)
|
|
|
|
loop_release_xfer(lo);
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
int loop_unregister_transfer(int number)
|
|
|
|
{
|
|
|
|
unsigned int n = number;
|
|
|
|
struct loop_func_table *xfer;
|
|
|
|
|
|
|
|
if (n == 0 || n >= MAX_LO_CRYPT || (xfer = xfer_funcs[n]) == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
xfer_funcs[n] = NULL;
|
2011-08-01 00:08:04 +04:00
|
|
|
idr_for_each(&loop_index_idr, &unregister_transfer_cb, xfer);
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(loop_register_transfer);
|
|
|
|
EXPORT_SYMBOL(loop_unregister_transfer);
|
|
|
|
|
2017-06-03 10:38:05 +03:00
|
|
|
static blk_status_t loop_queue_rq(struct blk_mq_hw_ctx *hctx,
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
const struct blk_mq_queue_data *bd)
|
|
|
|
{
|
|
|
|
struct loop_cmd *cmd = blk_mq_rq_to_pdu(bd->rq);
|
2015-05-05 14:49:54 +03:00
|
|
|
struct loop_device *lo = cmd->rq->q->queuedata;
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
|
|
|
|
blk_mq_start_request(bd->rq);
|
|
|
|
|
2015-05-05 14:49:54 +03:00
|
|
|
if (lo->lo_state != Lo_bound)
|
2017-06-03 10:38:05 +03:00
|
|
|
return BLK_STS_IOERR;
|
2015-05-05 14:49:54 +03:00
|
|
|
|
2016-08-04 17:10:00 +03:00
|
|
|
switch (req_op(cmd->rq)) {
|
|
|
|
case REQ_OP_FLUSH:
|
|
|
|
case REQ_OP_DISCARD:
|
2017-04-05 20:21:15 +03:00
|
|
|
case REQ_OP_WRITE_ZEROES:
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
cmd->use_aio = false;
|
2016-08-04 17:10:00 +03:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
cmd->use_aio = lo->use_dio;
|
|
|
|
break;
|
|
|
|
}
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
|
2017-09-25 22:07:22 +03:00
|
|
|
/* always use the first bio's css */
|
2017-09-26 21:02:12 +03:00
|
|
|
#ifdef CONFIG_BLK_CGROUP
|
2017-09-25 22:07:22 +03:00
|
|
|
if (cmd->use_aio && cmd->rq->bio && cmd->rq->bio->bi_css) {
|
|
|
|
cmd->css = cmd->rq->bio->bi_css;
|
|
|
|
css_get(cmd->css);
|
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
cmd->css = NULL;
|
2016-10-11 23:55:20 +03:00
|
|
|
kthread_queue_work(&lo->worker, &cmd->work);
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
|
2017-06-03 10:38:05 +03:00
|
|
|
return BLK_STS_OK;
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void loop_handle_cmd(struct loop_cmd *cmd)
|
|
|
|
{
|
2016-06-05 22:31:45 +03:00
|
|
|
const bool write = op_is_write(req_op(cmd->rq));
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
struct loop_device *lo = cmd->rq->q->queuedata;
|
2015-09-27 22:01:50 +03:00
|
|
|
int ret = 0;
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
|
2015-09-27 22:01:50 +03:00
|
|
|
if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY)) {
|
|
|
|
ret = -EIO;
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
goto failed;
|
2015-09-27 22:01:50 +03:00
|
|
|
}
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
|
2014-12-31 16:22:58 +03:00
|
|
|
ret = do_req_filebacked(lo, cmd->rq);
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
failed:
|
block: loop: support DIO & AIO
There are at least 3 advantages to use direct I/O and AIO on
read/write loop's backing file:
1) double cache can be avoided, then memory usage gets
decreased a lot
2) not like user space direct I/O, there isn't cost of
pinning pages
3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O top throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime
xfstests(-g auto, ext4) is basically passed when running with
direct I/O(aio), one exception is generic/232, but it failed in
loop buffered I/O(4.2-rc6-next-20150814) too.
Follows the fio test result for performance purpose:
4 jobs fio test inside ext4 file system over loop block
1) How to run
- KVM: 4 VCPUs, 2G RAM
- linux kernel: 4.2-rc6-next-20150814(base) with the patchset
- the loop block is over one image on SSD.
- linux psync, 4 jobs, size 1500M, ext4 over loop block
- test result: IOPS from fio output
2) Throughput(IOPS) becomes a bit better with direct I/O(aio)
-------------------------------------------------------------
test cases |randread |read |randwrite |write |
-------------------------------------------------------------
base |8015 |113811 |67442 |106978
-------------------------------------------------------------
base+loop aio |8136 |125040 |67811 |111376
-------------------------------------------------------------
- somehow, it should be caused by more page cache avaiable for
application or one extra page copy is avoided in case of direct I/O
3) context switch
- context switch decreased by ~50% with loop direct I/O(aio)
compared with loop buffered I/O(4.2-rc6-next-20150814)
4) memory usage from /proc/meminfo
-------------------------------------------------------------
| Buffers | Cached
-------------------------------------------------------------
base | > 760MB | ~950MB
-------------------------------------------------------------
base+loop direct I/O(aio) | < 5MB | ~1.6GB
-------------------------------------------------------------
- so there are much more page caches available for application with
direct I/O
[1] https://lwn.net/Articles/612483/
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-08-17 05:31:51 +03:00
|
|
|
/* complete non-aio request */
|
2017-04-20 17:03:02 +03:00
|
|
|
if (!cmd->use_aio || ret) {
|
|
|
|
cmd->ret = ret ? -EIO : 0;
|
2017-04-20 17:03:09 +03:00
|
|
|
blk_mq_complete_request(cmd->rq);
|
2017-04-20 17:03:02 +03:00
|
|
|
}
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
}
|
|
|
|
|
2015-08-17 05:31:48 +03:00
|
|
|
static void loop_queue_work(struct kthread_work *work)
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
{
|
|
|
|
struct loop_cmd *cmd =
|
2015-08-17 05:31:48 +03:00
|
|
|
container_of(work, struct loop_cmd, work);
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
|
|
|
|
loop_handle_cmd(cmd);
|
|
|
|
}
|
|
|
|
|
2017-05-01 19:19:08 +03:00
|
|
|
static int loop_init_request(struct blk_mq_tag_set *set, struct request *rq,
|
|
|
|
unsigned int hctx_idx, unsigned int numa_node)
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
{
|
|
|
|
struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
|
|
|
|
|
|
|
|
cmd->rq = rq;
|
2016-10-11 23:55:20 +03:00
|
|
|
kthread_init_work(&cmd->work, loop_queue_work);
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-30 23:39:16 +03:00
|
|
|
static const struct blk_mq_ops loop_mq_ops = {
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
.queue_rq = loop_queue_rq,
|
|
|
|
.init_request = loop_init_request,
|
2017-04-20 17:03:02 +03:00
|
|
|
.complete = lo_complete_rq,
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
};
|
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
static int loop_add(struct loop_device **l, int i)
|
2007-05-08 11:28:20 +04:00
|
|
|
{
|
|
|
|
struct loop_device *lo;
|
|
|
|
struct gendisk *disk;
|
2011-08-01 00:08:04 +04:00
|
|
|
int err;
|
2007-05-08 11:28:20 +04:00
|
|
|
|
2012-07-15 02:39:58 +04:00
|
|
|
err = -ENOMEM;
|
2007-05-08 11:28:20 +04:00
|
|
|
lo = kzalloc(sizeof(*lo), GFP_KERNEL);
|
2012-07-15 02:39:58 +04:00
|
|
|
if (!lo)
|
2007-05-08 11:28:20 +04:00
|
|
|
goto out;
|
2011-08-01 00:08:04 +04:00
|
|
|
|
2013-10-16 00:14:38 +04:00
|
|
|
lo->lo_state = Lo_unbound;
|
|
|
|
|
2013-02-28 05:03:58 +04:00
|
|
|
/* allocate id, if @id >= 0, we're requesting that specific id */
|
2011-08-01 00:08:04 +04:00
|
|
|
if (i >= 0) {
|
2013-02-28 05:03:58 +04:00
|
|
|
err = idr_alloc(&loop_index_idr, lo, i, i + 1, GFP_KERNEL);
|
|
|
|
if (err == -ENOSPC)
|
2011-08-01 00:08:04 +04:00
|
|
|
err = -EEXIST;
|
|
|
|
} else {
|
2013-02-28 05:03:58 +04:00
|
|
|
err = idr_alloc(&loop_index_idr, lo, 0, 0, GFP_KERNEL);
|
2011-08-01 00:08:04 +04:00
|
|
|
}
|
|
|
|
if (err < 0)
|
|
|
|
goto out_free_dev;
|
2013-02-28 05:03:58 +04:00
|
|
|
i = err;
|
2007-05-08 11:28:20 +04:00
|
|
|
|
2013-03-22 18:59:19 +04:00
|
|
|
err = -ENOMEM;
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
lo->tag_set.ops = &loop_mq_ops;
|
|
|
|
lo->tag_set.nr_hw_queues = 1;
|
|
|
|
lo->tag_set.queue_depth = 128;
|
|
|
|
lo->tag_set.numa_node = NUMA_NO_NODE;
|
|
|
|
lo->tag_set.cmd_size = sizeof(struct loop_cmd);
|
|
|
|
lo->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE;
|
|
|
|
lo->tag_set.driver_data = lo;
|
|
|
|
|
|
|
|
err = blk_mq_alloc_tag_set(&lo->tag_set);
|
|
|
|
if (err)
|
2013-10-14 20:12:24 +04:00
|
|
|
goto out_free_idr;
|
2007-05-08 11:28:20 +04:00
|
|
|
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
lo->lo_queue = blk_mq_init_queue(&lo->tag_set);
|
|
|
|
if (IS_ERR_OR_NULL(lo->lo_queue)) {
|
|
|
|
err = PTR_ERR(lo->lo_queue);
|
|
|
|
goto out_cleanup_tags;
|
|
|
|
}
|
2013-10-16 00:14:38 +04:00
|
|
|
lo->lo_queue->queuedata = lo;
|
|
|
|
|
2017-09-01 08:09:45 +03:00
|
|
|
blk_queue_max_hw_sectors(lo->lo_queue, BLK_DEF_MAX_SECTORS);
|
2017-09-01 08:09:46 +03:00
|
|
|
|
2015-08-17 05:31:47 +03:00
|
|
|
/*
|
2017-09-01 08:09:46 +03:00
|
|
|
* By default, we do buffer IO, so it doesn't make sense to enable
|
|
|
|
* merge because the I/O submitted to backing file is handled page by
|
|
|
|
* page. For directio mode, merge does help to dispatch bigger request
|
|
|
|
* to underlayer disk. We will enable merge once directio is enabled.
|
2015-08-17 05:31:47 +03:00
|
|
|
*/
|
|
|
|
queue_flag_set_unlocked(QUEUE_FLAG_NOMERGES, lo->lo_queue);
|
|
|
|
|
2016-06-07 05:05:15 +03:00
|
|
|
err = -ENOMEM;
|
loop: manage partitions in disk image
This patch allows to use loop device with partitionned disk image.
Original behavior of loop is not modified.
A new parameter is introduced to define how many partition we want to be
able to manage per loop device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
# modprobe loop max_part=63
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
And to attach a raw partitionned disk image, the original losetup is used:
# losetup -f etch.img
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-03-05 14:57 /dev/loop0p1
brw-rw---- 1 root disk 7, 2 2008-03-05 14:57 /dev/loop0p2
brw-rw---- 1 root disk 7, 5 2008-03-05 14:57 /dev/loop0p5
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /mnt
bench cdrom home lib mnt root srv usr
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
# umount /mnt
# losetup -d /dev/loop0
Of course, the same behavior can be done using kpartx on a loop device,
but modifying loop avoids to stack several layers of block device (loop +
device mapper), this is a very light modification (40% of modifications
are to manage the new parameter).
Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-03-26 14:11:53 +03:00
|
|
|
disk = lo->lo_disk = alloc_disk(1 << part_shift);
|
2007-05-08 11:28:20 +04:00
|
|
|
if (!disk)
|
|
|
|
goto out_free_queue;
|
|
|
|
|
loop: always allow userspace partitions and optionally support automatic scanning
Automatic partition scanning can be requested individually per loop
device during its setup by setting LO_FLAGS_PARTSCAN. By default, no
partition tables are scanned.
Userspace can now always add and remove partitions from all loop
devices, regardless if the in-kernel partition scanner is enabled or
not.
The needed partition minor numbers are allocated from the extended
minors space, the main loop device numbers will continue to match the
loop minors, regardless of the number of partitions used.
# grep . /sys/class/block/loop1/loop/*
/sys/block/loop1/loop/autoclear:0
/sys/block/loop1/loop/backing_file:/home/kay/data/stuff/part.img
/sys/block/loop1/loop/offset:0
/sys/block/loop1/loop/partscan:1
/sys/block/loop1/loop/sizelimit:0
# ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 14 20:22 /dev/loop0
brw-rw---- 1 root disk 7, 1 Aug 14 20:23 /dev/loop1
brw-rw---- 1 root disk 259, 0 Aug 14 20:23 /dev/loop1p1
brw-rw---- 1 root disk 259, 1 Aug 14 20:23 /dev/loop1p2
brw-rw---- 1 root disk 7, 99 Aug 14 20:23 /dev/loop99
brw-rw---- 1 root disk 259, 2 Aug 14 20:23 /dev/loop99p1
brw-rw---- 1 root disk 259, 3 Aug 14 20:23 /dev/loop99p2
crw------T 1 root root 10, 237 Aug 14 20:22 /dev/loop-control
Cc: Karel Zak <kzak@redhat.com>
Cc: Davidlohr Bueso <dave@gnu.org>
Acked-By: Tejun Heo <tj@kernel.org>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-23 22:12:04 +04:00
|
|
|
/*
|
|
|
|
* Disable partition scanning by default. The in-kernel partition
|
|
|
|
* scanning can be requested individually per-device during its
|
|
|
|
* setup. Userspace can always add and remove partitions from all
|
|
|
|
* devices. The needed partition minors are allocated from the
|
|
|
|
* extended minor space, the main loop device numbers will continue
|
|
|
|
* to match the loop minors, regardless of the number of partitions
|
|
|
|
* used.
|
|
|
|
*
|
|
|
|
* If max_part is given, partition scanning is globally enabled for
|
|
|
|
* all loop devices. The minors for the main loop devices will be
|
|
|
|
* multiples of max_part.
|
|
|
|
*
|
|
|
|
* Note: Global-for-all-devices, set-only-at-init, read-only module
|
|
|
|
* parameteters like 'max_loop' and 'max_part' make things needlessly
|
|
|
|
* complicated, are too static, inflexible and may surprise
|
|
|
|
* userspace tools. Parameters like this in general should be avoided.
|
|
|
|
*/
|
|
|
|
if (!part_shift)
|
|
|
|
disk->flags |= GENHD_FL_NO_PART_SCAN;
|
|
|
|
disk->flags |= GENHD_FL_EXT_DEVT;
|
2007-05-08 11:28:20 +04:00
|
|
|
mutex_init(&lo->lo_ctl_mutex);
|
2015-05-06 07:26:23 +03:00
|
|
|
atomic_set(&lo->lo_refcnt, 0);
|
2007-05-08 11:28:20 +04:00
|
|
|
lo->lo_number = i;
|
|
|
|
spin_lock_init(&lo->lo_lock);
|
|
|
|
disk->major = LOOP_MAJOR;
|
loop: manage partitions in disk image
This patch allows to use loop device with partitionned disk image.
Original behavior of loop is not modified.
A new parameter is introduced to define how many partition we want to be
able to manage per loop device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
# modprobe loop max_part=63
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
And to attach a raw partitionned disk image, the original losetup is used:
# losetup -f etch.img
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-03-05 14:57 /dev/loop0p1
brw-rw---- 1 root disk 7, 2 2008-03-05 14:57 /dev/loop0p2
brw-rw---- 1 root disk 7, 5 2008-03-05 14:57 /dev/loop0p5
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /mnt
bench cdrom home lib mnt root srv usr
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
# umount /mnt
# losetup -d /dev/loop0
Of course, the same behavior can be done using kpartx on a loop device,
but modifying loop avoids to stack several layers of block device (loop +
device mapper), this is a very light modification (40% of modifications
are to manage the new parameter).
Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-03-26 14:11:53 +03:00
|
|
|
disk->first_minor = i << part_shift;
|
2007-05-08 11:28:20 +04:00
|
|
|
disk->fops = &lo_fops;
|
|
|
|
disk->private_data = lo;
|
|
|
|
disk->queue = lo->lo_queue;
|
|
|
|
sprintf(disk->disk_name, "loop%d", i);
|
2011-08-01 00:08:04 +04:00
|
|
|
add_disk(disk);
|
|
|
|
*l = lo;
|
|
|
|
return lo->lo_number;
|
2007-05-08 11:28:20 +04:00
|
|
|
|
|
|
|
out_free_queue:
|
|
|
|
blk_cleanup_queue(lo->lo_queue);
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
out_cleanup_tags:
|
|
|
|
blk_mq_free_tag_set(&lo->tag_set);
|
2013-10-14 20:12:24 +04:00
|
|
|
out_free_idr:
|
|
|
|
idr_remove(&loop_index_idr, i);
|
2007-05-08 11:28:20 +04:00
|
|
|
out_free_dev:
|
|
|
|
kfree(lo);
|
|
|
|
out:
|
2011-08-01 00:08:04 +04:00
|
|
|
return err;
|
2007-05-08 11:28:20 +04:00
|
|
|
}
|
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
static void loop_remove(struct loop_device *lo)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2007-05-08 11:28:20 +04:00
|
|
|
blk_cleanup_queue(lo->lo_queue);
|
2015-04-27 07:12:22 +03:00
|
|
|
del_gendisk(lo->lo_disk);
|
block: loop: improve performance via blk-mq
The conversion is a bit straightforward, and use work queue to
dispatch requests of loop block, and one big change is that requests
is submitted to backend file/device concurrently with work queue,
so throughput may get improved much. Given write requests over same
file are often run exclusively, so don't handle them concurrently for
avoiding extra context switch cost, possible lock contention and work
schedule cost. Also with blk-mq, there is opportunity to get loop I/O
merged before submitting to backend file/device.
In the following test:
- base: v3.19-rc2-2041231
- loop over file in ext4 file system on SSD disk
- bs: 4k, libaio, io depth: 64, O_DIRECT, num of jobs: 1
- throughput: IOPS
------------------------------------------------------
| | base | base with loop-mq | delta |
------------------------------------------------------
| randread | 1740 | 25318 | +1355%|
------------------------------------------------------
| read | 42196 | 51771 | +22.6%|
-----------------------------------------------------
| randwrite | 35709 | 34624 | -3% |
-----------------------------------------------------
| write | 39137 | 40326 | +3% |
-----------------------------------------------------
So loop-mq can improve throughput for both read and randread, meantime,
performance of write and randwrite isn't hurted basically.
Another benefit is that loop driver code gets simplified
much after blk-mq conversion, and the patch can be thought as
cleanup too.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-31 16:22:57 +03:00
|
|
|
blk_mq_free_tag_set(&lo->tag_set);
|
2007-05-08 11:28:20 +04:00
|
|
|
put_disk(lo->lo_disk);
|
|
|
|
kfree(lo);
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
static int find_free_cb(int id, void *ptr, void *data)
|
|
|
|
{
|
|
|
|
struct loop_device *lo = ptr;
|
|
|
|
struct loop_device **l = data;
|
|
|
|
|
|
|
|
if (lo->lo_state == Lo_unbound) {
|
|
|
|
*l = lo;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
static int loop_lookup(struct loop_device **l, int i)
|
2007-06-09 00:46:44 +04:00
|
|
|
{
|
|
|
|
struct loop_device *lo;
|
2011-08-01 00:08:04 +04:00
|
|
|
int ret = -ENODEV;
|
2007-06-09 00:46:44 +04:00
|
|
|
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
if (i < 0) {
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = idr_for_each(&loop_index_idr, &find_free_cb, &lo);
|
|
|
|
if (err == 1) {
|
|
|
|
*l = lo;
|
|
|
|
ret = lo->lo_number;
|
|
|
|
}
|
|
|
|
goto out;
|
2007-06-09 00:46:44 +04:00
|
|
|
}
|
|
|
|
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
/* lookup and return a specific i */
|
2011-08-01 00:08:04 +04:00
|
|
|
lo = idr_find(&loop_index_idr, i);
|
2007-06-09 00:46:44 +04:00
|
|
|
if (lo) {
|
2011-08-01 00:08:04 +04:00
|
|
|
*l = lo;
|
|
|
|
ret = lo->lo_number;
|
2007-06-09 00:46:44 +04:00
|
|
|
}
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
out:
|
2011-08-01 00:08:04 +04:00
|
|
|
return ret;
|
2007-06-09 00:46:44 +04:00
|
|
|
}
|
|
|
|
|
2007-05-08 11:28:20 +04:00
|
|
|
static struct kobject *loop_probe(dev_t dev, int *part, void *data)
|
|
|
|
{
|
2007-05-13 13:52:32 +04:00
|
|
|
struct loop_device *lo;
|
2007-05-13 00:23:15 +04:00
|
|
|
struct kobject *kobj;
|
2011-08-01 00:08:04 +04:00
|
|
|
int err;
|
2007-05-08 11:28:20 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
mutex_lock(&loop_index_mutex);
|
|
|
|
err = loop_lookup(&lo, MINOR(dev) >> part_shift);
|
|
|
|
if (err < 0)
|
|
|
|
err = loop_add(&lo, MINOR(dev) >> part_shift);
|
|
|
|
if (err < 0)
|
2013-10-14 20:13:24 +04:00
|
|
|
kobj = NULL;
|
2011-08-01 00:08:04 +04:00
|
|
|
else
|
|
|
|
kobj = get_disk(lo->lo_disk);
|
|
|
|
mutex_unlock(&loop_index_mutex);
|
2007-05-08 11:28:20 +04:00
|
|
|
|
|
|
|
*part = 0;
|
2007-05-13 00:23:15 +04:00
|
|
|
return kobj;
|
2007-05-08 11:28:20 +04:00
|
|
|
}
|
|
|
|
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
static long loop_control_ioctl(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long parm)
|
|
|
|
{
|
|
|
|
struct loop_device *lo;
|
|
|
|
int ret = -ENOSYS;
|
|
|
|
|
|
|
|
mutex_lock(&loop_index_mutex);
|
|
|
|
switch (cmd) {
|
|
|
|
case LOOP_CTL_ADD:
|
|
|
|
ret = loop_lookup(&lo, parm);
|
|
|
|
if (ret >= 0) {
|
|
|
|
ret = -EEXIST;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ret = loop_add(&lo, parm);
|
|
|
|
break;
|
|
|
|
case LOOP_CTL_REMOVE:
|
|
|
|
ret = loop_lookup(&lo, parm);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
mutex_lock(&lo->lo_ctl_mutex);
|
|
|
|
if (lo->lo_state != Lo_unbound) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
break;
|
|
|
|
}
|
2015-05-06 07:26:23 +03:00
|
|
|
if (atomic_read(&lo->lo_refcnt) > 0) {
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
ret = -EBUSY;
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
lo->lo_disk->private_data = NULL;
|
|
|
|
mutex_unlock(&lo->lo_ctl_mutex);
|
|
|
|
idr_remove(&loop_index_idr, lo->lo_number);
|
|
|
|
loop_remove(lo);
|
|
|
|
break;
|
|
|
|
case LOOP_CTL_GET_FREE:
|
|
|
|
ret = loop_lookup(&lo, -1);
|
|
|
|
if (ret >= 0)
|
|
|
|
break;
|
|
|
|
ret = loop_add(&lo, -1);
|
|
|
|
}
|
|
|
|
mutex_unlock(&loop_index_mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations loop_ctl_fops = {
|
|
|
|
.open = nonseekable_open,
|
|
|
|
.unlocked_ioctl = loop_control_ioctl,
|
|
|
|
.compat_ioctl = loop_control_ioctl,
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.llseek = noop_llseek,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct miscdevice loop_misc = {
|
|
|
|
.minor = LOOP_CTRL_MINOR,
|
|
|
|
.name = "loop-control",
|
|
|
|
.fops = &loop_ctl_fops,
|
|
|
|
};
|
|
|
|
|
|
|
|
MODULE_ALIAS_MISCDEV(LOOP_CTRL_MINOR);
|
|
|
|
MODULE_ALIAS("devname:loop-control");
|
|
|
|
|
2007-05-08 11:28:20 +04:00
|
|
|
static int __init loop_init(void)
|
|
|
|
{
|
2007-06-09 00:46:44 +04:00
|
|
|
int i, nr;
|
|
|
|
unsigned long range;
|
2011-08-01 00:08:04 +04:00
|
|
|
struct loop_device *lo;
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
int err;
|
2007-06-09 00:46:44 +04:00
|
|
|
|
loop: manage partitions in disk image
This patch allows to use loop device with partitionned disk image.
Original behavior of loop is not modified.
A new parameter is introduced to define how many partition we want to be
able to manage per loop device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
# modprobe loop max_part=63
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
And to attach a raw partitionned disk image, the original losetup is used:
# losetup -f etch.img
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-03-05 14:57 /dev/loop0p1
brw-rw---- 1 root disk 7, 2 2008-03-05 14:57 /dev/loop0p2
brw-rw---- 1 root disk 7, 5 2008-03-05 14:57 /dev/loop0p5
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /mnt
bench cdrom home lib mnt root srv usr
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
# umount /mnt
# losetup -d /dev/loop0
Of course, the same behavior can be done using kpartx on a loop device,
but modifying loop avoids to stack several layers of block device (loop +
device mapper), this is a very light modification (40% of modifications
are to manage the new parameter).
Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-03-26 14:11:53 +03:00
|
|
|
part_shift = 0;
|
2011-05-27 09:59:25 +04:00
|
|
|
if (max_part > 0) {
|
loop: manage partitions in disk image
This patch allows to use loop device with partitionned disk image.
Original behavior of loop is not modified.
A new parameter is introduced to define how many partition we want to be
able to manage per loop device. This parameter is "max_part".
For instance, to manage 63 partitions / loop device, we will do:
# modprobe loop max_part=63
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
And to attach a raw partitionned disk image, the original losetup is used:
# losetup -f etch.img
# ls -l /dev/loop?*
brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0
brw-rw---- 1 root disk 7, 1 2008-03-05 14:57 /dev/loop0p1
brw-rw---- 1 root disk 7, 2 2008-03-05 14:57 /dev/loop0p2
brw-rw---- 1 root disk 7, 5 2008-03-05 14:57 /dev/loop0p5
brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1
brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2
brw-rw---- 1 root disk 7, 192 2008-03-05 14:55 /dev/loop3
brw-rw---- 1 root disk 7, 256 2008-03-05 14:55 /dev/loop4
brw-rw---- 1 root disk 7, 320 2008-03-05 14:55 /dev/loop5
brw-rw---- 1 root disk 7, 384 2008-03-05 14:55 /dev/loop6
brw-rw---- 1 root disk 7, 448 2008-03-05 14:55 /dev/loop7
# mount /dev/loop0p1 /mnt
# ls /mnt
bench cdrom home lib mnt root srv usr
bin dev initrd lost+found opt sbin sys var
boot etc initrd.img media proc selinux tmp vmlinuz
# umount /mnt
# losetup -d /dev/loop0
Of course, the same behavior can be done using kpartx on a loop device,
but modifying loop avoids to stack several layers of block device (loop +
device mapper), this is a very light modification (40% of modifications
are to manage the new parameter).
Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2008-03-26 14:11:53 +03:00
|
|
|
part_shift = fls(max_part);
|
|
|
|
|
2011-05-27 09:59:25 +04:00
|
|
|
/*
|
|
|
|
* Adjust max_part according to part_shift as it is exported
|
|
|
|
* to user space so that user can decide correct minor number
|
|
|
|
* if [s]he want to create more devices.
|
|
|
|
*
|
|
|
|
* Note that -1 is required because partition 0 is reserved
|
|
|
|
* for the whole disk.
|
|
|
|
*/
|
|
|
|
max_part = (1UL << part_shift) - 1;
|
|
|
|
}
|
|
|
|
|
2013-02-22 03:16:49 +04:00
|
|
|
if ((1UL << part_shift) > DISK_MAX_PARTS) {
|
|
|
|
err = -EINVAL;
|
2017-08-07 15:37:50 +03:00
|
|
|
goto err_out;
|
2013-02-22 03:16:49 +04:00
|
|
|
}
|
2011-05-24 18:48:54 +04:00
|
|
|
|
2013-02-22 03:16:49 +04:00
|
|
|
if (max_loop > 1UL << (MINORBITS - part_shift)) {
|
|
|
|
err = -EINVAL;
|
2017-08-07 15:37:50 +03:00
|
|
|
goto err_out;
|
2013-02-22 03:16:49 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
/*
|
|
|
|
* If max_loop is specified, create that many devices upfront.
|
|
|
|
* This also becomes a hard limit. If max_loop is not specified,
|
|
|
|
* create CONFIG_BLK_DEV_LOOP_MIN_COUNT loop devices at module
|
|
|
|
* init time. Loop devices can be requested on-demand with the
|
|
|
|
* /dev/loop-control interface, or be instantiated by accessing
|
|
|
|
* a 'dead' device node.
|
|
|
|
*/
|
2007-05-08 11:28:20 +04:00
|
|
|
if (max_loop) {
|
2007-06-09 00:46:44 +04:00
|
|
|
nr = max_loop;
|
loop: handle on-demand devices correctly
When finding or allocating a loop device, loop_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example:
$ sudo modprobe loop max_part=15
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
$ sudo mknod /dev/loop8 b 7 128
$ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
$ sudo losetup -a
/dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8
After this patch, /dev/loop8 - instead of /dev/loop128 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that LOOP_MAJOR can address. It does
not need to be limited by partition numbers unless 'max_loop'
param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-05-24 18:48:55 +04:00
|
|
|
range = max_loop << part_shift;
|
2007-06-09 00:46:44 +04:00
|
|
|
} else {
|
2011-08-01 00:08:04 +04:00
|
|
|
nr = CONFIG_BLK_DEV_LOOP_MIN_COUNT;
|
loop: handle on-demand devices correctly
When finding or allocating a loop device, loop_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example:
$ sudo modprobe loop max_part=15
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
$ sudo mknod /dev/loop8 b 7 128
$ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
$ sudo losetup -a
/dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8
After this patch, /dev/loop8 - instead of /dev/loop128 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that LOOP_MAJOR can address. It does
not need to be limited by partition numbers unless 'max_loop'
param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-05-24 18:48:55 +04:00
|
|
|
range = 1UL << MINORBITS;
|
2007-06-09 00:46:44 +04:00
|
|
|
}
|
|
|
|
|
2017-08-07 15:37:50 +03:00
|
|
|
err = misc_register(&loop_misc);
|
|
|
|
if (err < 0)
|
|
|
|
goto err_out;
|
|
|
|
|
|
|
|
|
2013-02-22 03:16:49 +04:00
|
|
|
if (register_blkdev(LOOP_MAJOR, "loop")) {
|
|
|
|
err = -EIO;
|
|
|
|
goto misc_out;
|
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2007-06-09 00:46:44 +04:00
|
|
|
blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
|
|
|
|
THIS_MODULE, loop_probe, NULL, NULL);
|
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
/* pre-create number of devices given by config or max_loop */
|
2011-08-01 00:08:04 +04:00
|
|
|
mutex_lock(&loop_index_mutex);
|
|
|
|
for (i = 0; i < nr; i++)
|
|
|
|
loop_add(&lo, i);
|
|
|
|
mutex_unlock(&loop_index_mutex);
|
|
|
|
|
2007-05-08 11:28:20 +04:00
|
|
|
printk(KERN_INFO "loop: module loaded\n");
|
2005-04-17 02:20:36 +04:00
|
|
|
return 0;
|
2013-02-22 03:16:49 +04:00
|
|
|
|
|
|
|
misc_out:
|
|
|
|
misc_deregister(&loop_misc);
|
2017-08-07 15:37:50 +03:00
|
|
|
err_out:
|
2013-02-22 03:16:49 +04:00
|
|
|
return err;
|
2011-08-01 00:08:04 +04:00
|
|
|
}
|
2007-06-09 00:46:44 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
static int loop_exit_cb(int id, void *ptr, void *data)
|
|
|
|
{
|
|
|
|
struct loop_device *lo = ptr;
|
2007-06-09 00:46:44 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
loop_remove(lo);
|
|
|
|
return 0;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2007-05-08 11:28:20 +04:00
|
|
|
static void __exit loop_exit(void)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2007-06-09 00:46:44 +04:00
|
|
|
unsigned long range;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
loop: handle on-demand devices correctly
When finding or allocating a loop device, loop_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example:
$ sudo modprobe loop max_part=15
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
$ sudo mknod /dev/loop8 b 7 128
$ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
$ sudo losetup -a
/dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8
After this patch, /dev/loop8 - instead of /dev/loop128 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that LOOP_MAJOR can address. It does
not need to be limited by partition numbers unless 'max_loop'
param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-05-24 18:48:55 +04:00
|
|
|
range = max_loop ? max_loop << part_shift : 1UL << MINORBITS;
|
2007-06-09 00:46:44 +04:00
|
|
|
|
2011-08-01 00:08:04 +04:00
|
|
|
idr_for_each(&loop_index_idr, &loop_exit_cb, NULL);
|
|
|
|
idr_destroy(&loop_index_idr);
|
2007-05-08 11:28:20 +04:00
|
|
|
|
2007-06-09 00:46:44 +04:00
|
|
|
blk_unregister_region(MKDEV(LOOP_MAJOR, 0), range);
|
2007-07-17 15:03:46 +04:00
|
|
|
unregister_blkdev(LOOP_MAJOR, "loop");
|
loop: add management interface for on-demand device allocation
Loop devices today have a fixed pre-allocated number of usually 8.
The number can only be changed at module init time. To find a free
device to use, /dev/loop%i needs to be scanned, and all devices need
to be opened until a free one is possibly found.
This adds a new /dev/loop-control device node, that allows to
dynamically find or allocate a free device, and to add and remove loop
devices from the running system:
LOOP_CTL_ADD adds a specific device. Arg is the number
of the device. It returns the device i or a negative
error code.
LOOP_CTL_REMOVE removes a specific device, Arg is the
number the device. It returns the device i or a negative
error code.
LOOP_CTL_GET_FREE finds the next unbound device or allocates
a new one. No arg is given. It returns the device i or a
negative error code.
The loop kernel module gets automatically loaded when
/dev/loop-control is accessed the first time. The alias
specified in the module, instructs udev to create this
'dead' device node, even when the module is not loaded.
Example:
cfd = open("/dev/loop-control", O_RDWR);
# add a new specific loop device
err = ioctl(cfd, LOOP_CTL_ADD, devnr);
# remove a specific loop device
err = ioctl(cfd, LOOP_CTL_REMOVE, devnr);
# find or allocate a free loop device to use
devnr = ioctl(cfd, LOOP_CTL_GET_FREE);
sprintf(loopname, "/dev/loop%i", devnr);
ffd = open("backing-file", O_RDWR);
lfd = open(loopname, O_RDWR);
err = ioctl(lfd, LOOP_SET_FD, ffd);
Cc: Tejun Heo <tj@kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
2011-08-01 00:08:04 +04:00
|
|
|
|
|
|
|
misc_deregister(&loop_misc);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
module_init(loop_init);
|
|
|
|
module_exit(loop_exit);
|
|
|
|
|
|
|
|
#ifndef MODULE
|
|
|
|
static int __init max_loop_setup(char *str)
|
|
|
|
{
|
|
|
|
max_loop = simple_strtol(str, NULL, 0);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
__setup("max_loop=", max_loop_setup);
|
|
|
|
#endif
|