From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
Cc: Dave Chinner <david@fromorbit.com>,
fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] generic: make 17[1-4] work well when btrfs compression is enabled
Date: Sun, 9 Oct 2016 21:25:27 -0700 [thread overview]
Message-ID: <20161010042527.GA30576@birch.djwong.org> (raw)
In-Reply-To: <57FB0FAF.4080200@cn.fujitsu.com>
On Mon, Oct 10, 2016 at 11:49:03AM +0800, Wang Xiaoguang wrote:
> hi,
>
> On 10/10/2016 05:04 AM, Darrick J. Wong wrote:
> >On Sat, Oct 08, 2016 at 01:36:10AM +1100, Dave Chinner wrote:
> >>On Fri, Oct 07, 2016 at 03:00:42PM +0800, Wang Xiaoguang wrote:
> >>>When enabling btrfs compression, original codes can not fill fs
> >>>correctly, fix this.
> >>>
> >>>Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
> >>>---
> >>> tests/generic/171 | 4 +---
> >>> tests/generic/172 | 2 +-
> >>> tests/generic/173 | 4 +---
> >>> tests/generic/174 | 4 +---
> >>> 4 files changed, 4 insertions(+), 10 deletions(-)
> >>>
> >>>diff --git a/tests/generic/171 b/tests/generic/171
> >>>index f391685..d2ae8e4 100755
> >>>--- a/tests/generic/171
> >>>+++ b/tests/generic/171
> >>>@@ -75,9 +75,7 @@ _cp_reflink $testdir/bigfile $testdir/clonefile
> >>> sync
> >>> echo "Allocate the rest of the space"
> >>>-nr_free=$(stat -f -c '%f' $testdir)
> >>>-touch $testdir/file0 $testdir/file1
> >Why remove this line which ensures that the inode we're going to use (file1)
> >later in the test has been allocated /before/ we try to eat all the space?
> Sorry, I don't understand :)
> In generic/171, generic/172, generic/173, generic/174, you created file0 and
> file1, but I don't see test cases use them and they are empty.
>
> >
> >>>-_pwrite_byte 0x61 0 $((blksz * nr_free)) $testdir/eat_my_space >> $seqres.full 2>&1
> >>>+dd if=/dev/zero of=$testdir/eat_my_space >> $seqres.full 2>&1
> >Uh... isn't a bunch of zeroes just as compressible as 0x61?
> 0x61 is also compressible.
> >I suppose
> >the point here is to write until write returns ENOSPC, since in btrfs
> >land we can't assume that writing $nr blocks will use up at least that
> >much space.
> Yes.
Ok, just making sure I figured it out correctly. :)
> >
> >Does XFS reflink still pass this test with this patch?
> Could you please give a stable xfs repotory that supports xfs reflink,
> thanks.
The for-next branch of Dave Chinner's kernel tree:
https://git.kernel.org/cgit/linux/kernel/git/dgc/linux-xfs.git/?h=for-next
And userspace programs in my repo:
https://github.com/djwong/xfsprogs/tree/for-dave-for-4.9-10
(I wouldn't call them stable, but they are what's submitted for 4.9.)
> >>Please don't replace xfs_io writes using a specific data pattern
> >>with dd calls that write zeros. Indeed, we don't use dd for new
> >>tests anymore - xfs_io should be used.
> >>
> >>Write a function that fills all the remaining free space (one may
> >>already exist) and call it in all these places.
> >Yeah, there already are a few of these...
> OK, I'll use it, thanks.
No problem! :)
--D
>
> Regards,
> Xiaoguang Wang
> >
> >--D
> >
> >>Cheers,
> >>
> >>Dave.
> >>--
> >>Dave Chinner
> >>david@fromorbit.com
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
>
prev parent reply other threads:[~2016-10-10 4:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-07 7:00 [PATCH] generic: make 17[1-4] work well when btrfs compression is enabled Wang Xiaoguang
2016-10-07 14:36 ` Dave Chinner
2016-10-09 21:04 ` Darrick J. Wong
2016-10-10 3:49 ` Wang Xiaoguang
2016-10-10 4:25 ` Darrick J. Wong [this message]
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=20161010042527.GA30576@birch.djwong.org \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=wangxg.fnst@cn.fujitsu.com \
/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