From: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Yi Zhang <yi.zhang@redhat.com>,
"logang@deltatee.com" <logang@deltatee.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH blktests] common/xfs: ignore the 32M log size during mkfs.xfs
Date: Fri, 21 Oct 2022 08:58:10 +0000 [thread overview]
Message-ID: <20221021085809.zkzw23ewnv6ul3b4@shindev> (raw)
In-Reply-To: <d3688d8d-bcf7-9cbf-7c99-74cb1a05a9dc@nvidia.com>
On Oct 19, 2022 / 19:18, Chaitanya Kulkarni wrote:
> On 10/19/22 07:19, Eric Sandeen wrote:
> > On 10/19/22 1:16 AM, Chaitanya Kulkarni wrote:
> >> On 10/18/22 22:12, Yi Zhang wrote:
> >>> The new minimum size for the xfs log is 64MB which introudced from
> >>> xfsprogs v5.19.0, let's ignore it, or nvme/013 will be failed at:
> >>>
> >>
> >> instead of removing it set to 64MB ?
> >
> > What is the advantage of hard-coding any log size? By doing so you are
> > overriding mkfs's own best-practice heuristics, and you might run into
> > other failures in the future.
> >
> > Is there a reason to not just use the defaults?
> >
>
> I think the point here to use the minimal XFS setup.
>
> Does default size is minimal ? or at least we should document
> what the size it is.
As far as I read `man mkfs.xfs`, it is not minimal. It changes depending on the
filesystem size.
To have minimal XFS setup, do we need to care other parameters than log size?
I'm looking at 'man mkfs.xfs' and it mentions data section size and some other
size related options.
Two more questions have come up in my mind:
- Did we have nvme driver or block layer issues related to xfs log size in the
past? If so, it is reasonable to specify it.
- When we see failures of xfs user test cases (nvme/012,013,035), is xfs log
size useful to debug?
--
Shin'ichiro Kawasaki
next prev parent reply other threads:[~2022-10-21 8:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 5:12 [PATCH blktests] common/xfs: ignore the 32M log size during mkfs.xfs Yi Zhang
2022-10-19 6:06 ` Chaitanya Kulkarni
2022-10-19 6:16 ` Chaitanya Kulkarni
2022-10-19 14:19 ` Eric Sandeen
2022-10-19 19:18 ` Chaitanya Kulkarni
2022-10-21 8:58 ` Shinichiro Kawasaki [this message]
2022-10-21 21:42 ` Chaitanya Kulkarni
2022-10-21 23:56 ` Shinichiro Kawasaki
2022-10-23 15:27 ` Yi Zhang
2022-10-24 0:50 ` Shinichiro Kawasaki
2022-10-24 6:32 ` Yi Zhang
2022-10-24 10:31 ` Shinichiro Kawasaki
2022-10-25 0:42 ` Chaitanya Kulkarni
2022-10-25 1:53 ` Shinichiro Kawasaki
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=20221021085809.zkzw23ewnv6ul3b4@shindev \
--to=shinichiro.kawasaki@wdc.com \
--cc=chaitanyak@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=sandeen@sandeen.net \
--cc=yi.zhang@redhat.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