misc/021-image-multi-devices fails on latest btrfs-devel/misc-next

Hi. Few days back(Nov14th) this(misc/021-image-multi-devices) test script used to pass and seems like its failing now. may be due to recent commits? Logs,screen-casts available here: https://lakshmipathi.github.io/btrfsqa/ Cheers, Lakshmipathi.G http://www.giis.co.in http://www.webminal.org

Re: [PATCH 2/4] btrfs: make open_ctree error injectable

* Josef Bacik wrote: > From: Josef Bacik > > This allows us to do error injection with BPF for open_ctree. > > Signed-off-by: Josef Bacik > --- > fs/btrfs/disk-io.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

Re: Unrecoverable scrub errors

On Fri, Nov 17, 2017 at 08:19:11PM -0700, Chris Murphy wrote: > On Fri, Nov 17, 2017 at 8:41 AM, Nazar Mokrynskyi > wrote: > > >> [551049.038718] BTRFS warning (device dm-2): checksum error at logical > >> 470069460992 on dev > >>

Re: Unrecoverable scrub errors

On Fri, Nov 17, 2017 at 8:41 AM, Nazar Mokrynskyi wrote: >> [551049.038718] BTRFS warning (device dm-2): checksum error at logical >> 470069460992 on dev >> /dev/mapper/luks-bd5dd3e7-ad80-405f-8dfd-752f2b870f93-part1, sector >> 942238048: metadata leaf (level 0) in tree

Re: 4.14 balance: kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!

On 2017-11-18 10:08, Hans van Kranenburg wrote: On 11/18/2017 01:49 AM, Tomasz Chmielewski wrote: I'm getting the following BUG when running balance on one of my systems: [ 3458.698704] BTRFS info (device sdb3): relocating block group 306045779968 flags data|raid1 [ 3466.892933] BTRFS info

Re: 4.14 balance: kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!

On 11/18/2017 01:49 AM, Tomasz Chmielewski wrote: > I'm getting the following BUG when running balance on one of my systems: > > > [ 3458.698704] BTRFS info (device sdb3): relocating block group > 306045779968 flags data|raid1 > [ 3466.892933] BTRFS info (device sdb3): found 2405 extents > [

4.14 balance: kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!

I'm getting the following BUG when running balance on one of my systems: [ 3458.698704] BTRFS info (device sdb3): relocating block group 306045779968 flags data|raid1 [ 3466.892933] BTRFS info (device sdb3): found 2405 extents [ 3495.408630] BTRFS info (device sdb3): found 2405 extents [

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

On 2017年11月17日 23:50, Marc MERLIN wrote: > On Fri, Nov 17, 2017 at 04:12:07PM +0800, Qu Wenruo wrote: >> >> >> On 2017年11月17日 15:30, Marc MERLIN wrote: >>> Here's the whole output: >>> gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647 >> >> Sorry, I missed "-C10"

Re: [RFC PATCH 0/8] btrfs iomap support

On 11/17/2017 12:45 PM, Nikolay Borisov wrote: > > > On 17.11.2017 19:44, Goldwyn Rodrigues wrote: >> This patch series attempts to use kernels iomap for btrfs. Currently, >> it covers buffered writes only, but I intend to add some other iomap >> uses once this gets through. I am sending this

[PATCH 3/8] fs: btrfs: remove unused hardirq.h

Preempt counter APIs have been split out, currently, hardirq.h just includes irq_enter/exit APIs which are not used by btrfs at all. So, remove the unused hardirq.h. Signed-off-by: Yang Shi Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba

Re: [PATCH v2] iomap: report collisions between directio and buffered writes to userspace

On Fri, Nov 17, 2017 at 11:39:25AM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong > > If two programs simultaneously try to write to the same part of a file > via direct IO and buffered IO, there's a chance that the post-diowrite > pagecache invalidation will fail

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

Am Fri, 17 Nov 2017 06:51:52 +0300 schrieb Andrei Borzenkov : > 16.11.2017 19:13, Kai Krakow пишет: > ... > > > BTW: From user API perspective, btrfs snapshots do not guarantee > > perfect granular consistent backups. > > Is it documented somewhere? I was relying on

Re: Btrfs progs pre-release 4.14-rc1

> On Nov 17, 2017, at 8:48 AM, Uli Heller wrote: > > I tried to compile these on ubuntu-14.04 running 4.4.0-98-generic > - I had to install libzstd-dev > - I had to disable the zstd tests > > Do you think this ends up in a working binary? Or am I doing something

WARN_ON in __writeback_inodes_sb_nr

I see a backtrace booting 4.14+ on a mellanox switch. The trace is due to the WARN_ON in __writeback_inodes_sb_nr. [ 40.958590] WARNING: CPU: 0 PID: 183 at /home/dsa/kernel-2.git/fs/fs-writeback.c:2339 __writeback_inodes_sb_nr+0x8a/0x90 [ 40.958593] Modules linked in: ebtable_filter ebtables

[PATCH] btrfs: clear space cache inode generation always

From: Josef Bacik We discovered a box that had double allocations, and suspected the space cache may be to blame. While auditing the write out path I noticed that if we've already setup the space cache we will just carry on. This means that any error we hit after

[PATCH v2] iomap: report collisions between directio and buffered writes to userspace

From: Darrick J. Wong If two programs simultaneously try to write to the same part of a file via direct IO and buffered IO, there's a chance that the post-diowrite pagecache invalidation will fail on the dirty page. When this happens, the dio write succeeded, which

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On Nov 15, 2017, at 7:18 PM, Qu Wenruo wrote: > > [Background] > Recently I'm considering the possibility to use checksum from filesystem > to enhance device-mapper raid. > > The idea behind it is quite simple, since most modern filesystems have > checksum for their

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On 11/17/17 18:48, Marc MERLIN wrote: > On Thu, Nov 16, 2017 at 09:53:15PM -0800, Marc MERLIN wrote: >>> I suggest that you try lvmcache instead. It's much more flexible than >>> bcache, >>> does pretty much the same job, and has much less of the "hacky" feel to it. >> >> I can read up on it,

Re: [RFC PATCH 0/8] btrfs iomap support

On 17.11.2017 19:44, Goldwyn Rodrigues wrote: > This patch series attempts to use kernels iomap for btrfs. Currently, > it covers buffered writes only, but I intend to add some other iomap > uses once this gets through. I am sending this as an RFC because I > would like to find ways to improve

[PATCH 3/4] bpf: add a bpf_override_function helper

From: Josef Bacik Error injection is sloppy and very ad-hoc. BPF could fill this niche perfectly with it's kprobe functionality. We could make sure errors are only triggered in specific call chains that we care about with very specific situations. Accomplish this with the

[PATCH 2/4] btrfs: make open_ctree error injectable

From: Josef Bacik This allows us to do error injection with BPF for open_ctree. Signed-off-by: Josef Bacik --- fs/btrfs/disk-io.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index dfdab849037b..c6b4e1f07072 100644

[PATCH 1/4] add infrastructure for tagging functions as error injectable

From: Josef Bacik Using BPF we can override kprob'ed functions and return arbitrary values. Obviously this can be a bit unsafe, so make this feature opt-in for functions. Simply tag a function with KPROBE_ERROR_INJECT_SYMBOL in order to give BPF access to that function for error

[PATCH 4/4] samples/bpf: add a test for bpf_override_return

From: Josef Bacik This adds a basic test for bpf_override_return to verify it works. We override the main function for mounting a btrfs fs so it'll return -ENOMEM and then make sure that trying to mount a btrfs fs will fail. Acked-by: Alexei Starovoitov

[PATCH 0/4][v6] Add the ability to do BPF directed error injection

I've reworked this to be opt-in only as per Igno and Alexei. Still needs to go through Dave because of the bpf bits, but I need tracing guys to weigh in and sign off on my approach please. v5->v6: - add BPF_ALLOW_ERROR_INJECTION() tagging for functions that will support this feature. This way

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On Thu, Nov 16, 2017 at 09:53:15PM -0800, Marc MERLIN wrote: > > I suggest that you try lvmcache instead. It's much more flexible than > > bcache, > > does pretty much the same job, and has much less of the "hacky" feel to it. > > I can read up on it, it's going to be a big pain to convert from

[RFC PATCH 1/8] btrfs: use iocb for __btrfs_buffered_write

From: Goldwyn Rodrigues Preparatory patch. It reduces the arguments to __btrfs_buffered_write to follow buffered_write() style. Signed-off-by: Goldwyn Rodrigues --- fs/btrfs/file.c | 24 1 file changed, 12 insertions(+), 12

[RFC PATCH 7/8] fs: iomap->prepare_pages() to set directives specific for the page

From: Goldwyn Rodrigues This adds prepare_pages() to iomap in order to set page directives for the page so as FS such as btrfs may perform post-write operations after write completes. Can we do away with this? EXTENT_PAGE_PRIVATE is only set and not used. However, we want the

[RFC PATCH 7/8] fs: iomap->prepare_pages() to set directives specific for the page

From: Goldwyn Rodrigues This adds prepare_pages() to iomap in order to set page directives for the page so as FS such as btrfs may perform post-write operations after write completes. Can we do away with this? EXTENT_PAGE_PRIVATE is only set and not used. However, we want the

[RFC PATCH 8/8] iomap: Introduce iomap->dirty_page()

From: Goldwyn Rodrigues In dirty_page(), we are clearing PageChecked, though I don't see it set. Is this used for compression only? Can we call __set_page_dirty_nobuffers instead? Signed-off-by: Goldwyn Rodrigues --- fs/btrfs/file.c | 8

[RFC PATCH 3/8] fs: Introduce IOMAP_F_NOBH

From: Goldwyn Rodrigues IOMAP_F_NOBH tells iomap functions not to use or attach buffer heads to the page. Page flush and writeback is the responsibility of the filesystem (such as btrfs) code, which use bio to perform it. Signed-off-by: Goldwyn Rodrigues

[RFC PATCH 5/8] btrfs: use iomap to perform buffered writes

From: Goldwyn Rodrigues This eliminates all page related code. Signed-off-by: Goldwyn Rodrigues --- fs/btrfs/btrfs_inode.h | 4 +- fs/btrfs/file.c| 488 ++--- 2 files changed, 185 insertions(+), 307

[RFC PATCH 6/8] btrfs: read the first/last page of the write

From: Goldwyn Rodrigues We cannot perform a readpage in iomap_apply after iomap_begin() because we have our extents locked. So, we perform a readpage and make sure we unlock it, but increase the page count. Question: How do we deal with -EAGAIN return from

[RFC PATCH 8/8] fs: Introduce iomap->dirty_page()

From: Goldwyn Rodrigues In dirty_page(), we are clearing PageChecked, though I don't see it set. Is this used for compression only? Can we call __set_page_dirty_nobuffers instead? Signed-off-by: Goldwyn Rodrigues --- fs/btrfs/file.c | 8

[RFC PATCH 4/8] btrfs: Introduce btrfs_iomap

From: Goldwyn Rodrigues Preparatory patch. btrfs_iomap structure carries extent/page state from iomap_begin() to iomap_end(). Signed-off-by: Goldwyn Rodrigues --- fs/btrfs/file.c | 68 ++--

[RFC PATCH 2/8] fs: Add inode_extend_page()

From: Goldwyn Rodrigues This splits the generic_write_end() into functions which handle block_write_end() and iomap_extend_page(). iomap_extend_page() performs the functions of increasing i_size (if required) and extending pagecache. Performed this split so we don't use

[RFC PATCH 0/8] btrfs iomap support

This patch series attempts to use kernels iomap for btrfs. Currently, it covers buffered writes only, but I intend to add some other iomap uses once this gets through. I am sending this as an RFC because I would like to find ways to improve the solution since some changes require adding more

Re: Btrfs progs pre-release 4.14-rc1

I tried to compile these on ubuntu-14.04 running 4.4.0-98-generic - I had to install libzstd-dev - I had to disable the zstd tests Do you think this ends up in a working binary? Or am I doing something strange? Best regards, Uli -- Uli Heller -- To unsubscribe from this list: send the line

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

On Fri, Nov 17, 2017 at 04:12:07PM +0800, Qu Wenruo wrote: > > > On 2017年11月17日 15:30, Marc MERLIN wrote: > > Here's the whole output: > > gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647 > > Sorry, I missed "-C10" parameter for grep. generation

Unrecoverable scrub errors

Hi folks, I'm a long-term btrfs user (permanently for my root partition and other stuff for ~3 years now, with compression, most of the way with RAID0 on various SSD, etc). In simple words my setup consists of root partition and backup partition. There are automated snapshots on root

Re: Btrfs restore error

On 2017-11-16 10:38 PM, Qu Wenruo wrote: On 2017年11月17日 11:56, Jay wrote: Hello, I thought I should report something since there was little information on this error. The situation is I have 2 external hard drives on Xubuntu. One is not working and I need to move the data over to the

[PATCH v2] btrfs: handle dynamically reappearing missing device

If the device is not present at the time of (-o degrade) mount, the mount context will create a dummy missing struct btrfs_device. Later this device may reappear after the FS is mounted and then device is included in the device list but it missed the open_device part. So this patch handles that

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017-11-16 20:30, Qu Wenruo wrote: On 2017年11月17日 00:47, Austin S. Hemmelgarn wrote: This is at least less complicated than dm-integrity. Just a new hook for READ bio. And it can start from easy part. Like starting from dm-raid1 and other fs support. It's less complicated for end users

Re: [PATCH] btrfs: handle dynamically reappearing missing device

On 11/17/2017 07:28 AM, Liu Bo wrote: On Sun, Nov 12, 2017 at 06:56:50PM +0800, Anand Jain wrote: If the device is not present at the time of (-o degrade) mount the mount context will create a dummy missing struct btrfs_device. Later this device may reappear after the FS is mounted. This

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

On 2017年11月17日 15:30, Marc MERLIN wrote: > Here's the whole output: > gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647 Sorry, I missed "-C10" parameter for grep. > location key (1919805647 INODE_ITEM 0) type FILE This should be the DIR_ITEM/DIR_INDEX