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

Groups > linux.kernel > #1202379 > unrolled thread

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

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 Christoph Hellwig <hch@lst.de> - 2015-08-07 09:40 +0200
    Re: [PATCH 0/4] loop: enable different physical blocksizes Ming Lei <tom.leiming@gmail.com> - 2015-08-07 09:50 +0200
      Re: [PATCH 0/4] loop: enable different physical blocksizes Christoph Hellwig <hch@lst.de> - 2015-08-07 09:50 +0200
        Re: [PATCH 0/4] loop: enable different physical blocksizes Ming Lei <tom.leiming@gmail.com> - 2015-08-07 10:00 +0200
      Re: [PATCH 0/4] loop: enable different physical blocksizes Hannes Reinecke <hare@suse.de> - 2015-08-07 10:00 +0200

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

On Mon, Jul 27, 2015 at 06:40:57AM -0400, 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.

The use case is to suppot 4k sectors sizes such as DASDs usually provide,
or just to create a 4k block device to check your filesystem of choice
handles 4k sectors just fine.  Replace 4k with other sector sizes of
your choice for added benefit.  In addition to the DASD use case it's really a
very useful debugging tool.
--
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]

#1202385

On Fri, Aug 7, 2015 at 3:33 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Jul 27, 2015 at 06:40:57AM -0400, 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.
>
> The use case is to suppot 4k sectors sizes such as DASDs usually provide,
> or just to create a 4k block device to check your filesystem of choice
> handles 4k sectors just fine.  Replace 4k with other sector sizes of
> your choice for added benefit.  In addition to the DASD use case it's really a
> very useful debugging tool.

There shouldn't be any problem about looping over DASP which has
4k sector size. Also for debugging purpose, we can easily emulate 4k
sector size disk by QEMU/virtio-blk.

We can support 4k sector size on loop for debugging purpose too, but
the side effect is that some images can't be loop mounted any more
after its secror size is become larger, then people might complain that.

Thanks,
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] | [prev] | [next] | [standalone]

#1202394

On Fri, Aug 07, 2015 at 03:44:58AM -0400, Ming Lei wrote:
> There shouldn't be any problem about looping over DASP which has
> 4k sector size. Also for debugging purpose, we can easily emulate 4k
> sector size disk by QEMU/virtio-blk.
> 
> We can support 4k sector size on loop for debugging purpose too, but
> the side effect is that some images can't be loop mounted any more
> after its secror size is become larger, then people might complain that.

Have you read the patches?

There isn't any change in default behavior, but it allows you to expose
a non-512 byte sector size _optionally_.  So no images will stop being
loop mountable, quite to the contrary - you can now loop mount an image
copied off from the 4k disk which otherwise would have been unusable
because the file system geometry didn't match what's returned by
the block layer as the sector size.
--
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] | [next] | [standalone]

#1202396

On Fri, Aug 7, 2015 at 3:48 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Aug 07, 2015 at 03:44:58AM -0400, Ming Lei wrote:
>> There shouldn't be any problem about looping over DASP which has
>> 4k sector size. Also for debugging purpose, we can easily emulate 4k
>> sector size disk by QEMU/virtio-blk.
>>
>> We can support 4k sector size on loop for debugging purpose too, but
>> the side effect is that some images can't be loop mounted any more
>> after its secror size is become larger, then people might complain that.
>
> Have you read the patches?
>
> There isn't any change in default behavior, but it allows you to expose
> a non-512 byte sector size _optionally_.  So no images will stop being
> loop mountable, quite to the contrary - you can now loop mount an image
> copied off from the 4k disk which otherwise would have been unusable
> because the file system geometry didn't match what's returned by
> the block layer as the sector size.

I mean the following case:

#losetup -B 4096 /dev/loop0 test.img
#mount /dev/loop0 /mnt
$...
#umount /mnt
#losetup -d /dev/loop0
#losetup /dev/loop0 test1.img
#mount /dev/loop0 /mnt

Then the last mount may fail becase the logical block size is still 4096.

Thanks,
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] | [prev] | [next] | [standalone]

#1202397

On 08/07/2015 09:44 AM, Ming Lei wrote:
> On Fri, Aug 7, 2015 at 3:33 AM, Christoph Hellwig <hch@lst.de> wrote:
>> On Mon, Jul 27, 2015 at 06:40:57AM -0400, 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.
>>
>> The use case is to suppot 4k sectors sizes such as DASDs usually provide,
>> or just to create a 4k block device to check your filesystem of choice
>> handles 4k sectors just fine.  Replace 4k with other sector sizes of
>> your choice for added benefit.  In addition to the DASD use case it's really a
>> very useful debugging tool.
> 
> There shouldn't be any problem about looping over DASP which has
> 4k sector size. Also for debugging purpose, we can easily emulate 4k
> sector size disk by QEMU/virtio-blk.
> 
> We can support 4k sector size on loop for debugging purpose too, but
> the side effect is that some images can't be loop mounted any more
> after its secror size is become larger, then people might complain that.
> 
Which is why I made it optional, and having to use some ioctl fields
to enable this feature.
So _if_ someone uses these new features _and_ then complains that
the sector size is different I'll have only limited compassion.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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