similar to: snapshot merging?

I converted an ext4 filesystem with btrfs-convert, mounted it, and wanted to do "lzop -d ...". The result was an immediate Oops (btrfs is on LVM, on dm-crypt, on /dev/sdb which is USB-connected). mini-904.img.lzo dentry_open failed BUG: unable to handle kernel paging request at ffffffcd IP: [<c01b5f36>] fput+0x6/0x30 *pde = 00575067 *pte = 00000000 Oops: 0002 [#1] SMP last sysfs

I''m trying to use this feature of qgroup: btrfs qgroup assign <srcid> <destid> <path> Assigns the lower level qgroup src to the higher level qgroup dest in the btrfs found in <path>. It is used to build qgroup hierarchies. However, I fail to understand how this feature should work, and I''m getting "ERROR: bad relation requested":

Hello folks, I reported a bug here: https://bugzilla.kernel.org/show_bug.cgi?id=63071 but I am not sure if that was the right thing to do. This is producing OOM issues and leading to system crashes (including eventual panics) with such alarming frequency that I wonder if perhaps there is something different about my setup than others. In a nutshell, I originally made the mistake of storing a

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

Not sure if it''s anything interesting - I had the following entry in dmesg a few days ago, on a server with 32 GB RAM. The system is still working fine. [1878432.675210] btrfs-qgroup-re: page allocation failure: order:5, mode:0x104050 [1878432.675319] CPU: 5 PID: 22251 Comm: btrfs-qgroup-re Not tainted 3.11.0-rc7 #2 [1878432.675417] Hardware name: System manufacturer System Product

On Mon 23-04-18 10:06:08, Mikulas Patocka wrote: > > > On Sat, 21 Apr 2018, Matthew Wilcox wrote: > > > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:

On Mon 23-04-18 10:06:08, Mikulas Patocka wrote: > > > On Sat, 21 Apr 2018, Matthew Wilcox wrote: > > > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:

On Wed, 18 Apr 2018, David Miller wrote: > From: Mikulas Patocka <mpatocka at redhat.com> > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT) > > > The structure net_device is followed by arbitrary driver-specific data > > (accessible with the function netdev_priv). And for virtio-net, these > > driver-specific data must be in DMA memory. > > And we are saying

On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > No way. This is just wrong! First of all, you will explode most likely > > > > on many allocations of small sizes. Second,

On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > No way. This is just wrong! First of all, you will explode most likely > > > > on many allocations of small sizes. Second,

On Tue 24-04-18 11:30:40, Mikulas Patocka wrote: > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > > > Fixing __vmalloc code > > > is easy and it doesn't require cooperation with maintainers. > > > > But it is a hack against the intention of the scope api. > > It is not!

On Tue 24-04-18 11:30:40, Mikulas Patocka wrote: > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > > > Fixing __vmalloc code > > > is easy and it doesn't require cooperation with maintainers. > > > > But it is a hack against the intention of the scope api. > > It is not!

I''ve enabled "extended inode refs" and "skinny metadata extent refs" with btrfstune. Then, I''ve tried running "btrfs filesystem balance" - unfortunately it segfaulted. (not sure if I should run balance operation after using btrfstune with -r and -x)? This is with 3.10 kernel with "Btrfs: make backref walking code handle skinny metadata"

On Wed, 18 Apr 2018, Eric Dumazet wrote: > > > On 04/18/2018 07:34 AM, Mikulas Patocka wrote: > > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > > fails (later patches change it to kvzalloc). > > > > The problem with this is that if the vzalloc function is actually used, > > virtio_net doesn't work (because it expects

On Wed, 18 Apr 2018, Eric Dumazet wrote: > > > On 04/18/2018 07:34 AM, Mikulas Patocka wrote: > > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > > fails (later patches change it to kvzalloc). > > > > The problem with this is that if the vzalloc function is actually used, > > virtio_net doesn't work (because it expects

On 04/25/2018 01:02 PM, Mikulas Patocka wrote: > > > From: Mikulas Patocka <mpatocka at redhat.com> > Subject: [PATCH v4] fault-injection: introduce kvmalloc fallback options > > This patch introduces a fault-injection option "kvmalloc_fallback". This > option makes kvmalloc randomly fall back to vmalloc. > > Unfortunatelly, some kernel code has bugs

On 04/25/2018 01:02 PM, Mikulas Patocka wrote: > > > From: Mikulas Patocka <mpatocka at redhat.com> > Subject: [PATCH v4] fault-injection: introduce kvmalloc fallback options > > This patch introduces a fault-injection option "kvmalloc_fallback". This > option makes kvmalloc randomly fall back to vmalloc. > > Unfortunatelly, some kernel code has bugs

On Tue 24-04-18 13:00:11, Mikulas Patocka wrote: > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > On Tue 24-04-18 11:50:30, Mikulas Patocka wrote: > > > > > > > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > > > > > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > > > > [...] > > > > > @@

On Tue 24-04-18 13:00:11, Mikulas Patocka wrote: > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > On Tue 24-04-18 11:50:30, Mikulas Patocka wrote: > > > > > > > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > > > > > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > > > > [...] > > > > > @@

On Tue, Apr 24, 2018 at 08:29:14AM -0400, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Matthew Wilcox wrote: > > > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > > Some bugs (such as buffer overflows) are better detected > > > with kmalloc code, so we must test the kmalloc path too. > > > > Well now, this brings up