Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755922AbbHGHpW (ORCPT ); Fri, 7 Aug 2015 03:45:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:42896 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752142AbbHGHpS (ORCPT ); Fri, 7 Aug 2015 03:45:18 -0400 Message-ID: <55C4620C.3050901@suse.de> Date: Fri, 07 Aug 2015 09:45:16 +0200 From: Hannes Reinecke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ming Lei CC: Alexander Graf , Jens Axboe , Christoph Hellwig , Linux Kernel Mailing List Subject: Re: [PATCH 0/4] loop: enable different physical blocksizes References: <1437118027-94602-1-git-send-email-hare@suse.de> <55BFF28B.8000308@suse.de> <55C4544E.1040207@suse.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2373 Lines: 59 On 08/07/2015 09:23 AM, Ming Lei wrote: > On Fri, Aug 7, 2015 at 2:46 AM, Hannes Reinecke wrote: >> On 08/07/2015 07:07 AM, Ming Lei wrote: >>> On Mon, Aug 3, 2015 at 7:00 PM, Alexander Graf 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/