Re: [PATCH] xfstests: Add message indicating btrfs-progs support FST in read-only mode

2017-10-25 Thread Eryu Guan
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

[PATCH] btrfs: fix offset in test Btrfs delalloc accounting overflow

2017-10-25 Thread robbieko
From: Robbie Ko Found it when test btrfs delalloc accounting overflow, Fix offset error. We will fill in the gaps between the created extents, then outstanding extents will all be merged into 1. Signed-off-by: Robbie Ko --- tests/btrfs/010 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] xfstests: Add message indicating btrfs-progs support FST in read-only mode

2017-10-25 Thread Gu Jinxiang
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. Signed-off-by: Gu JinXiang --- tests/btrfs/012 | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tests/btrfs/01

Re: btrfs send yields "ERROR: send ioctl failed with -5: Input/output error"

2017-10-25 Thread Zak Kohler
I don't need to recover in this case. I can just remake the filesystem. I'm just very concerned that this corruption was able to happen. Here is the entire history of the filesystem: 2017.10.18 create btrfs from 3 drives aka OfflineJ and rsync data from old madam raid5

Re: [PATCH] btrfs: avoid misleading talk about "compression level 0"

2017-10-25 Thread Adam Borowski
On Wed, Oct 25, 2017 at 03:23:11PM +0200, David Sterba wrote: > On Sat, Oct 21, 2017 at 06:49:01PM +0200, Adam Borowski wrote: > > Many compressors do assign a meaning to level 0: either null compression or > > the lowest possible level. This differs from our "unset thus default". > > Thus, let's

Re: [PATCH] btrfs: avoid misleading talk about "compression level 0"

2017-10-25 Thread David Sterba
On Sat, Oct 21, 2017 at 06:49:01PM +0200, Adam Borowski wrote: > Many compressors do assign a meaning to level 0: either null compression or > the lowest possible level. This differs from our "unset thus default". > Thus, let's not unnecessarily confuse users. I agree 'level 0' confusing, however

Re: [PATCH v3] Btrfs: free btrfs_device in place

2017-10-25 Thread David Sterba
On Mon, Oct 23, 2017 at 11:02:54PM -0600, Liu Bo wrote: > It's pointless to defer it to a kthread helper as we're not under a > special context. > > For reference, commit 1f78160ce1b1 ("Btrfs: using rcu lock in the > reader side of devices list") introduced RCU freeing for device > structures. >

Kernel Oops / btrfs problems

2017-10-25 Thread andreas . btrfs
Hi, I've had problems with a btrfs filesystem on a usb disk. I made a successfull backup of all data and created the filesystem from scratch. I'm not able to restore all backuped data because of a kernel oops. The problem is reproducible. I've checked my RAM alreayd with memtest86 for 8h witho

Re: [PATCH] fstests: btrfs/143: make test case more reliable

2017-10-25 Thread Nikolay Borisov
On 23.10.2017 23:57, Liu Bo wrote: > Currently drop_caches is used to invalidate file's page cache so that > buffered read can hit disk, but the problem is that it may also > invalidate metadata's page cache, so the test case may not get read > errors (and repair) if reading metadata has consumed

Re: check: "warning line 4144"

2017-10-25 Thread Qu Wenruo
On 2017年10月25日 14:54, Tom Hale wrote: > > > On 19/10/17 15:58, Qu Wenruo wrote: >> On 2017年10月19日 16:53, Tom Hale wrote: >>> In running btrfs check, I got the following message: >>> >>> warning line 4144 >>> >>> Could this be a little more descriptive? >>> >>> * Does it mean I should rebuil