Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756481AbbHGHXH (ORCPT ); Fri, 7 Aug 2015 03:23:07 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:34608 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755621AbbHGHXE (ORCPT ); Fri, 7 Aug 2015 03:23:04 -0400 MIME-Version: 1.0 In-Reply-To: <55C4544E.1040207@suse.de> References: <1437118027-94602-1-git-send-email-hare@suse.de> <55BFF28B.8000308@suse.de> <55C4544E.1040207@suse.de> Date: Fri, 7 Aug 2015 03:23:03 -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: 1724 Lines: 43 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? > 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 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/