On Wed, Apr 07, 2021 at 01:13:26PM -0700, Boris Burkov wrote:
> btrfs trims fiemap extents to the inputted offset, which leads to
> inconsistent results for most inputs, and downright bizarre outputs like
> [7..6] when the trimmed extent is at the end of an extent and shorter
> than 512 bytes.
>
>
On Thu, Apr 08, 2021 at 11:57:50AM -0700, Boris Burkov wrote:
> generic/574 has tests for corrupting the merkle tree data stored by the
> filesystem. Since btrfs uses a different scheme for storing this data,
> the existing logic for corrupting it doesn't work out of the box. Adapt
> it to properly
On Thu, Apr 08, 2021 at 11:57:49AM -0700, Boris Burkov wrote:
> There are some btrfs specific fsverity scenarios that don't map
> neatly onto the tests in generic/574 like holes, inline extents,
> and preallocated extents. Cover those in a btrfs specific test.
>
> This test relies on the btrfs imp
On Thu, Mar 18, 2021 at 11:48:15AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We start a process that runs fsstress, then kill the process, wait for it
> to die and then end the test, where we attempt to unmount the fs which
> often fails because the fsstress subcommand started b
On Wed, Mar 10, 2021 at 10:48:35AM +, Filipe Manana wrote:
> On Sun, Mar 7, 2021 at 3:24 PM Eryu Guan wrote:
> >
> > On Sun, Mar 07, 2021 at 03:07:43PM +, Filipe Manana wrote:
> > > On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
> > > >
> > &g
On Mon, Feb 22, 2021 at 06:48:18AM -0800, Anand Jain wrote:
> This test case runs fio for raid1/10/1c3/1c4 profiles and all the
> available read policies in the system. At the end of the test case,
> a comparative summary of the result is in the $seqresfull-file.
>
> LOAD_FACTOR parameter controls
On Sun, Mar 07, 2021 at 03:07:43PM +, Filipe Manana wrote:
> On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
> >
> > On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Test cases where a dire
On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test cases where a direct IO write, with O_DSYNC, can not be done and has
> to fallback to a buffered write.
>
> This is motivated by a regression that was introduced in kernel 5.10 by
> commit 0eb7929
On Wed, Feb 24, 2021 at 05:37:20PM +0800, Chengguang Xu wrote:
> 在 星期三, 2021-02-24 17:22:35 Su Yue 撰写
> >
> > On Wed 24 Feb 2021 at 16:51, Chengguang Xu
> > wrote:
> >
> > > 在 星期三, 2021-02-24 15:52:17 Su Yue 撰写
> > >
> > > >
> > > > Cc to the author and linux
On Tue, Jan 12, 2021 at 01:17:47PM -0800, Boris Burkov wrote:
> I recently changed clear_cache to not appear in mount options, as it has
> one shot semantics, which was breaking this test. Test explicitly that
> it _doesn't_ appear, which properly fails on old filesystems and passes
> on misc-next.
On Thu, Dec 17, 2020 at 11:47:49AM +, Filipe Manana wrote:
> On Tue, Dec 15, 2020 at 4:16 AM ethanwu wrote:
> >
> > This is a regression test for the issue fixed by the kernel commit titled
> > "btrfs: correctly calculate item size used when item key collision happens"
> >
> > In this case, we
On Mon, Dec 07, 2020 at 06:19:00PM +0200, Nikolay Borisov wrote:
> This test verifies btrfs' free objectid management. I.e it ensures that
> the first objectid is always 256 in an fs tree.
>
> Signed-off-by: Nikolay Borisov
Some minor issues below, but I'd like btrfs folks to help review to see
On Mon, Oct 07, 2019 at 05:41:01PM +0800, Anand Jain wrote:
> Test if btrfs.ko sucessfully identifies and reports the missing device,
> if the missed device contians no btrfs magic string.
>
> Signed-off-by: Anand Jain
> ---
> tests/btrfs/197 | 79
> +
On Mon, Oct 07, 2019 at 05:41:00PM +0800, Anand Jain wrote:
> Test if btrfs.ko sucessfully identifies and reports the missing device,
> if the missed device contians someother btrfs.
>
> Signed-off-by: Anand Jain
> ---
> tests/btrfs/196 | 77
> +++
Hi Qu,
On Tue, Oct 01, 2019 at 12:04:19PM +0300, Nikolay Borisov wrote:
> Add basic test to ensure btrfs conversion functionality is tested. This test
> exercies conversion to all possible types of the data portion. This is
> sufficient
> since from the POV of relocation we are only moving blockg
On Wed, Oct 02, 2019 at 02:41:33PM -0400, Josef Bacik wrote:
> I discovered a problem in btrfs where we'd end up pointing at a block we
> hadn't written out yet. This is triggered by a race when two different
> files on two different subvolumes fsync. This test exercises this path
> with dm-log-w
On Thu, Oct 03, 2019 at 12:12:36PM +0100, Filipe Manana wrote:
> On Thu, Oct 3, 2019 at 11:59 AM Filipe Manana wrote:
> >
> > On Wed, Oct 2, 2019 at 7:44 PM Josef Bacik wrote:
> > >
> > > I discovered a problem in btrfs where we'd end up pointing at a block we
> > > hadn't written out yet. This
On Thu, Sep 26, 2019 at 10:26:35AM +0300, Nikolay Borisov wrote:
> This is a regression test for the bug fixed by
> 'btrfs: Fix a regression which we can't convert to SINGLE profile'
>
> Signed-off-by: Nikolay Borisov
> ---
> tests/btrfs/194 | 52 +
On Wed, Sep 18, 2019 at 02:56:26PM +0800, Qu Wenruo wrote:
> [BUG]
> When btrfs/011 is executed on a fast enough system (fully memory backed
> VM, with test device has unsafe cache mode), the test can fail like
> this:
>
> btrfs/011 43s ... [failed, exit status 1]- output mismatch (see
> /home/
On Sun, Sep 15, 2019 at 10:21:14AM +0100, Filipe Manana wrote:
> On Sun, Sep 15, 2019 at 8:32 AM Qu Wenruo wrote:
> >
> > Add a test case where falloc is called on multiple holes with qgroup
> > enabled.
> >
> > This can cause qgroup reserved data space leak and false EDQUOT error
> > even we're n
On Fri, Sep 13, 2019 at 09:51:51AM +0800, Qu Wenruo wrote:
> Add a test case where falloc is called on multiple holes with qgroup
> enabled.
>
> This can cause qgroup reserved data space leak and false EDQUOT error
> even we're not reaching the limit.
>
> The fix is titled:
> "btrfs: qgroup: Fix
On Mon, Aug 26, 2019 at 02:20:45PM +0800, Qu Wenruo wrote:
> We have generic dm-logwrites with fsstress test case (generic/482), but
> it doesn't cover fs specific operations like btrfs snapshot creation and
> deletion.
>
> Furthermore, that test is not heavy enough to bump btrfs tree height by
>
On Mon, Aug 19, 2019 at 04:18:06PM +0800, Qu Wenruo wrote:
> We have generic dm-logwrites with fsstress test case (generic/482), but
> it doesn't cover fs specific operations like btrfs snapshot creation and
> deletion.
>
> Furthermore, that test is not heavy enough to bump btrfs tree height by
>
On Thu, Aug 15, 2019 at 02:26:59PM -0400, Josef Bacik wrote:
> Btrfs does COW, so when we unlink the file we need to update metadata
> and write it to a new location, which we can't do because the thinp is
> full. This results in an EIO during a metadata write, which makes us
> flip read only, thu
On Fri, Aug 16, 2019 at 05:47:33PM +0800, Qu Wenruo wrote:
[...]
> >> +$KILLALL_PROG -q $FSSTRESS_PROG &> /dev/null
> >
> > You're very inconsistent within the same test :) Using both ">
> > /dev/null 2>&1" and "&> /dev/null".
>
> My bad, I mean 2>&1 > /dev/null.
> What I mean is output stderr wh
On Fri, Jul 05, 2019 at 11:09:38AM +0100, Filipe Manana wrote:
> On Fri, Jul 5, 2019 at 8:43 AM Eryu Guan wrote:
> >
> > On Fri, Jun 28, 2019 at 11:08:36PM +0100, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Test that if we clone
On Fri, Jun 28, 2019 at 11:08:36PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that if we clone a file with some large extents into a file that has
> many small extents, when the fs is nearly full, the clone operation does
> not fail and produces the correct result.
>
> This
On Fri, Jun 21, 2019 at 11:48:57AM +0100, Filipe Manana wrote:
> On Fri, Jun 21, 2019 at 11:36 AM Eryu Guan wrote:
> >
> > On Wed, Jun 19, 2019 at 01:06:24PM +0100, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Test as well that hole
On Wed, Jun 19, 2019 at 01:06:24PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test as well that hole punch operations that affect a single file block
> also update the file's mtime and ctime.
>
> This is motivated by a bug a found in btrfs which is fixed by the
> following patch
On Thu, May 23, 2019 at 09:11:01AM +0800, Qu Wenruo wrote:
> There are two regressions related to balance resume:
> - Kernel NULL pointer dereference at mount time
> Introduced in v5.0
> - Kernel BUG_ON() just after mount
> Introduced in v5.1
>
> The kernel fixes are:
> "btrfs: qgroup: Check i
On Wed, May 15, 2019 at 04:02:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Run fsstress, fsync every file and directory, simulate a power failure and
> then verify the all files and directories exist, with the same data and
> metadata they had before the power failure.
>
> Th
On Fri, Apr 26, 2019 at 06:35:42PM +0200, David Sterba wrote:
> On Tue, Apr 02, 2019 at 04:19:46PM +0800, Anand Jain wrote:
> > Some btrfs test cases use btrfs module-reload to unregister devices in
> > the btrfs kernel. The problem with the module-reload approach is, if test
> > system contains bt
On Thu, Apr 25, 2019 at 01:37:09AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The recent commit 4529b20e1aa8f9 ("btrfs/048: amend property validation
> cases"), does not properly filter the scratch device because the error
> messages are sent to stderr and not to stdout, and the
On Sat, Apr 20, 2019 at 02:14:25PM +, Filipe Manana wrote:
> On Mon, Apr 15, 2019 at 9:32 AM wrote:
> >
> > From: Filipe Manana
> >
> > Stress send running in parallel with deduplication against files that
> > belong to the snapshots used by send. The goal is to hit assertion failures
> > and
On Thu, Apr 04, 2019 at 05:30:18PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Currently fsstress does not exercise creating, reading or deleting xattrs
> on files or directories. This change adds support for setting xattrs on
> files and directories, using only the xattr user nam
On Sun, Apr 07, 2019 at 03:45:36PM +0300, Nikolay Borisov wrote:
>
>
> On 7.04.19 г. 14:54 ч., Anand Jain wrote:
> > On 6/4/19 8:02 pm, Eryu Guan wrote:
> >> On Fri, Apr 05, 2019 at 04:21:10PM +0300, Nikolay Borisov wrote:
> >>>
> >>>
> >&
On Thu, Mar 28, 2019 at 01:35:07PM +0800, Qu Wenruo wrote:
> For kernel operation we have METADATA/FUA/FLUSH flags as a beacon, but
> for user space write we don't have any useful flag unless the user space
> tool call fsync() to generate a FLUSH bio.
>
> This means for user space write, we don't
On Fri, Apr 05, 2019 at 04:21:10PM +0300, Nikolay Borisov wrote:
>
>
> On 3.04.19 г. 20:04 ч., Anand Jain wrote:
> > Add more property validation cases which are fixed by the patches [1]
> > [1]
> > btrfs: fix vanished compression property after failed set
> > btrfs: fix zstd compression par
On Tue, Apr 02, 2019 at 01:58:23PM +0800, Anand Jain wrote:
>
> Eryu,
>
> This patch isn't integrated yet.
Sorry for missing that, and thanks for reminding! I've applied the
patch. Thanks!
Eryu
On Tue, Mar 19, 2019 at 12:58:51PM +0200, Nikolay Borisov wrote:
> For a long time this test has been failing on all kinds of VM configuration,
> which are using virtio_blk devices. This is due to the fact that scsi
> devices are deletable and virtio_blk are not. However, this only prevents
> devic
On Tue, Mar 19, 2019 at 01:04:04PM +0200, Nikolay Borisov wrote:
> When a device is deleted/removed from a btrfs filesystem the kernel
> ensures all superblocks on said device are zeroed out. Test for this
> behavior. Since btrfs inspect-internal dump-super always return success
> I cannot test for
On Tue, Mar 19, 2019 at 05:49:40PM +0800, Anand Jain wrote:
> btrfs module reload was introduced to unregister devices in the btrfs
> kernel module.
>
> The problem with the module reload approach is that you can't run btrfs
> test cases 124, 125, 154 and 164 on the system with btrfs as root fs.
>
On Fri, Feb 08, 2019 at 01:44:04PM +0200, Nikolay Borisov wrote:
> Add support for btrfs in shared/298. Achieve this by introducing 2
> new awk scripts that parse relevant btrfs structures and print holes.
> Additionally modify the test to create larger - 3gb filesystem in the
> case of btrfs. This
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: https://www.spinics.net/lists/linux-btrfs/msg834
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 c
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 insertion(+)
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 c
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 op
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 deduplication of an ent
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 mot
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 expose
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 writt
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 defini
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 orig
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 rm
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 filesyst
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 orig
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 f
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 restrictions, so add versions
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 this list: send t
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 support, we want these
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
> > >
> > > Btrfs has a bug where we can p
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 keeping all of the
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 _require_x
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 b
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 rmdi
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 rmdi
[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 flags(immut
On Mon, Apr 16, 2018 at 12:28:59PM +0100, Filipe Manana wrote:
> On Mon, Apr 9, 2018 at 2:05 PM, Eryu Guan 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 wrote:
> >> > On Wed, Mar 28, 2
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 fsid
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 mount_opt_minus_args().
> 159.out slig
On Sun, Apr 08, 2018 at 09:46:24AM +0100, Filipe Manana wrote:
> On Sun, Apr 8, 2018 at 8:46 AM, Eryu Guan wrote:
> > 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
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 issue is fixed by the f
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
> Add mount_opt_minus_a
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 extents
> beyond the i
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 +
> tests/btrf
On Thu, Mar 29, 2018 at 02:45:26PM +0100, Filipe Manana wrote:
> On Wed, Mar 28, 2018 at 11:33 AM, Eryu Guan wrote:
> > On Wed, Mar 28, 2018 at 09:48:17AM +0100, Filipe Manana wrote:
> >> On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
> >> > On Mon, Mar 26, 2
On Wed, Mar 28, 2018 at 09:48:17AM +0100, Filipe Manana wrote:
> On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
> > 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
On Wed, Mar 28, 2018 at 01:51:44PM +0800, Qu Wenruo wrote:
>
>
> On 2018年03月28日 13:04, Amir Goldstein wrote:
> > On Wed, Mar 28, 2018 at 7:40 AM, Qu Wenruo wrote:
> >> Basic test case which triggers fsstress with dm-log-writes, and then
> >> check the fs after each FUA writes.
> >> With needed i
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 issue is fixed by the f
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 my test, xfs and
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
> >> check the fs
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 no
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 generic.
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 Fen
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 suff
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 SCRATCH_
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. F
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
>
> Signed-off
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
Test f
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 platf
1 - 100 of 471 matches
Mail list logo
