similar to: [PATCH] virtio_blk: add helper function to support mass of disks naming

This patch series renames "sd_format_disk_name()" to "disk_name_format()" and moves it into block core. So that who needs formatting disk name can use it, instead of duplicating these similar help functions. Ren Mingxin (4): block: add function disk_name_format() into block core scsi: replace sd_format_disk_name() to disk_name_format() block: replace

This patch series renames "sd_format_disk_name()" to "disk_name_format()" and moves it into block core. So that who needs formatting disk name can use it, instead of duplicating these similar help functions. Ren Mingxin (4): block: add function disk_name_format() into block core scsi: replace sd_format_disk_name() to disk_name_format() block: replace

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

The current virtio block sets a queue depth of 64, which is insufficient for very fast devices. It has been demonstrated that with a high IOPS device, using a queue depth of 256 can double the IOPS which can be sustained. As suggested by Venkatash Srinivas, set the queue depth by default to be one half the the device's virtqueue, which is the maximum queue depth that can be supported by the

On March 14, 2014 11:34:31 PM EDT, Theodore Ts'o <tytso at mit.edu> wrote: >The current virtio block sets a queue depth of 64, which is >insufficient for very fast devices. It has been demonstrated that >with a high IOPS device, using a queue depth of 256 can double the >IOPS which can be sustained. > >As suggested by Venkatash Srinivas, set the queue depth by default

On March 14, 2014 11:34:31 PM EDT, Theodore Ts'o <tytso at mit.edu> wrote: >The current virtio block sets a queue depth of 64, which is >insufficient for very fast devices. It has been demonstrated that >with a high IOPS device, using a queue depth of 256 can double the >IOPS which can be sustained. > >As suggested by Venkatash Srinivas, set the queue depth by default

Do not unregister the major at device remove, since there might be another device instances around. (qemu) pci_del 0 11 (qemu) ACPI: PCI interrupt for device 0000:00:0b.0 disabled (qemu) pci_del 0 10 (qemu) ------------[ cut here ]------------ WARNING: at block/genhd.c:126 unregister_blkdev+0x74/0x9e() ACPI: PCI interrupt for device 0000:00:0a.0 disabled Signed-off-by: Marcelo Tosatti

If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so

If we reset the virtio-blk device before the requests already dispatched to the virtio-blk driver from the block layer are finised, we will stuck in blk_cleanup_queue() and the remove will fail. blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued before DEAD marking. However it will never success if the device is already stopped. We'll have q->in_flight[] > 0, so

Rusty, currently virtio_blk uses one major number per device. While this works quite well on most systems it is wasteful and will exhaust major numbers on larger installations. This patch allocates a major number on init and will use 16 minor numbers for each disk. That will allow ~64k virtio_blk disks. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> ---

Rusty, currently virtio_blk uses one major number per device. While this works quite well on most systems it is wasteful and will exhaust major numbers on larger installations. This patch allocates a major number on init and will use 16 minor numbers for each disk. That will allow ~64k virtio_blk disks. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> ---

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Hi Jens, this series removes the revalidate_disk() function, which has been a really odd duck in the last years. The prime reason why most people use it is because it propagates a size change from the gendisk to the block_device structure. But it also calls into the rather ill defined ->revalidate_disk method which is rather useless for the callers. So this adds a new helper to just

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk