All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Eryu Guan <guaneryu@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	stable <stable@vger.kernel.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Brian Foster <bfoster@redhat.com>,
	Sasha Levin <alexander.levin@microsoft.com>
Subject: Re: [PATCH] xfs: truncate transaction does not modify the inobt
Date: Tue, 6 Nov 2018 21:18:21 -0800	[thread overview]
Message-ID: <20181107051821.GZ4135@magnolia> (raw)
In-Reply-To: <CAOQ4uxgVFm7CyhseKtNMOcf8ipTJWD+YJSaG6am1xo0F1hcTDQ@mail.gmail.com>

On Wed, Nov 07, 2018 at 07:09:42AM +0200, Amir Goldstein wrote:
> On Mon, Nov 5, 2018 at 7:57 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Sat, Nov 3, 2018 at 7:15 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > From: Brian Foster <bfoster@redhat.com>
> > >
> > > The truncate transaction does not ever modify the inode btree, but
> > > includes an associated log reservation. Update
> > > xfs_calc_itruncate_reservation() to remove the reservation
> > > associated with inobt updates.
> > >
> > > [Amir:  This commit was merged for kernel v4.16 and a twin commit was
> > >         merged for xfsprogs v4.16. As a result, a small xfs filesystem
> > >         formatted with features -m rmapbt=1,reflink=1 using mkfs.xfs
> > >         version >= v4.16 cannot be mounted with kernel < v4.16.
> > >
> > >         For example, xfstests generic/17{1,2,3} format a small fs and
> > >         when trying to mount it, they fail with an assert on this very
> > >         demonic line:
> > >
> > >  XFS (vdc): Log size 3075 blocks too small, minimum size is 3717 blocks
> > >  XFS (vdc): AAIEEE! Log failed size checks. Abort!
> > >  XFS: Assertion failed: 0, file: src/linux/fs/xfs/xfs_log.c, line: 666
> > >
> > >         The simple solution for stable kernels is to apply this patch,
> > >         because mkfs.xfs v4.16 is already in the wild, so we have to
> > >         assume that xfs filesystems with a "too small" log exist.
> > >         Regardless, xfsprogs maintainers should also consider reverting
> > >         the twin patch to stop creating those filesystems for the sake
> > >         of users with unpatched kernels.]
> > >
> > > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > > Reviewed-by: Dave Chinner <dchinner@redhat.com>
> > > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > Cc: <stable@vger.kernel.org> # v4.9+
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > ---
> > >
> > > Darrick/Dave,
> > >
> > > It took me a while to figure out what was going on with my test systems
> > > when small test partitions (10G) stopped working with older kernels.
> > >
> > > Please bless this change for stable and consider the remedie for mkfs.xfs
> > > I verified that patch cleanly applies to stable kernels 4.14.y and 4.9.y
> > > and that I can mount a filsystem created with new mkfs.xfs.
> > >
> > > I am now running quick tests on stable 4.14.y with configs 4k, 1k,
> > > reflink,reflink+overlay to verify no regressions from this patch.
> > >
> >
> > FYI no regressions detected.
> >
> > Thoughts?
> >
> 
> Maybe you'd want to chalk it up to reflink/rmapbt being Experimental
> before kernel 4.16? so the change in "minimum log size" is an on-disk format
> change prior to removing the Experimental label??

TBH nobody should be using reflink/rmap on 4.14 kernels, ever. :D

That said... does it change the minimum log size for (finobt, !reflink,
!rmap) filesystems?  That might be a bigger worry.  I /think/ the
transaction reservation change is fine, though I defer to Amir on
testing... :)

--D

> Thanks,
> Amir.

  reply	other threads:[~2018-11-07 14:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-03 17:15 [PATCH] xfs: truncate transaction does not modify the inobt Amir Goldstein
2018-11-05 17:57 ` Amir Goldstein
2018-11-07  5:09   ` Amir Goldstein
2018-11-07  5:18     ` Darrick J. Wong [this message]
2018-11-07  5:31       ` Amir Goldstein
2018-11-07 22:56         ` Sasha Levin

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=20181107051821.GZ4135@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=alexander.levin@microsoft.com \
    --cc=amir73il@gmail.com \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guaneryu@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@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.