linux-bcachefs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Su Yue <l@damenly.org>
To: Brian Foster <bfoster@redhat.com>
Cc: Su Yue <glass.su@suse.com>,
	fstests@vger.kernel.org, linux-bcachefs@vger.kernel.org,
	l@damenly.org
Subject: Re: [PATCH v2 2/2] common/rc: improve block size support for bcachefs
Date: Thu, 18 Jan 2024 10:59:14 +0800	[thread overview]
Message-ID: <h6jb49cm.fsf@damenly.org> (raw)
In-Reply-To: <ZagUdl+DlxIw+siv@bfoster>


On Wed 17 Jan 2024 at 12:55, Brian Foster <bfoster@redhat.com> 
wrote:

> On Wed, Jan 17, 2024 at 05:23:09PM +0800, Su Yue wrote:
>> For bcachefs, def_blksz is never assigned even MKFS_OPTIONS 
>> contains option
>> '--block_size'. So block size of bcachefs on scratch dev is 
>> always 4096
>> if _scratch_mkfs_sized is called without second parameter.
>>
>> Add the pattern to set def_blksz if '--block_size' is given in 
>> MKFS_OPTIONS.
>>
>> Signed-off-by: Su Yue <glass.su@suse.com>
>> ---
>> changelog:
>> v2:
>>     Born.
>> ---
>>  common/rc | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/common/rc b/common/rc
>> index 31c21d2a8360..6a01de69cf05 100644
>> --- a/common/rc
>> +++ b/common/rc
>> @@ -950,6 +950,9 @@ _scratch_mkfs_sized()
>>  	jfs)
>>  		def_blksz=4096
>>  		;;
>> +	bcachefs)
>> +		def_blksz=`echo $MKFS_OPTIONS | sed -rn 
>> 's/.*(--block_size)[ =]?+([0-9]+).*/\2/p'`
>> +		;;
>
> So if the default bcachefs block size is 512b, I wonder if this 
> should
> do something like what the udf branch does a few lines above and
>
mkfs.bcachefs decides block size by querying statbuf.st_blksize or
BLKPBSZGET from the device if the option is not given.

> override the hardcoded default of 4k. ISTM this whole thing 
> would be
> more robust if it just elided the param in the default cases and 
> let the
> associated mkfs tool use its own default, but that's probably a 
> separate
> issue. Hm?
>
Since there is no default block size of bcachefs, maybe we can let
mkfs.bcachefs decide on its own but it will make chaos when 
somebody
reports an unreproducible BUG due to the different block_size even
we have same local.config. It just happened...
So for now, I think 4096 is a resonable value of bcachefs block 
size.

--
Su
>
> Brian
>
>>  	esac
>>
>>  	[ -n "$def_blksz" ] && blocksize=$def_blksz
>> --
>> 2.43.0
>>

  reply	other threads:[~2024-01-18  3:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17  9:23 [PATCH v2 1/2] fstests: introduce MKFS_BCACHEFS_PROG for bcachefs Su Yue
2024-01-17  9:23 ` [PATCH v2 2/2] common/rc: improve block size support " Su Yue
2024-01-17 17:55   ` Brian Foster
2024-01-18  2:59     ` Su Yue [this message]
2024-01-19 16:09       ` Brian Foster
2024-01-21  4:00         ` Su Yue
2024-01-22 15:20           ` Brian Foster
2024-01-25  2:10             ` Su Yue
2024-01-26 13:40               ` Brian Foster
2024-01-17 17:54 ` [PATCH v2 1/2] fstests: introduce MKFS_BCACHEFS_PROG " Brian Foster

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=h6jb49cm.fsf@damenly.org \
    --to=l@damenly.org \
    --cc=bfoster@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=glass.su@suse.com \
    --cc=linux-bcachefs@vger.kernel.org \
    /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).