On Tue, Nov 06, 2018 at 02:06:30PM +0100, David Sterba wrote:
> On Mon, Nov 05, 2018 at 12:09:31AM +0800, Eryu Guan wrote:
> > On Fri, Nov 02, 2018 at 02:29:35PM -0700, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > This series fixes a couple of
On Fri, Nov 02, 2018 at 02:29:35PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This series fixes a couple of generic swapfile tests and adds some
> Btrfs-specific swapfile tests. Btrfs swapfile support is scheduled for
> 4.21 [1].
>
> 1:
On Tue, Oct 09, 2018 at 02:28:21AM +0800, Anand Jain wrote:
> We have a known bug in btrfs, that we let the device path be changed
> after the device has been mounted. So using this loop hole the new
> copied device would appears as if its mounted immediately after its
> been copied. So this test
On Wed, Sep 26, 2018 at 12:08:56PM +0800, Anand Jain wrote:
>
>
> On 09/25/2018 06:54 PM, Nikolay Borisov wrote:
> >
> >
> > On 25.09.2018 07:24, Anand Jain wrote:
> > > Open code helps to grep and find out parameter sent to the
> > > _scratch_mkfs_sized here.
> > >
> > > Signed-off-by: Anand
On Tue, Sep 25, 2018 at 12:24:16PM +0800, Anand Jain wrote:
> If btrfs need to be tested at its default blockgroup which is non-mixed,
> then it needs at least 256mb.
>
> Signed-off-by: Anand Jain
(Sorry for the late review..)
> ---
> tests/generic/077 | 3 +--
> 1 file changed, 1
On Mon, Oct 01, 2018 at 04:44:35PM +0800, Anand Jain wrote:
> We have a known bug in btrfs, that we let the device path be changed
> after the device has been mounted. So using this loop hole the new
> copied device would appears as if its mounted immediately after its
> been copied. So this test
On Mon, Sep 24, 2018 at 07:47:39PM +0800, Anand Jain wrote:
> Try to punch hole with unaligned size and offset when the FS
> returns ENOSPC
>
> Signed-off-by: Anand Jain
> ---
> This test case fails on btrfs as of now.
>
> tests/btrfs/172 | 66
>
On Wed, Sep 05, 2018 at 02:35:12PM +0800, Anand Jain wrote:
> Originally this test case was designed to work with only 4K sectorsize.
> Now enhance it to work with any sector sizes and makes the following
> changes:
> Output file not to contain any traces of sector size.
> Use max_inline=0 mount
On Sun, Aug 19, 2018 at 04:41:31PM +0100, Filipe Manana wrote:
> On Sun, Aug 19, 2018 at 3:07 PM, Eryu Guan wrote:
> > On Fri, Aug 17, 2018 at 09:39:24AM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> Test that deduplicati
On Fri, Aug 17, 2018 at 09:39:24AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that deduplication of an entire file that has a size that is not
> aligned to the filesystem's block size into a different file does not
> corrupt the destination's file data.
>
> This test is
On Fri, Aug 10, 2018 at 05:10:29PM +0800, Qu Wenruo wrote:
>
>
> On 8/10/18 4:54 PM, Filipe Manana wrote:
> > On Fri, Aug 10, 2018 at 9:46 AM, Qu Wenruo wrote:
> >>
> >>
> >> On 8/9/18 5:26 PM, Filipe Manana wrote:
> >>> On Thu, Aug 9, 2018 at 8:45 AM, Qu Wenruo wrote:
> This bug is
On Fri, Jul 06, 2018 at 02:01:37PM +0800, Anand Jain wrote:
> This test case verifies if the device ready return success after the
> device delete.
>
> Signed-off-by: Anand Jain
Need some helps from btrfs folks to see if it's a valid test. Thanks!
Eryu
> ---
> v1->v2: use _run_btrfs_util_prog
On Tue, Jul 03, 2018 at 04:47:53PM +0800, Anand Jain wrote:
> This test case verifies if the device ready return success after the
> device delete.
>
> Signed-off-by: Anand Jain
Looks fine to me overall, but I may need some helps from btrfs folks :)
> ---
> tests/btrfs/168 | 68
>
On Thu, Jun 28, 2018 at 08:11:00AM +0300, Nikolay Borisov wrote:
>
>
> On 1.06.2018 04:34, Qu Wenruo wrote:
> > This is a long existing bug (from 2012) but exposed by a reporter
> > recently, that when compressed extent without data csum get written to
> > device-replace target device, the
On Thu, Jun 21, 2018 at 03:04:22PM +0800, Lu Fengqi wrote:
> Since btrfs-dump-tree has been removed from btrfs-progs, use btrfs
> inspect-internal dump-tree instead of btrfs-dump-tree.
>
> Signed-off-by: Lu Fengqi
Then there's no user of $BTRFS_DEBUG_TREE_PROG, I think we could remove
the
On Fri, Jun 08, 2018 at 02:17:23PM +0800, Qu Wenruo wrote:
> This is a long existing bug (from 2012) but exposed by a reporter
> recently, that when compressed extent without data csum get written to
> device-replace target device, the written data is in fact uncompressed data
> other than the
On Wed, Jun 13, 2018 at 03:06:45PM +0900, Misono Tomohiro wrote:
> Add btrfs test that checks "rmdir" or "rm -r" command can delete a
> subvolume like an ordinary directory.
>
> This behavior has been restricted long time but becomes allowed by
> following commit in the kernel:
> btrfs: Allow
On Mon, Jun 11, 2018 at 07:24:35PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that if we create a new hard link for a file which was previously
> fsync'ed, fsync a parent directory of the new hard link and power fail,
> the parent directory exists after mounting the
On Fri, Jun 01, 2018 at 09:34:48AM +0800, Qu Wenruo wrote:
> This is a long existing bug (from 2012) but exposed by a reporter
> recently, that when compressed extent without data csum get written to
> device-replace target device, the written data is in fact uncompressed data
> other than the
On Mon, May 28, 2018 at 05:51:45PM +0800, Anand Jain wrote:
> Create a seed device and add the sprout device to it.
>
> Signed-off-by: Anand Jain
This series looks fine to me from fstests' point of view, there're just
some really minor common issues.
But I'd like some reviews from other btrfs
On Fri, May 18, 2018 at 07:37:07AM -0700, Darrick J. Wong wrote:
> On Wed, May 16, 2018 at 01:38:49PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Swap files cannot have holes, and they must at least two pages.
> > swapon(8) and mkswap(8) have stricter
On Wed, May 16, 2018 at 01:38:47PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Similar to generic/356 that makes sure we can't reflink an active
^^^ dedupe
I'll fix it on commit.
Thanks,
Eryu
--
To unsubscribe from
On Wed, May 16, 2018 at 01:38:46PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Commit 8c96cfbfe530 ("generic/35[67]: disable swapfile tests on Btrfs")
> disabled the swapfile tests on Btrfs because it did not support
> swapfiles at the time. Now that we're adding
On Tue, May 15, 2018 at 07:14:02PM -0700, Omar Sandoval wrote:
> On Wed, May 16, 2018 at 09:48:58AM +0800, Eryu Guan wrote:
> > On Wed, May 09, 2018 at 11:21:55PM -0700, Omar Sandoval wrote:
> > > From: Omar Sandoval <osan...@fb.com>
> > >
> > > Btrfs
On Wed, May 09, 2018 at 11:21:55PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Btrfs has a bug where we can prematurely ENOSPC if we have lots of
> orphaned files, i.e., deleted files which are still open. Add a test
> which repeatedly creates and deletes a file while
On Mon, Apr 30, 2018 at 04:43:18PM -0500, Eric Sandeen wrote:
> This tests the online label ioctl that btrfs has, which has been
> recently proposed for XFS.
>
> To run, it requires an updated xfs_io with the label command and a
> filesystem that supports it
>
> A slight change here to
On Fri, Apr 27, 2018 at 06:26:35PM +0200, David Sterba wrote:
> On Fri, Apr 27, 2018 at 05:02:45PM +0900, Misono Tomohiro wrote:
> > Add btrfs test that checks "rmdir" or "rm -r" command can delete a
> > subvolume like an ordinary drectory.
> >
> > This behavior has been restricted long time but
On Fri, Apr 27, 2018 at 05:02:45PM +0900, Misono Tomohiro wrote:
> Add btrfs test that checks "rmdir" or "rm -r" command can delete a
> subvolume like an ordinary drectory.
>
> This behavior has been restricted long time but becomes allowed by
> following patch in the kernel:
> btrfs: Allow
On Thu, Apr 19, 2018 at 04:23:35PM +0900, Misono Tomohiro wrote:
> Add btrfs test that checks "rmdir" or "rm -r" command can delete a
> subvolume like an ordinary drectory.
>
> This behavior has been restricted long time but becomes allowed by
> following patch in the kernel:
> btrfs: Allow
[adding linux-btrfs list to cc]
On Tue, Apr 17, 2018 at 04:44:42PM -0700, Howard McLauchlan wrote:
> This test aims to verify correct behaviour with chattr operations and
> btrfs send/receive. The intent is to check general correctness as well
> as special interactions with troublesome
On Mon, Apr 16, 2018 at 12:28:59PM +0100, Filipe Manana wrote:
> On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan <guane...@gmail.com> wrote:
> > On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote:
> >> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan <guane...@gmail.com>
On Sat, Apr 14, 2018 at 06:43:49AM +0800, Anand Jain wrote:
>
> > > +# Test if the superblock corruption is handled correctly:
> > > +#- Test fsid miss-match (csum ok) between primary and copy
> > > superblock
> > > +#Fixed by the ML patch:
> > > +#btrfs: check if the
On Mon, Apr 09, 2018 at 01:28:30PM +0800, Anand Jain wrote:
> Verify if the superblock corruption is handled correctly.
>
> Signed-off-by: Anand Jain
> ---
> v2->v3:
> Provide the disk to be corrupted as an arg, instead of swapping the devices,
> so drop
On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote:
> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan <guane...@gmail.com> wrote:
> > On Wed, Mar 28, 2018 at 12:55:30PM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana <fdman...@suse.com>
> >>
&
On Wed, Mar 28, 2018 at 12:55:30PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that when we have the no-holes mode enabled and a specific metadata
> layout, if we punch a hole and fsync the file, at replay time the whole
> hole was preserved.
>
> This
On Thu, Apr 05, 2018 at 02:28:49PM +0800, Anand Jain wrote:
> Verify if the superblock corruption is handled correctly.
>
> Signed-off-by: Anand Jain
> ---
> v1->v2:
> $subject slightly changed
> Added more info about the test-case
> Keep the stuff from the ./new btrfs
On Thu, Apr 05, 2018 at 10:56:14PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that fsync operations preserve extents allocated with fallocate(2)
> that are placed beyond a file's size.
>
> This test is motivated by a bug found in btrfs where unwritten
On Thu, Mar 29, 2018 at 06:28:48PM +0800, Anand Jain wrote:
> Verify if the superblock corruption is handled correctly.
>
> Signed-off-by: Anand Jain
> ---
> tests/btrfs/159 | 142
>
> tests/btrfs/159.out | 35
On Wed, Mar 28, 2018 at 09:48:17AM +0100, Filipe Manana wrote:
> On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan <guane...@gmail.com> wrote:
> > On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana <fdman...@suse.com>
&g
On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that when we have the no-holes mode enabled and a specific metadata
> layout, if we punch a hole and fsync the file, at replay time the whole
> hole was preserved.
>
> This
On Wed, Mar 21, 2018 at 02:22:29PM +0200, Amir Goldstein wrote:
> > +
> > +_log_writes_mount
> > +$FSSTRESS_PROG $fsstress_args > /dev/null 2>&1
>
> You should run fsstress with run_check() so output will go to $seqres.full
> this way if you are able to catch a bug, you can take the random seed
>
On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote:
> Basic test case which triggers fsstress with dm-log-writes, and then
> check the fs after each FUA writes.
> With needed infrastructure and special handlers for journal based fs.
>
> Signed-off-by: Qu Wenruo
> ---
> In
On Fri, Mar 16, 2018 at 01:17:07PM +0800, Qu Wenruo wrote:
>
>
> On 2018年03月16日 12:01, Eryu Guan wrote:
> > On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote:
> >> Basic test case which triggers fsstress with dm-log-writes, and then
> >> c
On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote:
> Basic test case which triggers fsstress with dm-log-writes, and then
> check the fs after each FUA writes.
> With needed infrastructure and special handlers for journal based fs.
It's not clear to me why the existing infrastructure is
On Sat, Mar 10, 2018 at 04:56:04PM -0700, Liu Bo wrote:
> The regression is introduced to btrfs in linux v4.4 and it refuses to create
> new files after log replay by returning -EEXIST.
>
> Although the problem is on btrfs only, there is no btrfs stuff in terms of
> test, so this makes it
On Thu, Mar 08, 2018 at 01:56:45PM +0800, Lu Fengqi wrote:
> In the case of compression, each 128K input data chunk will be compressed
> to 4K (because of the characters written are duplicate). Therefore we have
> to write (128K * 16) to make sure every stripe can be hit.
>
> Signed-off-by: Lu
On Tue, Mar 06, 2018 at 03:02:31PM +0800, Lu Fengqi wrote:
> Because of commit e76e13ce8c0b ("fsstress: implement the
> clonerange/deduperange ioctls"), dedupe makes the number of references to
> the same extent item increase so much that the default 4K buffer of
> logical-resolve is no longer
On Mon, Jan 15, 2018 at 11:10:20PM -0800, Liu Bo wrote:
> On Mon, Jan 15, 2018 at 02:22:28PM +0800, Eryu Guan wrote:
> > On Fri, Jan 12, 2018 at 06:04:59PM -0700, Liu Bo wrote:
> > > One of btrfs tests, btrfs/011, uses SCRATCH_DEV_POOL and puts a
> > > non-SCRATCH_DE
On Fri, Jan 12, 2018 at 06:04:59PM -0700, Liu Bo wrote:
> One of btrfs tests, btrfs/011, uses SCRATCH_DEV_POOL and puts a
> non-SCRATCH_DEV
> device as the first one when doing mkfs, and this makes
> _require_scratch{_nocheck} fail to umount $SCRATCH_MNT since it checks mount
> point with
On Thu, Jan 11, 2018 at 02:55:57PM +0800, Qu Wenruo wrote:
> Some test cases (AFAIK, btrfs RAID recovery test cases) read out certain
> location to verify its data.
>
> Such read is mostly OK, but the golden output contains the on-disk
> offset, which can differ due to underlying chunk change.
>
On Mon, Jan 08, 2018 at 10:43:30AM +0200, Nikolay Borisov wrote:
> This test has been failing for btrfs for quite some time,
> at least since 4.7. There are 2 implementation details of btrfs that
> it exposes:
>
> 1. Currently btrfs filesystem under 100mb are created in Mixed block
> group mode.
On Tue, Jan 02, 2018 at 01:35:00PM -0700, Liu Bo wrote:
> This is to reproduce a bug of scrub, with which scrub is unable to
> repair raid6 corruption as expected.
>
> The kernel side fixes are
> Btrfs: make raid6 rebuild retry more
> Btrfs: fix scrub to repair raid6 corruption
>
>
On Thu, Dec 07, 2017 at 08:43:43AM +0800, Qu Wenruo wrote:
> Ping.
>
> Any comment on this?
It's been pushed out to upstream, see commit 88231c0c0b9d
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
On Mon, Dec 04, 2017 at 03:33:23PM -0700, Liu Bo wrote:
> This test case is to reproduce a bug of raid6 reconstruction process.
>
> The kernel fix are
> Btrfs: do not merge rbios if their fail stripe index are not identical
> Btrfs: make raid6 rebuild retry more
>
> Signed-off-by: Liu Bo
On Wed, Dec 06, 2017 at 12:15:45PM +0530, Harish wrote:
> On platforms with a page size greater than 4Kb, at the moment btrfs
> doesn't support a node/leaf size smaller than the page size, but it
> supports a larger one. So use the max supported node size (64Kb) so
> that the test runs on any
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
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
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
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
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/顾 金香 <g...@cn.fujitsu.com>
> >
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
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:
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:
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
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
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
On Fri, Sep 01, 2017 at 10:14:41AM +0300, Amir Goldstein wrote:
> On Fri, Sep 1, 2017 at 10:04 AM, Eryu Guan <eg...@redhat.com> wrote:
> > On Fri, Sep 01, 2017 at 02:39:44PM +0900, Misono, Tomohiro wrote:
> >> Several tests uses both _filter_test_dir and _filter_scratch
&
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
> >
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
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
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
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
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: Nikolay
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
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
>
>
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
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)
>
>
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 <osan...@fb.com>
> > >
> > > This is
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
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
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
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 ge
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
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
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
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
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,
> >>
ms that don't support it.
>
> Suggested-by: Eryu Guan <eg...@redhat.com>
> Signed-off-by: Filipe Manana <fdman...@suse.com>
> ---
> common/rc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/rc b/common/rc
> index e1ab2c6..3d0
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 u
1 - 100 of 414 matches
Mail list logo