From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2] xfs: byte range buffer dirty region tracking
Date: Thu, 15 Feb 2018 09:05:32 +1100 [thread overview]
Message-ID: <20180214220532.GJ7000@dastard> (raw)
In-Reply-To: <20180214180807.GA43414@bfoster.bfoster>
On Wed, Feb 14, 2018 at 01:08:07PM -0500, Brian Foster wrote:
> On Wed, Feb 14, 2018 at 08:49:12AM -0800, Darrick J. Wong wrote:
> > On Wed, Feb 14, 2018 at 08:09:39AM -0500, Brian Foster wrote:
> > > On Wed, Feb 14, 2018 at 09:02:20AM +1100, Dave Chinner wrote:
> > > Yep. It's a specially crafted symlink creation on a small FSB, v4
> > > filesystem with fragmented free space. We log symlink buffers on v4
> > > filesystems without any header, so the buffer content is not dictated by
> > > any internal fs metadata format. If the link target is large enough to
> > > span multiple blocks and free space is fragmented such that those blocks
> > > are discontiguous, we can end up logging (solely) the first byte of the
> > > last buffer of the link target.
I'd completely forgotten about that whacky corner case in the v4
format. :(
> > > This is actually reproducible on demand so I'll just append a basic
> > > recipe rather than collect the debug data and whatnot..
> > >
> > > Brian
> > >
> > > --- 8< ---
> > >
> > > dev=<dev>
> > > mnt=/mnt
> > >
> > > sym=`for i in $(seq 0 512); do echo -n a; done`
> > >
> > > mkfs.xfs -f -mcrc=0 -bsize=512 -dsize=25m $dev
> > > mount $dev $mnt
> > >
> > > dd if=/dev/zero of=$mnt/spc1
> > > ~/xfstests-dev/src/punch-alternating $mnt/spc1
> > > dd if=/dev/zero of=$mnt/spc2
> > > xfs_io -c "fpunch 5m 25m" $mnt/spc2
> > >
> > > for i in $(seq 0 2); do
> > > ln -s $sym $mnt/link.$i
> > > xfs_io -c fsync $mnt
> > > done
> > >
> > > umount $mnt
> >
> > Did one of the "fragment free space, do stuff" xfstests hit this? If
> > not, would it be worth turning into a test?
> >
>
> This was just an experiment on this patch. I haven't run xfstests so I
> can't say for sure whether some existing test would have caught it
> (though I suspect Dave would have hit the problem by now, if so). I'm
Nope, a v4 512 byte block size filesystem is so far outside my
normal test config matrix it's not funny. In fact, I almost never
test on v4 filesystems anymore, and I rarely think of them when
developing new code as it's essentially a legacy format now....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-02-14 22:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 1:05 [PATCH] xfs: byte range buffer dirty region tracking Dave Chinner
2018-02-01 5:11 ` Darrick J. Wong
2018-02-01 8:14 ` Dave Chinner
2018-02-01 20:35 ` Darrick J. Wong
2018-02-01 23:16 ` Dave Chinner
2018-02-01 23:22 ` Darrick J. Wong
2018-02-01 23:55 ` Dave Chinner
2018-02-02 10:56 ` Brian Foster
2018-02-05 0:34 ` [PATCH v2] " Dave Chinner
2018-02-06 16:21 ` Brian Foster
2018-02-12 2:41 ` Dave Chinner
2018-02-12 14:26 ` Brian Foster
2018-02-12 21:18 ` Dave Chinner
2018-02-13 13:15 ` Brian Foster
2018-02-13 22:02 ` Dave Chinner
2018-02-14 13:09 ` Brian Foster
2018-02-14 16:49 ` Darrick J. Wong
2018-02-14 18:08 ` Brian Foster
2018-02-14 22:05 ` Dave Chinner [this message]
2018-02-14 22:30 ` Dave Chinner
2018-02-15 13:42 ` 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=20180214220532.GJ7000@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.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.