Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1192955 > unrolled thread

Re: [PATCH 0/4] loop: enable different physical blocksizes

Started byMing Lei <tom.leiming@gmail.com>
First post2015-07-27 12:50 +0200
Last post2015-08-04 01:10 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 0/4] loop: enable different physical blocksizes Ming Lei <tom.leiming@gmail.com> - 2015-07-27 12:50 +0200
    Re: [PATCH 0/4] loop: enable different physical blocksizes Alexander Graf <agraf@suse.de> - 2015-08-04 01:10 +0200

#1192955 — Re: [PATCH 0/4] loop: enable different physical blocksizes

FromMing Lei <tom.leiming@gmail.com>
Date2015-07-27 12:50 +0200
SubjectRe: [PATCH 0/4] loop: enable different physical blocksizes
Message-ID<pQO8O-7zV-13@gated-at.bofh.it>
On Fri, Jul 17, 2015 at 3:27 AM, Hannes Reinecke <hare@suse.de> wrote:
> Currently the loop driver just simulates 512-byte blocks. When
> creating images for virtual machines it might be required to use
> a different physical blocksize (eg 4k for S/390 DASD).

Looks 'qemu-img create' doesn't have parameter of block size,
so could you share your use case? And I am just curious why
512-byte can't work for this case.

> This patchset extends the current LOOP_SET_STATUS64 ioctl to
> set the logical and physical blocksize by re-using the existing
> 'init' fields, which are currently unused.
>
> As usual, comments and reviews are welcome.
>
> Hannes Reinecke (4):
>   loop: Enable correct physical blocksize
>   loop: Remove unused 'bdev' argument from loop_set_capacity
>   loop: Add 'lo_logical_blocksize'
>   loop: Pass logical blocksize in 'lo_init[0]' ioctl field
>
>  drivers/block/loop.c      | 35 ++++++++++++++++++++++++++++++-----
>  drivers/block/loop.h      |  1 +
>  include/uapi/linux/loop.h |  1 +
>  3 files changed, 32 insertions(+), 5 deletions(-)
>
> --
> 1.8.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1199317

FromAlexander Graf <agraf@suse.de>
Date2015-08-04 01:10 +0200
Message-ID<pTx1M-Kt-11@gated-at.bofh.it>
In reply to#1192955

On 27.07.15 11:40, Ming Lei wrote:
> On Fri, Jul 17, 2015 at 3:27 AM, Hannes Reinecke <hare@suse.de> wrote:
>> Currently the loop driver just simulates 512-byte blocks. When
>> creating images for virtual machines it might be required to use
>> a different physical blocksize (eg 4k for S/390 DASD).
> 
> Looks 'qemu-img create' doesn't have parameter of block size,
> so could you share your use case? And I am just curious why
> 512-byte can't work for this case.

If you only want to access the virtual disk inside of QEMU you're all
good. However, if you want to directly run mkfs or fdasd on a loopback
device, then you need to expose 4k blocksize to the tools or they end up
creating a different on-disk format (if they work at all).

So the easiest case where things go wrong is

  $ qemu-img create test.img 1G
  $ losetup /dev/loop0 test.img
  $ mkfs.ext4 /dev/loop0
  $ qemu <with lots of options to pass the disk as 4k disk>

because the guest thinks the disk is formatted with 4k sector size,
while mkfs thought it's formatted with 512 byte sector size.

With this patch you can do

  $ qemu-img create test.img 1G
  $ losetup -B 4096 /dev/loop0 test.img
  $ mkfs.ext4 /dev/loop0
  $ qemu <with lots of options to pass the disk as 4k disk>

and it will work because both views of the world are identical. The same
applies for images you pull from a disk. So if you have a real 4k
logical sector size disk and you dd an image from it, you won't be able
to loop mount it today. With this patch set, you can.


Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web