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.
>> 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 [email protected] +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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
