From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC632C3F2D8 for ; Tue, 3 Mar 2020 17:44:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF2C8208C3 for ; Tue, 3 Mar 2020 17:44:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730818AbgCCRou (ORCPT ); Tue, 3 Mar 2020 12:44:50 -0500 Received: from mx2.suse.de ([195.135.220.15]:49862 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730810AbgCCRor (ORCPT ); Tue, 3 Mar 2020 12:44:47 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 373A2AE5E; Tue, 3 Mar 2020 17:44:45 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 22CC7DA7AE; Tue, 3 Mar 2020 18:44:23 +0100 (CET) Date: Tue, 3 Mar 2020 18:44:22 +0100 From: David Sterba To: Anand Jain Cc: David Sterba , Qu Wenruo , linux-btrfs@vger.kernel.org, Nikolay Borisov Subject: Re: [PATCH] btrfs-progs: convert, warn if converting a fs which won't mount Message-ID: <20200303174422.GM2902@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Anand Jain , David Sterba , Qu Wenruo , linux-btrfs@vger.kernel.org, Nikolay Borisov References: <1582877026-5487-1-git-send-email-anand.jain@oracle.com> <39c3e381-b49e-a571-d058-a01734b8b4a9@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <39c3e381-b49e-a571-d058-a01734b8b4a9@oracle.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Fri, Feb 28, 2020 at 05:06:52PM +0800, Anand Jain wrote: > On 2/28/20 4:27 PM, Qu Wenruo wrote: > > On 2020/2/28 下午4:03, Anand Jain wrote: > >> On aarch64 with pagesize 64k, btrfs-convert of ext4 is successful, > >> but it won't mount because we don't yet support subpage blocksize/ > >> sectorsize. > >> > >> BTRFS error (device vda): sectorsize 4096 not supported yet, only support 65536 > >> > >> So in this case during convert provide a warning and a 10s delay to > >> terminate the command. > > > > This is no different than calling mkfs.btrfs -s 64k on x86 system. > > And I see no warning from mkfs.btrfs. > > > > Thus I don't see the point of only introducing such warning to > > btrfs-convert. > > > > I have equal weight-age on the choices if blocksize != pagesize viz.. > delay and warn (this patch) > quit (Nikolay). > keep it as it is without warning (Qu). > > Here we are dealing with already user data. Should it be different > from mkfs? > Quit is fine, but convert tool should it be system neutral? The delays should be used in exceptional cases, now we have it for check --repair and for unfiltered balance. Both on user request because expecting users to know everything in advance what the commands do has shown to be too optimistic. Refusing to allow the conversion does not make much sense for usability, mising the unmounted and mounted constraints. A warning might be in place but there's nothing wrong to let the user do the conversion. I've tried mkfs.ext4 with 64k block size and it warns and in the interactive session wants to confirm that by the user: $ mkfs.ext4 -b 64k img Warning: blocksize 65536 not usable on most systems. mke2fs 1.45.5 (07-Jan-2020) img contains a ext4 file system created on Tue Mar 3 18:41:46 2020 Proceed anyway? (y,N) y mkfs.ext4: 65536-byte blocks too big for system (max 4096) Proceed anyway? (y,N) y Warning: 65536-byte blocks too big for system (max 4096), forced to continue Creating filesystem with 32768 64k blocks and 32768 inodes Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done