linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-ext4@vger.kernel.org,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: mke2fs accepts block size not mentioned in its man page
Date: Thu, 8 Aug 2019 18:00:58 -0700	[thread overview]
Message-ID: <20190809010058.GA7125@magnolia> (raw)
In-Reply-To: <ce9edecb-6f04-77d3-32f1-2b9de6cd3d7e@gmx.com>

On Fri, Jul 05, 2019 at 01:35:02PM +0800, Qu Wenruo wrote:
> Hi,
> 
> Just doing some tests on aarch64 with 64K page size.
> 
> Man page of mke2fs only mentions 3 valid block size: 1k, 2k, 4k.
> But in real world, we can pass 64K as block size for it without any problem:
> 
>   $mke2fs -F -t ext3 -b 65536 /dev/loop1
>   Warning: blocksize 65536 not usable on most systems.
>   mke2fs 1.45.2 (27-May-2019)
>   /dev/loop1 contains a btrfs file system
>   Discarding device blocks: done
>   Creating filesystem with 81920 64k blocks and 81920 inodes
>   Filesystem UUID: 311bb224-6d2d-44a7-9790-92c4878d6549
>   [...]
> 
> It's great to see mke2fs accepts 64K as nodesize, which allows
> btrfs-convert to work.
> (If blocksize is default to 4K or doesn't accept 64K page size,
> btrfs-convert can work but can't be mounted on system with 64K page size)
> 
> Shouldn't the man page mention all valid values?

You'd think so, but 64k blocks only works on machines with 64k pages,
so that's why it doesn't mention anything beyond the lowest common
denominator. :/

--D

> Thanks,
> Qu
> 




      reply	other threads:[~2019-08-09  1:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05  5:35 mke2fs accepts block size not mentioned in its man page Qu Wenruo
2019-08-09  1:00 ` Darrick J. Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190809010058.GA7125@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).