On Tue, Dec 05, 2017 at 04:30:33PM +0800, Qu Wenruo wrote:
>
>
> On 2017年12月05日 16:26, Anand Jain wrote:
> > btrfs balance needs --full-balance option since 4.6, so check the
> > version and then use it.
> >
> > As this may be useful for other btrfs tests as well, so this patch
> > adds _btrfs_f
On Wed, Nov 15, 2017 at 11:05:15AM +0800, Anand Jain wrote:
> Make sure missing device is included in the alloc list when it is
> scanned on a mounted FS.
>
> This test case needs btrfs kernel patch which is in the ML
> [PATCH] btrfs: handle dynamically reappearing missing device
> Without the k
On Mon, Nov 13, 2017 at 10:25:41AM +0800, Anand Jain wrote:
> Make sure missing device is included in the alloc list when it is
> scanned on a mounted FS.
>
> This test case needs btrfs kernel patch which is in the ML
> [PATCH] btrfs: handle dynamically reappearing missing device
> Without the k
On Wed, Nov 01, 2017 at 06:01:23PM -0600, Liu Bo wrote:
> This is to reproduce a raid6 reconstruction bug after two drives
> getting offline and online via hotplug.
>
> Signed-off-by: James Alandt
> Signed-off-by: Liu Bo
I don't have 5 deletable pool devices to actually test this patch, but
jus
On Thu, Oct 26, 2017 at 07:16:02AM +, Gu, Jinxiang wrote:
> Hi,
>
> > -Original Message-
> > From: Eryu Guan [mailto:eg...@redhat.com]
> > Sent: Thursday, October 26, 2017 2:52 PM
> > To: Gu, Jinxiang/顾 金香
> > Cc: fste...@vger.kernel.org; linux-b
On Thu, Oct 26, 2017 at 01:57:46PM +0800, Gu Jinxiang wrote:
> From: Gu JinXiang
>
> btrfs-progs now support FST in read-only mode, so when space_cache=v2
> enabled, this test case will fail.
> Add message to help user to understand this status.
Sorry, I don't quite understand the new 'FST' feat
On Fri, Oct 13, 2017 at 01:40:05PM -0600, Liu Bo wrote:
> Currently running 'btrfs device delete' can end up with losing data
> raid profile (if any), this test is to reproduce the problem.
>
> The fix is
> "Btrfs: avoid losing data raid profile when deleting a device"
>
> Signed-off-by: Liu
On Mon, Oct 09, 2017 at 11:39:21AM -0600, Liu Bo wrote:
> Currently running 'btrfs device delete' can end up with losing data raid
> profile (if any), this test is to reproduce the problem.
>
> The fix is
> "Btrfs: avoid losing data raid profile when deleting a device"
>
> Signed-off-by: Liu
On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote:
> > > > Hello,
> > > >
> > > > One thing
On Tue, Sep 26, 2017 at 05:18:51PM -0700, Liu Bo wrote:
> On Tue, Sep 26, 2017 at 04:37:52PM -0700, Liu Bo wrote:
> > On Tue, Sep 26, 2017 at 05:02:36PM +0800, Eryu Guan wrote:
> > > On Fri, Sep 22, 2017 at 05:21:27PM -0600, Liu Bo wrote:
> > > > We had a bug in btrf
On Fri, Sep 22, 2017 at 05:21:27PM -0600, Liu Bo wrote:
> We had a bug in btrfs compression code which could end up with a
> kernel panic.
>
> This is adding a regression test for the bug and I've also sent a
> kernel patch to fix the bug.
>
> The patch is "Btrfs: fix kernel oops while reading co
On Mon, Sep 18, 2017 at 04:11:09PM +0800, Gu Jinxiang wrote:
> Resovle the inconsistent of mount option.
> Btrfs use MOUNT_OPTIONS for both scrath_dev and test_dev. Change to
> MOUNT_OPTIONS for scratch mount, and TEST_FS_MOUNT_OPTS for test dev
> mount.
>
> Signed-off-by: Gu Jinxiang
> ---
> As
On Fri, Sep 01, 2017 at 10:14:41AM +0300, Amir Goldstein wrote:
> On Fri, Sep 1, 2017 at 10:04 AM, Eryu Guan wrote:
> > On Fri, Sep 01, 2017 at 02:39:44PM +0900, Misono, Tomohiro wrote:
> >> Several tests uses both _filter_test_dir and _filter_scratch
> >> concatenated
On Fri, Sep 01, 2017 at 02:39:44PM +0900, Misono, Tomohiro wrote:
> Several tests uses both _filter_test_dir and _filter_scratch
> concatenated by pipe to filter $TEST_DIR and $SCRATCH_MNT. However, this
> would fail if the shorter string is a substring of the other (like
> "/mnt" and "/mnt2").
>
On Fri, Sep 01, 2017 at 09:44:59AM +0900, Misono, Tomohiro wrote:
> Ok. I will do that if you won't, though I'm not sure other combination of
> filters would pose the similar problem.
Thanks! Then I'll test :)
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
On Thu, Aug 31, 2017 at 08:53:09AM +0900, Misono, Tomohiro wrote:
> On 2017/08/30 20:09, Eryu Guan wrote:
> > On Wed, Aug 30, 2017 at 04:38:16PM +0900, Misono, Tomohiro wrote:
> >> btrfs/029 uses _filter_testdirs() to filter the name of $TEST_DIR and
> >> $SCRATCH_MNT d
On Wed, Aug 30, 2017 at 04:38:16PM +0900, Misono, Tomohiro wrote:
> btrfs/029 uses _filter_testdirs() to filter the name of $TEST_DIR and
> $SCRATCH_MNT directory.
>
> In this function, it calls both _filter_test_dir and _filter_scratch
> concatenated by pipe. Therefore if $TEST_DIR is a prefix of
On Mon, Aug 14, 2017 at 03:03:13PM +0800, Lu Fengqi wrote:
> I catch this following error from dmesg when this testcase fails.
>
> [17446.661127] Buffer I/O error on dev sdb1, logical block 64, async page read
>
> We expect to inject disk IO errors on the device when xfs_io reads the
> specific f
On Thu, Jul 20, 2017 at 04:03:33PM -0700, Justin Maggard wrote:
> This test case does some concurrent send/receives with qgroups enabled.
> Currently (4.13-rc1) this usually results in btrfs check errors, and
> often also results in a WARN_ON in record_root_in_trans().
>
> Bisecting points to 6426
On Thu, Jul 13, 2017 at 03:10:40PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that a direct IO write works against raid5/6 filesystems and that
> after the write operation we are able to read back the correct data
> and scrub operations don't find any errors.
>
> This test
On Fri, Jun 23, 2017 at 04:25:43PM +0800, Eryu Guan wrote:
> On Wed, Jun 21, 2017 at 10:50:35AM +0300, Nikolay Borisov wrote:
> > When changing the size of disks/filesystem we should always be
> > rounding down to a multiple of sectorsize
> >
> > Signed-off-by: Nikol
On Wed, Jun 21, 2017 at 10:50:35AM +0300, Nikolay Borisov wrote:
> When changing the size of disks/filesystem we should always be
> rounding down to a multiple of sectorsize
>
> Signed-off-by: Nikolay Borisov
Thanks for the update! But I still need some reviews from btrfs list to
see if this is
On Thu, Jun 15, 2017 at 04:45:38PM +0300, Nikolay Borisov wrote:
> When changing the size of disks/filesystem we should always be
> rounding down to a multiple of sectorsize. This is a test for the following
> btrfs patche:
>
> btrfs: Round up values which are written for total_bytes_size
>
> Si
On Wed, Jun 14, 2017 at 07:55:17AM -0400, Jeff Layton wrote:
> On Tue, 2017-06-13 at 16:40 +0800, Eryu Guan wrote:
> > On Mon, Jun 12, 2017 at 08:42:13AM -0400, Jeff Layton wrote:
> > > Make a new btrfs/999 test that works the way Chris Mason suggested:
> > >
>
On Mon, Jun 12, 2017 at 08:42:13AM -0400, Jeff Layton wrote:
> Make a new btrfs/999 test that works the way Chris Mason suggested:
>
> Build a filesystem with 2 devices that stripes the data across
> both devices, but mirrors metadata across both. Then, make one
> of the devices fail and see how f
On Mon, Jun 12, 2017 at 08:42:10AM -0400, Jeff Layton wrote:
> The writeback error handling test requires that you put the journal on a
> separate device. This allows us to use dmerror to simulate data
> writeback failure, without affecting the journal.
>
> xfs already has infrastructure for this
On Mon, Jun 12, 2017 at 08:42:09AM -0400, Jeff Layton wrote:
> I'm working on a set of kernel patches to change how writeback errors
> are handled and reported in the kernel. Instead of reporting a
> writeback error to only the first fsync caller on the file, I aim
> to make the kernel report them
On Mon, Jun 12, 2017 at 08:42:08AM -0400, Jeff Layton wrote:
> v4: respin set based on Eryu's comments
>
> These tests are companion tests to the patchset I recently posted with
> the cover letter:
>
> [PATCH v6 00/20] fs: enhanced writeback error reporting with errseq_t
> (pile #1)
>
> Thi
On Wed, Jun 07, 2017 at 10:34:13AM -0700, Omar Sandoval wrote:
> On Wed, Jun 07, 2017 at 05:36:45PM +0800, Eryu Guan wrote:
> > On Tue, Jun 06, 2017 at 11:57:10PM -0700, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > This is a regression t
On Tue, Jun 06, 2017 at 11:57:10PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is a regression test for "[PATCH] Btrfs: fix delalloc accounting
> leak caused by u32 overflow". It creates a bunch of delalloc extents and
> merges them together to make sure the accounting is done righ
On Tue, Jun 06, 2017 at 05:03:05PM -0700, Omar Sandoval wrote:
> On Sat, Jun 03, 2017 at 12:37:00AM -0700, Christoph Hellwig wrote:
> > This looks like a btrfs-specific test, and not like a generic one
> > to me.
>
> Nothing about the workload itself is btrfs-specific, we just have the
> extra che
On Fri, Jun 02, 2017 at 02:46:52PM +0200, David Sterba wrote:
> On Fri, Jun 02, 2017 at 12:07:37PM +0300, Nikolay Borisov wrote:
> > > +# Make sure that we didn't leak any metadata space.
> > > +if [[ $FSTYP = btrfs ]]; then
> > > + uuid="$(findmnt -n -o UUID "$TEST_DIR")"
> >
> > if we are on btr
On Wed, May 24, 2017 at 05:27:24PM +0800, Qu Wenruo wrote:
>
>
> At 05/24/2017 05:22 PM, Eryu Guan wrote:
> > On Wed, May 24, 2017 at 03:58:11PM +0800, Qu Wenruo wrote:
> > >
> > >
> > > At 05/24/2017 01:16 PM, Qu Wenruo wrote:
> > > >
&g
On Wed, May 24, 2017 at 03:58:11PM +0800, Qu Wenruo wrote:
>
>
> At 05/24/2017 01:16 PM, Qu Wenruo wrote:
> >
> >
> > At 05/24/2017 01:08 PM, Eryu Guan wrote:
> > > On Wed, May 24, 2017 at 12:28:34PM +0800, Qu Wenruo wrote:
> > > >
> >
On Wed, May 24, 2017 at 12:28:34PM +0800, Qu Wenruo wrote:
>
>
> At 05/24/2017 12:24 PM, Eryu Guan wrote:
> > On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote:
> > >
> > >
> > > At 05/23/2017 07:13 PM, Eryu Guan wrote:
> > > > On
On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote:
>
>
> At 05/23/2017 07:13 PM, Eryu Guan wrote:
> > On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
> > > [BUG]
> > > If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:
> [BUG]
> If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142
> generic/143 and generic/154, it will cause false alert like:
> cp: failed to clone '/mnt/test/test-154/file2' from
> '/mnt/test/test-154/file1': Invalid argumen
On Tue, May 09, 2017 at 11:56:11AM -0600, Liu Bo wrote:
> This is to test whether buffered read retry-repair code is able to work in
> raid1 case as expected.
>
> Please note that without checksum, btrfs doesn't know if the data used to
> repair is correct, so repair is more of resync which makes
On Tue, May 09, 2017 at 11:56:08AM -0600, Liu Bo wrote:
> This case tests whether dio read can repair the bad copy if we have
> a good copy.
>
> Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> introduced the regression.
>
> The upstream fix is
> Btrfs: fix inval
On Tue, May 09, 2017 at 11:56:07AM -0600, Liu Bo wrote:
> _get_current_dmesg can be used to grep customized pattern.
>
> Signed-off-by: Liu Bo
I can't apply this patch on top of current master, perhaps it needs a
rebase :)
> ---
> common/rc | 9 +++--
> 1 file changed, 7 insertions(+), 2 d
On Fri, Apr 28, 2017 at 11:25:52AM -0600, Liu Bo wrote:
> This case tests whether dio read can repair the bad copy if we have
> a good copy.
>
> Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> introduced the regression.
>
> The upstream fix is
> Btrfs: fix inval
On Wed, Apr 12, 2017 at 02:52:23PM +0200, David Sterba wrote:
> > > I understand that we need to do corruption so that we can test if the
> > > repair works, but I'm not sure if the output format will change, or if
> > > the program will get replace by "btrfs inspect-internal" group.
> >
> > In
On Wed, Apr 05, 2017 at 03:32:30PM +0300, Amir Goldstein wrote:
> On Wed, Apr 5, 2017 at 3:30 PM, David Sterba wrote:
> > On Wed, Apr 05, 2017 at 11:53:41AM +0100, David Howells wrote:
> >> I've added a test to xfstests that exercises the new statx syscall.
> >> However,
> >> it fails on btrfs:
On Fri, Apr 07, 2017 at 10:13:09AM +0100, Filipe Manana wrote:
> On Fri, Apr 7, 2017 at 9:51 AM, Eryu Guan wrote:
> > On Tue, Apr 04, 2017 at 07:34:29AM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> For example NFS 4.2 supports f
t.
>
> Suggested-by: Eryu Guan
> Signed-off-by: Filipe Manana
> ---
> common/rc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/rc b/common/rc
> index e1ab2c6..3d0f089 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -202
On Thu, Apr 06, 2017 at 11:28:01AM -0500, Eric Sandeen wrote:
> On 4/6/17 11:26 AM, Theodore Ts'o wrote:
> > On Wed, Apr 05, 2017 at 10:35:26AM +0800, Eryu Guan wrote:
> >>
> >> Test fails with ext3/2 when driving with ext4 driver, fiemap changed
> >> after
t.
>
> Suggested-by: Eryu Guan
> Signed-off-by: Filipe Manana
> ---
> common/rc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/rc b/common/rc
> index e1ab2c6..3d0f089 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -202
On Wed, Apr 05, 2017 at 11:13:56AM +0100, Filipe Manana wrote:
> On Wed, Apr 5, 2017 at 10:46 AM, Eryu Guan wrote:
> > On Tue, Apr 04, 2017 at 03:23:35AM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> Test that a filesystem's
On Tue, Apr 04, 2017 at 03:23:35AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that a filesystem's implementation of the stat(2) system call
> reports correct values for the number of blocks allocated for a file
> when there are delayed allocations.
>
> This test is motivate
On Mon, Apr 03, 2017 at 03:09:23PM +0800, Qu Wenruo wrote:
> As long as we don't modify the on-disk data, fiemap result should always
> be constant.
>
> Operation like cycle mount and sleep should not affect fiemap result.
> While unfortunately, btrfs doesn't follow that behavior.
>
> Btrfs fiema
On Mon, Apr 03, 2017 at 11:01:39AM +0800, Qu Wenruo wrote:
> Btrfs allows inline file extent if and only if
> 1) It's at offset 0
> 2) It's smaller than min(max_inline, page_size)
>Although we don't specify if the size is before compression or after
>compression.
>At least according to
On Thu, Mar 16, 2017 at 05:08:51PM +0800, Qu Wenruo wrote:
> Btrfs balance will reloate date extent, but its hash is removed too late
^^^ relocate
> at run_delayed_ref() time, which will cause extent ref increased
> during balance, cause either find_data_references() gives
On Tue, Mar 21, 2017 at 03:36:54PM +0800, Qu Wenruo wrote:
>
>
> At 03/21/2017 03:23 PM, Eryu Guan wrote:
> > On Thu, Mar 16, 2017 at 09:50:24AM +0800, Qu Wenruo wrote:
> > > Btrfs in-band de-duplication test cases for in-memory backend, which
> > > covers
On Thu, Mar 16, 2017 at 09:50:24AM +0800, Qu Wenruo wrote:
> Btrfs in-band de-duplication test cases for in-memory backend, which covers
> the bugs exposed during the development.
Sorry, I'm having trouble enabling inband dedupe in tests, I always get
ioctl failure, $seqres.full shows:
btrfs-prog
On Tue, Mar 21, 2017 at 01:22:33PM +0800, Qu Wenruo wrote:
>
>
> At 03/21/2017 12:51 PM, Eryu Guan wrote:
> > Hi Qu,
> >
> > On Thu, Mar 16, 2017 at 05:08:48PM +0800, Qu Wenruo wrote:
> > > Btrfs in-band de-duplication test cases for in-memory backend, which
Hi Qu,
On Thu, Mar 16, 2017 at 05:08:48PM +0800, Qu Wenruo wrote:
> Btrfs in-band de-duplication test cases for in-memory backend, which covers
> the bugs exposed during the development.
Do you have a kernel tree that contains the in-band patches so that I
and others could try and run these tests
On Thu, Mar 16, 2017 at 09:50:27AM +0800, Qu Wenruo wrote:
> Btrfs balance with inband dedupe enable/disable will expose a lot of
> hidden dedupe bug:
>
> 1) Enable/disable race bug
> 2) Btrfs dedupe tree balance corrupted delayed_ref
> 3) Btrfs disable and balance will cause balance BUG_ON
>
> R
On Thu, Mar 16, 2017 at 09:50:25AM +0800, Qu Wenruo wrote:
> Add basic test for btrfs in-band de-duplication(inmemory backend), including:
> 1) Enable
> 3) Dedup rate
> 4) File correctness
> 5) Disable
>
> Signed-off-by: Qu Wenruo
I haven't looked into this patchset closely, this may need more h
On Wed, Mar 15, 2017 at 11:01:05AM +0800, Qu Wenruo wrote:
> Any comment on this patch?
It's already committed, see commit 726726d.
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[please cc linux-btrfs@vger.kernel.org for btrfs specific tests]
On Mon, Mar 13, 2017 at 04:37:16PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> If we create and delete files within the qgroup limits, qg->reserved
> (allocations before commits) over-inflates and causes -EDQUOT t
On Tue, Feb 28, 2017 at 08:31:50AM -0800, Darrick J. Wong wrote:
> On Tue, Feb 28, 2017 at 04:15:02PM +0800, Eryu Guan wrote:
> > On Fri, Feb 24, 2017 at 05:12:57PM -0800, Darrick J. Wong wrote:
> > > From: Darrick J. Wong
> > >
> > > If we reflink a file wit
On Fri, Feb 24, 2017 at 05:12:57PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> If we reflink a file with N blocks to another file one block at a time,
> does the destination file end up with the same number of extents as the
> source file? In other words, does the filesystem succee
On Thu, Feb 16, 2017 at 06:32:49PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()".
> It fails for zlib on v4.10-rc[1-7].
>
> Signed-off-by: Omar Sandoval
> ---
> This runs in <60 seconds on my test VM, which I think q
On Wed, Feb 01, 2017 at 09:50:28PM +0800, Anand Jain wrote:
> /dev/urandom is incompressible and, /dev/zero is highly compressible,
> so both are less effective in testing the compress code logic in btrfs.
>
> This patch introduces a text data generator
> cat /dev/urandom | od
I noticed that the
On Wed, Jan 25, 2017 at 05:30:32PM +0800, Qu Wenruo wrote:
>
>
> At 01/25/2017 05:20 PM, Eryu Guan wrote:
> > On Tue, Jan 24, 2017 at 10:50:29PM -0800, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > This is a regression test for "Btr
On Tue, Jan 24, 2017 at 10:50:29PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is a regression test for "Btrfs: disable xattr operations on
> subvolume directories". On v4.9, it will result in an aborted
> transaction.
>
> Signed-off-by: Omar Sandoval
Looks good to me overall, t
On Thu, Jan 12, 2017 at 03:13:37AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that an incremental send operation works after moving a directory
> into a new parent directory, deleting its previous parent directory and
> creating a new inode that has the same inode number as
On Wed, Jan 18, 2017 at 07:17:02AM +0530, Lakshmipathi.G wrote:
> Signed-off-by: Lakshmipathi.G
Need detailed test description in commit log too.
> ---
> tests/btrfs/047 | 108
>
> tests/btrfs/047.out | 1 +
> tests/btrfs/group | 1
On Thu, Jan 12, 2017 at 02:22:06PM -0800, Liu Bo wrote:
> On btrfs, if a large dio write (>=128MB) got splitted, the outstanding_extents
> assertion would complain. Note that CONFIG_BTRFS_ASSERT is required.
>
> Regression test for
> Btrfs: adjust outstanding_extents counter properly when dio w
On Wed, Jan 04, 2017 at 04:37:08PM +0800, Qu Wenruo wrote:
> Test case like generic/304 and generic/158 can cause false alert due to
> the error output change of xfs_io.
>
> For error case, xfs_io mostly reports error like "dedupe: ERROR STRING"
> while under certain case, it reports error like "X
On Mon, Jan 02, 2017 at 10:16:17PM -0500, Su Yue wrote:
> Btrfs-progs v4.9 changed "device status" output by adding one more
> space, which differs from golden output.
> Fix it by using filter '_filter_spaces' to convert multi space into one.
You missed your SOB line. I added
Signed-off-by: Su Yu
On Thu, Dec 29, 2016 at 11:14:10PM -0500, Su Yue wrote:
> Btrfs-progs v4.9 changed "device status" output by adding one more
> space, which differs from golden output.
>
> Fix it by introducing new filter to convert multi space into one.
>
> Signed-off-by: Su Yue
> ---
> common/filter |
On Thu, Dec 22, 2016 at 10:02:51AM +0800, Qu Wenruo wrote:
> Although by design, btrfs scrub and replace share the same code path, so
> they are exclusive to each other.
>
> But the fact is, there is still some critical region not protected well,
> so we can have the following kernel panic, especi
On Tue, Dec 20, 2016 at 09:24:56AM +0800, Qu Wenruo wrote:
> Btrfs upstream doesn't accept stream-version, so the test is never ran
> on upstream kernel nor btrfs-progs.
>
> Just remove it.
>
> Signed-off-by: Qu Wenruo
Looks fine to me, but I'd like to see an ack or review from btrfs
developers
On Thu, Dec 08, 2016 at 05:20:49PM +0800, Qu Wenruo wrote:
>
>
> At 12/08/2016 04:47 PM, Eryu Guan wrote:
> > On Thu, Dec 08, 2016 at 04:12:13PM +0800, Qu Wenruo wrote:
> > > Introduce new _require_btrfs_qgroup_report function, which will check
> > > the acces
On Thu, Dec 08, 2016 at 04:12:13PM +0800, Qu Wenruo wrote:
> Introduce new _require_btrfs_qgroup_report function, which will check
> the accessibility to "btrfs check --qgroup-report", then set a global
> flag to info _check_scratch_fs() to do extra qgroup check.
>
> Signed-off-by: Qu Wenruo
> --
On Thu, Dec 08, 2016 at 10:04:56AM +0800, Qu Wenruo wrote:
> Introduce new _require_btrfs_qgroup_report function, which will check
> the accessibility to "btrfs check --qgroup-report", then set a global
> flag to info _check_scratch_fs() to do extra qgroup check.
>
> Signed-off-by: Qu Wenruo
> --
On Thu, Dec 08, 2016 at 10:04:55AM +0800, Qu Wenruo wrote:
> Rename _require_btrfs() to _require_btrfs_subcommand() to avoid
> confusion, as all other _require_btrfs_* has a quite clear suffix, like
> _require_btrfs_mkfs_feature() or _require_btrfs_fs_feature().
>
> Also enhance _require_btrfs_sub
On Tue, Nov 22, 2016 at 04:38:08PM +0800, Qu Wenruo wrote:
> Despite the scrub test cases in fstests, there is not even one test case
> which really checked if scrub can recover data.
>
> In fact, btrfs scrub for RAID56 will even corrupt correct data stripes.
>
> So let's start from the needed fa
On Tue, Nov 22, 2016 at 04:38:09PM +0800, Qu Wenruo wrote:
> Rename _require_btrfs() to _require_btrfs_subcommand() to avoid
> confusion, as all other _require_btrfs_* has a quite clear suffix, like
> _require_btrfs_mkfs_feature() or _require_btrfs_fs_feature().
>
> Signed-off-by: Qu Wenruo
> ---
On Tue, Nov 29, 2016 at 03:32:54PM +0800, Qu Wenruo wrote:
> Old btrfs qgroup test cases uses fix golden output numbers, which limits
> the coverage since they can't handle mount options like compress or
> inode_map, and cause false alert.
>
> Introduce _btrfs_check_scratch_qgroup() function to ch
On Mon, Nov 28, 2016 at 10:50:30AM +0800, Qu Wenruo wrote:
> Any comment?
Sorry for the late review, I'm planning to look at them this week.
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu, Nov 17, 2016 at 10:06:48AM +0800, Qu Wenruo wrote:
> For fs support reflink, some of them (OK, btrfs again) doesn't split
> SHARED flag for extent fiemap reporting.
>
> For example:
> 0 4K 8K
>/ File1: Extent 0 \
> /\
> |<- On disk Extent-->|
On Thu, Nov 17, 2016 at 10:14:12AM -0800, Omar Sandoval wrote:
> On Thu, Nov 17, 2016 at 01:26:11PM +0800, Eryu Guan wrote:
> > On Wed, Nov 16, 2016 at 04:29:34PM -0800, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > There have been a coupl
On Wed, Nov 16, 2016 at 04:29:34PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> There have been a couple of logic bugs in `btrfs_get_extent()` which
> could lead to spurious -EEXIST errors from read or write. This test
> exercises those conditions by having two threads race to add an ext
On Fri, Nov 11, 2016 at 02:30:04PM -0800, Liu Bo wrote:
> This updates generic/098 by adding a sync option, i.e. 'sync' after the second
> write, and with btrfs's NO_HOLES, we could still get wrong isize after
> remount.
>
> This gets fixed by the patch
>
> 'Btrfs: fix truncate down when no_hole
On Thu, Nov 10, 2016 at 10:42:36AM +0800, Qu Wenruo wrote:
>
>
> At 11/10/2016 10:19 AM, Dave Chinner wrote:
> > On Thu, Nov 10, 2016 at 08:34:20AM +0800, Qu Wenruo wrote:
> > > At 11/09/2016 05:43 PM, Eryu Guan wrote:
> > > > On Wed, Nov 09, 2016
On Wed, Nov 09, 2016 at 08:24:38AM +0800, Qu Wenruo wrote:
>
>
> At 11/08/2016 06:58 PM, Eryu Guan wrote:
> > On Tue, Nov 08, 2016 at 05:15:15PM +0800, Qu Wenruo wrote:
> > > Due to the fact that btrfs uses different max extent size for
> > > compressed and no
On Tue, Nov 08, 2016 at 05:15:15PM +0800, Qu Wenruo wrote:
> Due to the fact that btrfs uses different max extent size for
> compressed and non-compressed write, it calculates metadata reservation
> incorrectly.
>
> This can leads to false ENOSPC alert for compressed write.
>
> This test case wil
On Wed, Nov 02, 2016 at 12:07:26PM +0800, Wang Xiaoguang wrote:
> In original common/populate codes, we put _require_xfs_io_command "falloc" and
> _require_xfs_io_command "fpunch" in the begin of common/populate, but it's
> not appropriate, for fs, which does not support falloc and punch, will not
On Wed, Nov 02, 2016 at 06:22:58PM +0800, Wang Xiaoguang wrote:
> hi Eryu,
>
> There has already be a generic/102 doing this test...
> Thanks for you kindly review and sorry for wasting your time.
I had impression yesterday that we have a case that does exactly the
same test, and I searched but d
On Tue, Nov 01, 2016 at 07:19:30PM +0800, Wang Xiaoguang wrote:
> In btrfs, sometimes though the number of created files' consumed disk space
> are not larger than fs's free space, we can still get some ENOSPC error, it
> may be that btrfs does not try hard to reclaim disk space(I have sent kernel
On Fri, Oct 28, 2016 at 09:44:06AM +0800, robbieko wrote:
> From: Robbie Ko
>
> Test that an incremental send operation dosen't work because
> it tries to rename a directory which is already deleted.
>
> This test exercises scenarios used to fail in btrfs and are fixed by
> the following patch f
On Fri, Oct 28, 2016 at 09:44:03AM +0800, robbieko wrote:
> From: Robbie Ko
>
> Test that an incremental send operation doesn't work because
> there's a name collision in the destination and it's not checked
> corretly before the rename operation applies.
>
> This test exercises scenarios used t
On Fri, Oct 28, 2016 at 03:05:55PM +0800, Wang Xiaoguang wrote:
> hi,
>
> On 10/27/2016 07:25 PM, Eryu Guan wrote:
> > On Wed, Oct 26, 2016 at 05:52:11PM +0800, Wang Xiaoguang wrote:
> > > When enabling btrfs compression, original codes can not fill fs
> > > corr
On Fri, Oct 28, 2016 at 03:00:29PM +0800, Wang Xiaoguang wrote:
> hi,
>
> On 10/28/2016 01:13 AM, Darrick J. Wong wrote:
> > On Wed, Oct 26, 2016 at 05:52:11PM +0800, Wang Xiaoguang wrote:
> > > When enabling btrfs compression, original codes can not fill fs
> > > correctly, here we introduce _fil
On Wed, Oct 26, 2016 at 05:52:11PM +0800, Wang Xiaoguang wrote:
> When enabling btrfs compression, original codes can not fill fs
> correctly, here we introduce _fill_fs() in common/rc, which'll keep
> creating and writing files until enospc error occurs. Note _fill_fs
> is copied from tests/generi
On Thu, Sep 22, 2016 at 12:37:53PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> The behavior of different combinations of space_cache mount options
> wasn't well defined, which led to a regression between my initial
> patches adding the free space tree and the 4.5 release. Add a test to
On Wed, Sep 21, 2016 at 08:32:33AM -0400, je...@suse.com wrote:
> From: Jeff Mahoney
>
> There was a bug where the btrfs snapshot/subvol creation ioctls
> would accept a regular file and then Oops when it tried to use
> the file inode operations to do a lookup.
>
> This also adds an ioctl-helper
On Fri, Sep 23, 2016 at 11:12:07AM +0800, Wang Xiaoguang wrote:
> In btrfs, there is a bug about btrfs' truncate codes, it'll leak
> some fs space as the truncate operation proceeds. If this truncate
> operation is very large, later metadata request in this truncate
> operation may fail for enospc
101 - 200 of 471 matches
Mail list logo
