On Fri, Aug 7, 2015 at 2:46 AM, Hannes Reinecke <h...@suse.de> wrote: > On 08/07/2015 07:07 AM, Ming Lei wrote: >> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf <ag...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
