linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
	linux-xfs@vger.kernel.org, david@fromorbit.com
Subject: Re: [PATCH 1/5] xfs_repair: check filesystem geometry before allowing upgrades
Date: Wed, 22 Jun 2022 15:12:31 -0700	[thread overview]
Message-ID: <YrOTz236fFQqx59l@magnolia> (raw)
In-Reply-To: <66855f31-32a0-7ccf-4cc2-ab56e39fe4f2@sandeen.net>

On Wed, Jun 22, 2022 at 01:57:52PM -0500, Eric Sandeen wrote:
> On 5/25/22 12:36 AM, Chandan Babu R wrote:
> > From: "Darrick J. Wong" <djwong@kernel.org>
> > 
> > Currently, the two V5 feature upgrades permitted by xfs_repair do not
> > affect filesystem space usage, so we haven't needed to verify the
> > geometry.
> > 
> > However, this will change once we start to allow the sysadmin to add new
> > metadata indexes to existing filesystems.  Add all the infrastructure we
> > need to ensure that the log will still be large enough, that there's
> > enough space for metadata space reservations, and the root inode will
> > still be where we expect it to be after the upgrade.
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
> > [Recompute transaction reservation values; Exit with error if upgrade fails]
> 
> This is a lot to digest; I'd like to go ahead and merge 3 patches out of
> this 5 patch series and leave this + the upgrade patch until I get a chance
> to digest it a bit more.
> 
> One thing at least, though:
> 
> 
> > +	/*
> > +	 * Would we have at least 10% free space in the data device after all
> > +	 * the upgrades?
> > +	 */
> > +	if (mp->m_sb.sb_fdblocks < mp->m_sb.sb_dblocks / 10)
> > +		printf(_("Filesystem will be low on space after upgrade.\n"));
> > +
> 
> This should be removed, IMHO; what is the point? The user can't do anything about
> it, it proceeds anyway, and for all we know they started with less than 10% free.
> So why bother printing something that might generate questions and support
> calls? I don't think it's useful or actionable information.

Would you rather this exit(1)'d afterwards?  i.e. refuse the upgrade if
the fs doesn't have enough free space?

--D

> Thanks,
> -Eric

  reply	other threads:[~2022-06-22 22:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25  5:36 [PATCH 0/5] xfsprogs: Large extent counters Chandan Babu R
2022-05-25  5:36 ` [PATCH 1/5] xfs_repair: check filesystem geometry before allowing upgrades Chandan Babu R
2022-06-22 18:57   ` Eric Sandeen
2022-06-22 22:12     ` Darrick J. Wong [this message]
2022-05-25  5:36 ` [PATCH 2/5] xfsprogs: Invoke bulkstat ioctl with XFS_BULK_IREQ_NREXT64 flag Chandan Babu R
2022-05-25  5:36 ` [PATCH 3/5] xfs_info: Report NREXT64 feature status Chandan Babu R
2022-05-25  5:36 ` [PATCH 4/5] mkfs: Add option to create filesystem with large extent counters Chandan Babu R
2022-05-25  5:36 ` [PATCH 5/5] xfs_repair: Add support for upgrading to " Chandan Babu R
2022-05-25  9:36 ` [PATCH 0/5] xfsprogs: Large " Chandan Babu R

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=YrOTz236fFQqx59l@magnolia \
    --to=djwong@kernel.org \
    --cc=chandan.babu@oracle.com \
    --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;
as well as URLs for NNTP newsgroup(s).