Re: [PATCH 00/39] drop null test before destroy functions

> Recent commits to kernel/git/torvalds/linux.git have made the following > functions able to tolerate NULL arguments: > > kmem_cache_destroy (commit 3942d29918522) > mempool_destroy (commit 4e3ca3e033d1) > dma_pool_destroy (commit 44d7175da6ea) How do you think about to extend an other SmPL

Re: [PATCH] Btrfs: fix read corruption of compressed and shared extents

On Mon, Sep 14, 2015 at 05:34:02PM +0800, Qu Wenruo wrote: > >>And in your case: > >>(With a little modification, decompressed length is 32K now) > >> File layout > >> [0 - 8K] [8K - 24K] > >> | | > >> |

Re: [PATCH v3 0/9] Btrfs: free space B-tree

On 09/14/15 08:04, Omar Sandoval wrote: > I went back and fixed the issues that came up since v2. Changes below. I > removed Josef's Reviewed-by on patch 9 because it was completely > rewritten to change the mount options like Dave suggested. These are > still based on 4.2 I decided to take one

Re: [PATCH v3 0/9] Btrfs: free space B-tree

On 2015-09-14 02:04, Omar Sandoval wrote: Hi, everyone, I went back and fixed the issues that came up since v2. Changes below. I removed Josef's Reviewed-by on patch 9 because it was completely rewritten to change the mount options like Dave suggested. These are still based on 4.2 Thanks!

Re: Horrible dbench performance

On 09/14/2015 11:28 AM, Liu Bo wrote: Hi, Both [1] and [2] had run dbench on btrfs with fast storage, and showed bad numbers, I got an impression that after refractoring btree lock to smart rwlock, we have mitigated this issue.. Not got a fast-enough ssd handy, does anyone confirm the result

Horrible dbench performance

Hi, Both [1] and [2] had run dbench on btrfs with fast storage, and showed bad numbers, I got an impression that after refractoring btree lock to smart rwlock, we have mitigated this issue.. Not got a fast-enough ssd handy, does anyone confirm the result showed in those link?

Re: unable to mount multi disk volume with recovery mode

Anand Jain posted on Mon, 14 Sep 2015 17:44:25 +0800 as excerpted: > Hi Qu, > >> Unfortunately, single mode means no duplication. >> And degrade mount only works for RAID level with >> duplication(DUP,RAID1/5/6/10). > > further to the below commit. > > commit

Re: Horrible dbench performance

On Mon, Sep 14, 2015 at 03:31:27PM -0400, Chris Mason wrote: > On Mon, Sep 14, 2015 at 11:28:21PM +0800, Liu Bo wrote: > > Hi, > > > > Both [1] and [2] had run dbench on btrfs with fast storage, and > > showed bad numbers, I got an impression that after refractoring btree lock > > to > > smart

Re: unable to mount multi disk volume with recovery mode

Hi Aand, Anand Jain wrote on 2015/09/14 17:44 +0800: Hi Qu, Unfortunately, single mode means no duplication. And degrade mount only works for RAID level with duplication(DUP,RAID1/5/6/10). further to the below commit. commit 95669976bd7d30ae265db938ecb46a6b7f8cb893 Btrfs: don't

Re: [PATCH v3 0/9] Btrfs: free space B-tree

On Mon, Sep 14, 2015 at 11:18:36AM -0400, Austin S Hemmelgarn wrote: > On 2015-09-14 02:04, Omar Sandoval wrote: > >Hi, everyone, > > > >I went back and fixed the issues that came up since v2. Changes below. I > >removed Josef's Reviewed-by on patch 9 because it was completely > >rewritten to

Re: [PATCH v3 0/9] Btrfs: free space B-tree

On Mon, Sep 14, 2015 at 04:51:48PM +0200, Holger Hoffstätte wrote: > On 09/14/15 08:04, Omar Sandoval wrote: > > I went back and fixed the issues that came up since v2. Changes below. I > > removed Josef's Reviewed-by on patch 9 because it was completely > > rewritten to change the mount options

Re: [PATCH v2 8/9] vfs: copy_file_range() can do a pagecache copy with splice

On Fri, Sep 11, 2015 at 04:30:21PM -0400, Anna Schumaker wrote: > The NFS server will need some kind offallback for filesystems that don't > have any kind of copy acceleration, and it should be generally useful to > have an in-kernel copy to avoid lots of switches between kernel and user > space.

Re: [PATCH 06/39] Btrfs: drop null test before destroy functions

On Sun, Sep 13, 2015 at 02:14:59PM +0200, Julia Lawall wrote: > Remove unneeded NULL test. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ expression x; @@ > -if (x != NULL) > \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);

Re: [PATCH v2 10/9] copy_file_range.2: New page documenting copy_file_range()

On Sun, Sep 13, 2015 at 09:50:18AM +0200, Michael Kerrisk (man-pages) wrote: > Hi Anna, > > On 09/11/2015 10:30 PM, Anna Schumaker wrote: > > copy_file_range() is a new system call for copying ranges of data > > completely in the kernel. This gives filesystems an opportunity to > > implement

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Sep 13, 2015 4:25 PM, "Dave Chinner" wrote: > > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: > > Can we have a clean way to figure out whether two file ranges are the > > same in a way that allows false negatives? I.e. return 1 if the > > ranges are

Re: [PATCH v3 1/3] btrfs-progs: use calloc instead of malloc+memset for tree roots

On Sun, Sep 13, 2015 at 11:08:22PM -0700, Omar Sandoval wrote: > From: Omar Sandoval > > Signed-off-by: Omar Sandoval I don't know why I missed this patch last time, but now applied to devel for real. -- To unsubscribe from this list: send the line "unsubscribe

Re: Horrible dbench performance

On Mon, Sep 14, 2015 at 11:28:21PM +0800, Liu Bo wrote: > Hi, > > Both [1] and [2] had run dbench on btrfs with fast storage, and > showed bad numbers, I got an impression that after refractoring btree lock to > smart rwlock, we have mitigated this issue.. > > Not got a fast-enough ssd handy,

Re: [PATCH v2 10/9] copy_file_range.2: New page documenting copy_file_range()

On 2015-09-13 03:50, Michael Kerrisk (man-pages) wrote: Hi Anna, On 09/11/2015 10:30 PM, Anna Schumaker wrote: copy_file_range() is a new system call for copying ranges of data completely in the kernel. This gives filesystems an opportunity to implement some kind of "copy acceleration", such

Re: unable to mount multi disk volume with recovery mode

Hi Ivan, Ivan Petrovic wrote on 2015/09/04 22:45 +0200: Hello, I had 3 HDDs in single mode and one died. Unfortunately, single mode means no duplication. And degrade mount only works for RAID level with duplication(DUP,RAID1/5/6/10). So you lost all your data. Thanks, Qu I have put a

[PATCH v3 5/9] Btrfs: introduce the free space B-tree on-disk format

From: Omar Sandoval The on-disk format for the free space tree is straightforward. Each block group is represented in the free space tree by a free space info item that stores accounting information: whether the free space for this block group is stored as bitmaps or extents and

[PATCH v3 2/9] Btrfs: add extent buffer bitmap sanity tests

From: Omar Sandoval Sanity test the extent buffer bitmap operations (test, set, and clear) against the equivalent standard kernel operations. Signed-off-by: Omar Sandoval --- fs/btrfs/extent_io.c | 34 ++ fs/btrfs/extent_io.h |

[PATCH v3 8/9] Btrfs: wire up the free space tree to the extent tree

From: Omar Sandoval The free space tree is updated in tandem with the extent tree. There are only a handful of places where we need to hook in: 1. Block group creation 2. Block group deletion 3. Delayed refs (extent creation and deletion) 4. Block group caching Signed-off-by:

[PATCH v3 6/9] Btrfs: implement the free space B-tree

From: Omar Sandoval The free space cache has turned out to be a scalability bottleneck on large, busy filesystems. When the cache for a lot of block groups needs to be written out, we can get extremely long commit times; if this happens in the critical section, things are

[PATCH v3 1/9] Btrfs: add extent buffer bitmap operations

From: Omar Sandoval These are going to be used for the free space tree bitmap items. Signed-off-by: Omar Sandoval --- fs/btrfs/extent_io.c | 149 +++ fs/btrfs/extent_io.h | 6 +++ 2 files changed, 155

[PATCH v3 4/9] Btrfs: refactor caching_thread()

From: Omar Sandoval We're also going to load the free space tree from caching_thread(), so we should refactor some of the common code. Signed-off-by: Omar Sandoval --- fs/btrfs/ctree.h | 3 +++ fs/btrfs/extent-tree.c | 59

[PATCH v3 3/9] Btrfs: add helpers for read-only compat bits

From: Omar Sandoval We're finally going to add one of these for the free space tree, so let's add the same nice helpers that we have for the incompat bits. While we're add it, also add helpers to clear the bits. Reviewed-by: Josef Bacik Signed-off-by: Omar

[PATCH v3 9/9] Btrfs: add free space tree mount option

From: Omar Sandoval Now we can finally hook up everything so we can actually use free space tree. The free space tree is enabled by passing the space_cache=v2 mount option. On the first mount with the this option set, the free space tree will be created and the FREE_SPACE_TREE

[PATCH v3 7/9] Btrfs: add free space tree sanity tests

From: Omar Sandoval This tests the operations on the free space tree trying to excercise all of the main cases for both formats. Between this and xfstests, the free space tree should have pretty good coverage. Signed-off-by: Omar Sandoval --- fs/btrfs/Makefile

[PATCH v3 0/9] Btrfs: free space B-tree

Hi, everyone, I went back and fixed the issues that came up since v2. Changes below. I removed Josef's Reviewed-by on patch 9 because it was completely rewritten to change the mount options like Dave suggested. These are still based on 4.2 Thanks! Changes from v2->v3: - Fixed a warning in the

[PATCH v3 3/3] btrfs-progs: check the free space tree in btrfsck

From: Omar Sandoval This reuses the existing code for checking the free space cache, we just need to load the free space tree. While we do that, we check a couple of invariants on the free space tree itself. This requires pulling in some code from the kernel to exclude the super

[PATCH v3 2/3] btrfs-progs: add basic awareness of the free space tree

From: Omar Sandoval To start, let's tell btrfs-progs to read the free space root and how to print the on-disk format of the free space tree. However, we're not adding the FREE_SPACE_TREE read-only compat bit to the set of supported bits because progs doesn't know how to keep the

[PATCH v3 1/3] btrfs-progs: use calloc instead of malloc+memset for tree roots

From: Omar Sandoval Signed-off-by: Omar Sandoval --- disk-io.c | 22 +++--- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/disk-io.c b/disk-io.c index 1d4889322411..8496aded31c4 100644 --- a/disk-io.c +++ b/disk-io.c @@ -833,13

[PATCH] Btrfs: fix read corruption of compressed and shared extents

From: Filipe Manana If a file has a range pointing to a compressed extent, followed by another range that points to the same compressed extent and a read operation attempts to read both ranges (either completely or part of them), the pages that correspond to the second range

[PATCH] fstests: regression test for btrfs read corruption of compressed extents

From: Filipe Manana Regression test for file read corruption when using compressed extents that are shared by multiple consecutive ranges of the same file. The btrfs issue is fixed by the linux kernel patch titled: "Btrfs: fix read corruption of compressed and shared extents"

Re: [PATCH] Btrfs: fix read corruption of compressed and shared extents

On Mon, Sep 14, 2015 at 10:08 AM, Qu Wenruo wrote: > Hi Filepe, > > > wrote on 2015/09/14 09:29 +0100: >> >> From: Filipe Manana >> >> If a file has a range pointing to a compressed extent, followed by >> another range that points to the same

Re: [PATCH] Btrfs: fix read corruption of compressed and shared extents

Filipe Manana wrote on 2015/09/14 10:22 +0100: On Mon, Sep 14, 2015 at 10:08 AM, Qu Wenruo wrote: Hi Filepe, wrote on 2015/09/14 09:29 +0100: From: Filipe Manana If a file has a range pointing to a compressed extent, followed by another

Re: unable to mount multi disk volume with recovery mode

Hi Qu, Unfortunately, single mode means no duplication. And degrade mount only works for RAID level with duplication(DUP,RAID1/5/6/10). further to the below commit. commit 95669976bd7d30ae265db938ecb46a6b7f8cb893 Btrfs: don't consider the missing device when allocating new chunks in

Re: [PATCH] Btrfs: fix read corruption of compressed and shared extents

Hi Filepe, wrote on 2015/09/14 09:29 +0100: From: Filipe Manana If a file has a range pointing to a compressed extent, followed by another range that points to the same compressed extent and a read operation attempts to read both ranges (either completely or part of them),