From: Hannes Reinecke <hare@suse.de>
To: Ming Lei <tom.leiming@gmail.com>, Alexander Graf <agraf@suse.de>
Cc: Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] loop: enable different physical blocksizes
Date: Fri, 07 Aug 2015 08:46:38 +0200 [thread overview]
Message-ID: <55C4544E.1040207@suse.de> (raw)
In-Reply-To: <CACVXFVP1VzTObFO0FCghmVVSuj+qUjpwcupJmVsNpSTnXXa1Dg@mail.gmail.com>
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)
next prev parent reply other threads:[~2015-08-07 6:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 7:27 [PATCH 0/4] loop: enable different physical blocksizes Hannes Reinecke
2015-07-17 7:27 ` [PATCH 1/4] loop: Enable correct physical blocksize Hannes Reinecke
2015-07-27 5:15 ` Christoph Hellwig
2015-07-27 5:59 ` Hannes Reinecke
2015-08-07 7:31 ` Christoph Hellwig
2015-07-17 7:27 ` [PATCH 2/4] loop: Remove unused 'bdev' argument from loop_set_capacity Hannes Reinecke
2015-07-27 5:16 ` Christoph Hellwig
2015-07-17 7:27 ` [PATCH 3/4] loop: Add 'lo_logical_blocksize' Hannes Reinecke
2015-07-17 7:27 ` [PATCH 4/4] loop: Pass logical blocksize in 'lo_init[0]' ioctl field Hannes Reinecke
2015-07-27 10:40 ` [PATCH 0/4] loop: enable different physical blocksizes Ming Lei
2015-08-03 23:00 ` Alexander Graf
2015-08-07 5:07 ` Ming Lei
2015-08-07 6:46 ` Hannes Reinecke [this message]
2015-08-07 7:23 ` Ming Lei
2015-08-07 7:45 ` Hannes Reinecke
2015-08-07 8:02 ` Ming Lei
2015-08-07 7:33 ` Christoph Hellwig
2015-08-07 7:44 ` Ming Lei
2015-08-07 7:48 ` Christoph Hellwig
2015-08-07 7:58 ` Ming Lei
2015-08-07 7:50 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55C4544E.1040207@suse.de \
--to=hare@suse.de \
--cc=agraf@suse.de \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tom.leiming@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox