Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422806AbbHGIC2 (ORCPT ); Fri, 7 Aug 2015 04:02:28 -0400 Received: from mail-io0-f180.google.com ([209.85.223.180]:35937 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755695AbbHGICT (ORCPT ); Fri, 7 Aug 2015 04:02:19 -0400 MIME-Version: 1.0 In-Reply-To: <55C4620C.3050901@suse.de> References: <1437118027-94602-1-git-send-email-hare@suse.de> <55BFF28B.8000308@suse.de> <55C4544E.1040207@suse.de> <55C4620C.3050901@suse.de> Date: Fri, 7 Aug 2015 04:02:18 -0400 Message-ID: Subject: Re: [PATCH 0/4] loop: enable different physical blocksizes From: Ming Lei To: Hannes Reinecke Cc: Alexander Graf , Jens Axboe , Christoph Hellwig , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1902 Lines: 46 On Fri, Aug 7, 2015 at 3:45 AM, Hannes Reinecke wrote: > 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. 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 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/