From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] [RFC] xfs: filesystem expansion design documentation
Date: Wed, 24 Jul 2024 10:23:34 -0700 [thread overview]
Message-ID: <20240724172334.GY612460@frogsfrogsfrogs> (raw)
In-Reply-To: <73173356-6914-42d4-8020-ea2f32661393@sandeen.net>
On Wed, Jul 24, 2024 at 10:44:47AM -0500, Eric Sandeen wrote:
> On 7/24/24 10:41 AM, Eric Sandeen wrote:
> > On 7/23/24 7:46 PM, Dave Chinner wrote:
> >>> What about the log? If sb_agblocks increases, that can cause
> >>> transaction reservations to increase, which also increases the minimum
> >>> log size.
> >> Not caring, because the current default minimum of 64MB is big enough for
> >> any physical filesystem size. Further, 64MB is big enough for decent
> >> metadata performance even on large filesystem, so we really don't
> >> need to touch the journal here.
<shrug> I think our support staff might disagree about that for the
large machines they have to support, but log expansion doesn't need to
be implemented in the initial proposal or programming effort.
> > Seems fair, but just to stir the pot, "growing the log" offline, when
> > you've just added potentially gigabytes of free space to an AG, should
> > be trivial, right?
Possibly -- if there's free space after the end and the log is clean.
Maybe mkfs should try to allocate the log at the /end/ of the AG to
make this easier?
> Ugh I'm sorry, read to the end before responding, Eric.
>
> (I had assumed that an expand operation would require a clean log, but I
> suppose it doesn't have to.)
...why not require a clean filesystem? Most of these 10000x XFS
expansions are gold master cloud images coming from a vendor, which
implies that we could hold them to slightly higher cleanliness levels.
--D
> -Eric
>
>
next prev parent reply other threads:[~2024-07-24 17:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-21 23:01 [PATCH] [RFC] xfs: filesystem expansion design documentation Dave Chinner
2024-07-23 23:58 ` Darrick J. Wong
2024-07-24 0:46 ` Dave Chinner
2024-07-24 15:41 ` Eric Sandeen
2024-07-24 15:44 ` Eric Sandeen
2024-07-24 17:23 ` Darrick J. Wong [this message]
2024-07-24 17:33 ` Eric Sandeen
2024-07-24 21:08 ` Darrick J. Wong
2024-07-24 22:50 ` Eric Sandeen
2024-07-24 23:48 ` Darrick J. Wong
2024-07-25 0:41 ` Dave Chinner
2024-08-02 12:09 ` Brian Foster
2024-08-06 2:01 ` Dave Chinner
2024-08-09 13:31 ` Brian Foster
2024-07-24 22:06 ` Eric Sandeen
2024-07-24 22:12 ` Darrick J. Wong
2024-07-24 22:38 ` Eric Sandeen
2024-07-25 1:42 ` Dave Chinner
2024-07-29 1:45 ` Dave Chinner
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=20240724172334.GY612460@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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