Re: [PATCH] btrfs-progs: convert, warn if converting a fs which won't mount

[David Sterba <dsterba@suse.cz>]

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