All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 1/2] xfs: set a mount flag when perag reservation is active
Date: Fri, 19 Mar 2021 07:55:36 +1100	[thread overview]
Message-ID: <20210318205536.GO63242@dread.disaster.area> (raw)
In-Reply-To: <20210318161707.723742-2-bfoster@redhat.com>

On Thu, Mar 18, 2021 at 12:17:06PM -0400, Brian Foster wrote:
> perag reservation is enabled at mount time on a per AG basis. The
> upcoming in-core allocation btree accounting mechanism needs to know
> when reservation is enabled and that all perag AGF contexts are
> initialized. As a preparation step, set a flag in the mount
> structure and unconditionally initialize the pagf on all mounts
> where at least one reservation is active.

I'm not sure this is a good idea. AFAICT, this means just about any
filesystem with finobt, reflink and/or rmap will now typically read
every AGF header in the filesystem at mount time. That means pretty
much every v5 filesystem in production...

We've always tried to avoid needing to reading all AG headers at
mount time because that does not scale when we have really large
filesystems (I'm talking petabytes here). We should only read AG
headers if there is something not fully recovered during the mount
(i.e. slow path) and not on every mount.

Needing to do a few thousand synchonous read IOs during mount makes
mount very slow, and as such we always try to do dynamic
instantiation of AG headers...  Testing I've done with exabyte scale
filesystems (>10^6 AGs) show that it can take minutes for mount to
run when each AG header needs to be read, and that's on SSDs where
the individual read latency is only a couple of hundred
microseconds. On spinning disks that can do 200 IOPS, we're
potentially talking hours just to mount really large filesystems...

Hence I don't think that any algorithm that requires reading every
AGF header in the filesystem at mount time on every v5 filesystem
already out there in production (because finobt triggers this) is a
particularly good idea...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2021-03-18 20:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 16:17 [PATCH v3 0/2] xfs: set aside allocation btree blocks from block reservation Brian Foster
2021-03-18 16:17 ` [PATCH v3 1/2] xfs: set a mount flag when perag reservation is active Brian Foster
2021-03-18 20:55   ` Dave Chinner [this message]
2021-03-18 22:19     ` Darrick J. Wong
2021-03-19  1:05       ` Dave Chinner
2021-03-19  1:34         ` Darrick J. Wong
2021-03-19 14:54           ` Brian Foster
2021-03-19  1:43         ` Dave Chinner
2021-03-19  1:48           ` Darrick J. Wong
2021-03-19  2:08             ` Dave Chinner
2021-03-19 14:54           ` Brian Foster
2021-03-23 22:40             ` Dave Chinner
2021-03-24 14:24               ` Brian Foster
2021-03-18 16:17 ` [PATCH v3 2/2] xfs: set aside allocation btree blocks from block reservation Brian Foster
2021-03-18 20:31   ` Darrick J. Wong
2021-03-19 15:00     ` Brian Foster
2021-03-27  1:34       ` Darrick J. Wong
2021-03-27 14:51         ` Brian Foster
2021-04-09 14:17 ` [PATCH v3 0/2] " Brian Foster
  -- strict thread matches above, loose matches on Subject: below --
2021-04-12 13:30 [PATCH v3 REPOST " Brian Foster
2021-04-12 13:30 ` [PATCH v3 1/2] xfs: set a mount flag when perag reservation is active Brian Foster
2021-04-14  0:49   ` Darrick J. Wong
2021-04-20 16:22     ` Brian Foster
2021-04-20 16:23     ` 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=20210318205536.GO63242@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=linux-xfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.