On Fri, Aug 7, 2015 at 3:45 AM, Hannes Reinecke <[email protected]> wrote: > On 08/07/2015 09:23 AM, Ming Lei wrote: >> On Fri, Aug 7, 2015 at 2:46 AM, Hannes Reinecke <[email protected]> wrote: >>> On 08/07/2015 07:07 AM, Ming Lei wrote: >>>> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
