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

Groups > linux.kernel > #1202290 > 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 Ming Lei <tom.leiming@gmail.com> - 2015-08-07 07:10 +0200
    Re: [PATCH 0/4] loop: enable different physical blocksizes Hannes Reinecke <hare@suse.de> - 2015-08-07 08:50 +0200
      Re: [PATCH 0/4] loop: enable different physical blocksizes Ming Lei <tom.leiming@gmail.com> - 2015-08-07 09:30 +0200
        Re: [PATCH 0/4] loop: enable different physical blocksizes Hannes Reinecke <hare@suse.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:10 +0200

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

On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <agraf@suse.de> wrote:
>
>
> 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

The default block size of mkfs.ext4 is 4K, so suppose it is 1024 by passing
'-b 1024'; otherwise inside VM, the block device(with 4k logical block size)
can be mounted correctly.

>   $ qemu <with lots of options to pass the disk as 4k disk>

Then you should pass 'logical_block_size=1024 or 512' in '-device '
parameter of qemu. The story is that block size of filesystem should
be equal or greater than logical block size of block device, see
sb_min_blocksize().

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

I am wondering if mkfs is remembering the sector size of actual block
device, and at least it can't be found by 'dumpe2fs'. And it shouldn't have
do that, otherwise it isn't flexible. And one fs image often can be looped
successully by loop because loop's block size is 512.

That is why I am wondering if we need support other logical block size
for loop.

>
> 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.

No, the filesystem block size is just equal or bigger than logical block size
of the backing device, then it can be loop mounted successfully without
any problem.


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

#1202317

On 08/07/2015 07:07 AM, Ming Lei wrote:
> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <agraf@suse.de> wrote:
>>

[ .. ]

>>
>> because the guest thinks the disk is formatted with 4k sector size,
>> while mkfs thought it's formatted with 512 byte sector size.
> 
> I am wondering if mkfs is remembering the sector size of actual block
> device, and at least it can't be found by 'dumpe2fs'. And it shouldn't have
> do that, otherwise it isn't flexible. And one fs image often can be looped
> successully by loop because loop's block size is 512.
> 
> That is why I am wondering if we need support other logical block size
> for loop.
> 
If you were to install a bootloader (like lilo or zipl for S/390) it
needs to write the _physical_ block addresses of the kernel and the
initrd. And these do vary, depending in the physical blocksize.
So while the filesystems indeed do not care (all translation is done
in the block driver, not the filesystem), bootloaders most certainly
do.
If you were to create a bootable disk on 4k disks you need this patch.

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

#1202363

On Fri, Aug 7, 2015 at 2:46 AM, Hannes Reinecke <hare@suse.de> wrote:
> On 08/07/2015 07:07 AM, Ming Lei wrote:
>> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <agraf@suse.de> wrote:
>>>
>
> [ .. ]
>
>>>
>>> because the guest thinks the disk is formatted with 4k sector size,
>>> while mkfs thought it's formatted with 512 byte sector size.
>>
>> I am wondering if mkfs is remembering the sector size of actual block
>> device, and at least it can't be found by 'dumpe2fs'. And it shouldn't have
>> do that, otherwise it isn't flexible. And one fs image often can be looped
>> successully by loop because loop's block size is 512.
>>
>> That is why I am wondering if we need support other logical block size
>> for loop.
>>
> If you were to install a bootloader (like lilo or zipl for S/390) it
> needs to write the _physical_ block addresses of the kernel and the
> initrd. And these do vary, depending in the physical blocksize.

So there isn't filesystem involved in your case of installing bootloader,
then I am wondering why you don't write the data to the backing block
directly? And why does loop have to be involved in this special case?

> So while the filesystems indeed do not care (all translation is done
> in the block driver, not the filesystem), bootloaders most certainly
> do.
> If you were to create a bootable disk on 4k disks you need this patch.

It it were me, I choose to do that against the disk directly, instead of
using loop, :-)


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]

#1202387

On 08/07/2015 09:23 AM, Ming Lei wrote:
> On Fri, Aug 7, 2015 at 2:46 AM, Hannes Reinecke <hare@suse.de> wrote:
>> On 08/07/2015 07:07 AM, Ming Lei wrote:
>>> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>
>> [ .. ]
>>
>>>>
>>>> because the guest thinks the disk is formatted with 4k sector size,
>>>> while mkfs thought it's formatted with 512 byte sector size.
>>>
>>> I am wondering if mkfs is remembering the sector size of actual block
>>> device, and at least it can't be found by 'dumpe2fs'. And it shouldn't have
>>> do that, otherwise it isn't flexible. And one fs image often can be looped
>>> successully by loop because loop's block size is 512.
>>>
>>> That is why I am wondering if we need support other logical block size
>>> for loop.
>>>
>> If you were to install a bootloader (like lilo or zipl for S/390) it
>> needs to write the _physical_ block addresses of the kernel and the
>> initrd. And these do vary, depending in the physical blocksize.
> 
> So there isn't filesystem involved in your case of installing bootloader,
> then I am wondering why you don't write the data to the backing block
> directly? And why does loop have to be involved in this special case?
> 
Because this is a virtual environment.
Hardware is a limited resource, and you would need to assign each
one to a guest.
Using loop you can run fully virtualized, without having to recurse
on hardware limitations.

>> So while the filesystems indeed do not care (all translation is done
>> in the block driver, not the filesystem), bootloaders most certainly
>> do.
>> If you were to create a bootable disk on 4k disks you need this patch.
> 
> It it were me, I choose to do that against the disk directly, instead of
> using loop, :-)
> 
See above. The reason why we did this patch is precisely because we
do _not_ want to use physical disks.

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

#1202417

On Fri, Aug 7, 2015 at 3:45 AM, Hannes Reinecke <hare@suse.de> wrote:
> On 08/07/2015 09:23 AM, Ming Lei wrote:
>> On Fri, Aug 7, 2015 at 2:46 AM, Hannes Reinecke <hare@suse.de> wrote:
>>> On 08/07/2015 07:07 AM, Ming Lei wrote:
>>>> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <agraf@suse.de> wrote:
>>>>>
>>>
>>> [ .. ]
>>>
>>>>>
>>>>> because the guest thinks the disk is formatted with 4k sector size,
>>>>> while mkfs thought it's formatted with 512 byte sector size.
>>>>
>>>> I am wondering if mkfs is remembering the sector size of actual block
>>>> device, and at least it can't be found by 'dumpe2fs'. And it shouldn't have
>>>> do that, otherwise it isn't flexible. And one fs image often can be looped
>>>> successully by loop because loop's block size is 512.
>>>>
>>>> That is why I am wondering if we need support other logical block size
>>>> for loop.
>>>>
>>> If you were to install a bootloader (like lilo or zipl for S/390) it
>>> needs to write the _physical_ block addresses of the kernel and the
>>> initrd. And these do vary, depending in the physical blocksize.
>>
>> So there isn't filesystem involved in your case of installing bootloader,
>> then I am wondering why you don't write the data to the backing block
>> directly? And why does loop have to be involved in this special case?
>>
> Because this is a virtual environment.
> Hardware is a limited resource, and you would need to assign each
> one to a guest.
> Using loop you can run fully virtualized, without having to recurse
> on hardware limitations.

OK, sounds a valid case, and suggest to add the install bootloader story
into the commit log.


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] | [standalone]

Back to top | Article view | linux.kernel

csiph-web