On Mon, Sep 23, 2013 at 07:19:06PM +0200, David Sterba wrote: > On Mon, Sep 23, 2013 at 07:43:44AM +0700, Tomasz Chmielewski wrote: > > 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. > > Yes this is interesting of course. > > > > [1878432.675210] btrfs-qgroup-re: page allocation failure: order:5, > > mode:0x104050 > > Order 5 allocation, not guaranteed to succeed. > > > [1878432.675319] CPU: 5 PID: 22251 Comm: btrfs-qgroup-re Not tainted > > 3.11.0-rc7 #2 > > [1878432.676204] [<ffffffff810bde12>] krealloc+0x52/0x8c > > [1878432.676324] [<ffffffffa036bcf0>] find_parent_nodes+0x49c/0x5a5 [btrfs] > > [1878432.676383] [<ffffffffa036be75>] btrfs_find_all_roots+0x7c/0xd7 > > [btrfs] > > [1878432.676441] [<ffffffffa036d6e1>] ? > > qgroup_account_ref_step1+0xea/0x102 [btrfs] > > [1878432.676542] [<ffffffffa036d915>] > > btrfs_qgroup_rescan_worker+0x21c/0x516 [btrfs] > > 220 new_nodes = krealloc(old, sizeof(*new_nodes) * > new_alloced, > 221 gfp_mask); > 222 if (!new_nodes) > 223 return -ENOMEM; > > The requested size is between 64k and 128k, with 40 bytes of ulist_node > it's 1638 to 3276 elements. So, lots of things going on during the > rescan, quite expectable. > > I don't know if krealloc can be replaced with something more friendly to > allocator, eg. a list of page-sized blocks instead of one contiguous > array. >
I've done that with a patch in bugzilla, hopefully that will fix it. I've not had time to try and reproduce myself, but I assume if you do something like create a random file, then create 100000 snapshots and then defrag it will probably hit the same problem. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
