On 2020/3/4 上午10:14, Anand Jain wrote: > > > On 3/4/20 1:44 AM, David Sterba wrote: >> 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 >> > > Just warn is reasonable. But I don't think you meant to introduce > interactive part similar to mkfs.ext4 in btrfs-convert? we don't have it > anywhere in btrfs-progs. As the btrfs-convert is not an exceptional case > (though it deals with the user data) removing the delay makes sense, > mover over the conversion and the rollback does not take much time in > general. > > Thanks, Anand +1 for warning only, especially when btrfs-convert is revertable, unlike mkfs. Thanks, Qu
