Re: [PATCH] fstests: test for btrfs incremental send after replacing a file

On Sat, Sep 26, 2015 at 12:40:13PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Test that an incremental send works after a file from the parent snapshot > gets replaced in the send snapshot by another one at the same exact > location, with the same name and

lots of snapshots, forcing defragmentation, and figuring out which files to defrag or nodatacow

(Trying again in plain text and without the 100KiB log file.) Hi linux-btrfs, The context of these three questions is that I'm experiencing occasional hangs for several seconds while btrfs-transacti works, and very long boot times. General comments welcome. System info at bottom, end part of

Add stripes filter

Hello everyone! The attached patches to linux and btrfs-progs add support for filtering based on the number of strips in a block when balancing. This is my first attempt at kernel development, I'd love if you could please point out any mistakes that I've made. Thanks, Gabríel P.S. I could not

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

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

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

On Fri, Sep 25, 2015 at 04:48:16PM -0400, 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 as reflinks or > server-side-copy (in the

Re: [PATCH v3 5/9] vfs: Copy shouldn't forbid ranges inside the same file

On Fri, Sep 25, 2015 at 04:48:11PM -0400, Anna Schumaker wrote: > This is perfectly valid for BTRFS and XFS, so let's leave this up to > filesystems to check. > > Signed-off-by: Anna Schumaker > Reviewed-by: David Sterba Reviewed-by: Darrick J. Wong

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

On Tue, Sep 22, 2015 at 04:10:47PM -0400, Anna Schumaker wrote: > On 09/14/2015 02:32 PM, Darrick J. Wong wrote: > > 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

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

On 09/28/2015 02:31 PM, Darrick J. Wong wrote: > On Fri, Sep 25, 2015 at 04:48:14PM -0400, Anna Schumaker wrote: >> The NFS server will need some kind offallback for filesystems that don't > > "some kind of fallback" I'll rephrase that :) > >> have any kind of copy acceleration, and it should

Re: mkfs.btrfs(8) --data outdated?

Thanks for the help (and the story :P ). The partition was just a test. On 09/28/2015 04:19 AM, Duncan wrote: Juan Francisco Cantero Hurtado posted on Sun, 27 Sep 2015 22:33:01 +0200 as excerpted: kernel: 4.1.7 btrfs-progs: 4.2 mkfs.btrfs(8) man page says: -d|--data Specify how

Re: Add stripes filter

On Mon, Sep 28, 2015 at 05:57:05PM +, Gabríel Arthúr Pétursson wrote: > Hello everyone! > > The attached patches to linux and btrfs-progs add support for filtering > based on the number of strips in a block when balancing. > > This is my first attempt at kernel development, I'd love if you

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

On 09/28/2015 02:40 PM, Darrick J. Wong wrote: > On Fri, Sep 25, 2015 at 04:48:16PM -0400, 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

Re: btrfs fi defrag interfering (maybe) with Ceph OSD operation

Lionel Bouton posted on Mon, 28 Sep 2015 11:55:15 +0200 as excerpted: > From what I understood, filefrag doesn't known the length of each extent > on disk but should have its position. This is enough to have a rough > estimation of how badly fragmented the file is : it doesn't change the > result

Re: btrfs fi defrag interfering (maybe) with Ceph OSD operation

Le 28/09/2015 22:52, Duncan a écrit : > Lionel Bouton posted on Mon, 28 Sep 2015 11:55:15 +0200 as excerpted: > >> From what I understood, filefrag doesn't known the length of each extent >> on disk but should have its position. This is enough to have a rough >> estimation of how badly fragmented

RE: [PATCH v2 1/2] btrfs-progs: Introduce warning and error for common use

Hi, David Sterba Thanks for review. > -Original Message- > From: David Sterba [mailto:dste...@suse.cz] > Sent: Friday, September 25, 2015 6:50 PM > To: Zhao Lei > Cc: linux-btrfs@vger.kernel.org; Qu Wenruo > Subject: Re: [PATCH v2 1/2]

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

On 09/25/2015 08:14 PM, Andy Lutomirski wrote: > On Fri, Sep 25, 2015 at 1:48 PM, 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

[PATCH v3 0/2] btrfs-progs: Introduce warning and error for common use

Current code use fprintf(stderr, "...") to output warnning and error information. The error message have different style, as: # grep fprintf *.c fprintf(stderr, "Open ctree failed\n"); fprintf(stderr, "%s: open ctree failed\n", __func__); fprintf(stderr, "ERROR: cannot open ctree\n"); ...

[PATCH v3 2/2] btrfs-progs: use common warning/error for cmds-scrub.c

Use common warning/error functions in cmds-scrub.c, it can make message format unified and make code simple. Signed-off-by: Qu Wenruo Signed-off-by: Zhao Lei --- cmds-scrub.c | 176 +-- 1

[PATCH v3 1/2] btrfs-progs: Introduce warning and error for common use

Current code use fprintf(stderr, "...") to output warnning and error information. The error message have different style, as: # grep fprintf *.c fprintf(stderr, "Open ctree failed\n"); fprintf(stderr, "%s: open ctree failed\n", __func__); fprintf(stderr, "ERROR: cannot open ctree\n"); ...

Re: fstrim silently does nothing on dev add/dev rem'd filesystem

Rich Freeman posted on Sun, 27 Sep 2015 23:08:49 -0400 as excerpted: > On Sun, Sep 27, 2015 at 10:45 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> But I think part of reasoning behind the relatively low priority this >> issue has received is that it's a low visibility issue not really >> affecting

Re: strange i/o errors with btrfs on raid/lvm

Hi Chris, all, Am 2015-09-25 um 22:47 schrieb Chris Murphy: > On Fri, Sep 25, 2015 at 2:26 PM, Jogi Hofmüller wrote: > >> That was right while the RAID was in degraded state and rebuilding. > > On the guest: > > Aug 28 05:17:01 vm kernel: [140683.741688] BTRFS info (device vdc):

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

From: Filipe Manana My previous fix in commit 005efedf2c7d ("Btrfs: fix read corruption of compressed and shared extents") was effective only if the compressed extents cover a file range with a length that is not a multiple of 16 pages. That's because the detection of when we

Re: btrfs fi defrag interfering (maybe) with Ceph OSD operation

Hi Duncan, thanks for your answer, here is additional information. Le 28/09/2015 02:18, Duncan a écrit : > [...] >> I decided to disable it and develop our own >> defragmentation scheduler. It is based on both a slow walk through the >> filesystem (which acts as a safety net over one week

[PATCH] fstests: btrfs, test read corruption of compressed extents differently

From: Filipe Manana Regression test for file read corruption when using compressed extents that represent file ranges with a length that is a multiple of 16 pages and that are shared by multiple consecutive ranges of the same file. This is similar to the test added in commit

[PATCH] btrfs: add stripes filter

--- fs/btrfs/ctree.h | 6 +- fs/btrfs/volumes.c | 18 ++ fs/btrfs/volumes.h | 1 + include/uapi/linux/btrfs.h | 6 +- 4 files changed, 29 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 938efe3..78573e5

Re: btrfs: obtain block checksums from user space

On Mon, 2015-09-28 at 23:16 +, Hugo Mills wrote: > On Mon, Sep 28, 2015 at 07:11:51PM -0400, Calvin Walton wrote: > > > > The problem with trying to use btrfs checksums to compare two > > different > > files is that the blocks might not match up, if only due to > > fragmentation. E.g., the

Re: [PATCH] fstests: btrfs: add test for quota groups and drop snapshot

On Wed, Sep 23, 2015 at 02:05:16PM -0700, Mark Fasheh wrote: > Since the last time I sent this test, drop snapshot was broken again with > respect to qgroups. What practical step could I take to get a test for that > in here which I can beat the btrfs developers over the head with the next > time

Re: btrfs: obtain block checksums from user space

On Thu, 2015-09-24 at 21:48 +0300, Matwey V. Kornilov wrote: > 2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn > : > > On 2015-09-24 14:06, Matwey V. Kornilov wrote: > > It's worth noting that the way btrfs does checksums isn't per-file, > > it's > > per-block. This means

Re: btrfs: obtain block checksums from user space

On Mon, Sep 28, 2015 at 07:11:51PM -0400, Calvin Walton wrote: > On Thu, 2015-09-24 at 21:48 +0300, Matwey V. Kornilov wrote: > > 2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn > > : > > > On 2015-09-24 14:06, Matwey V. Kornilov wrote: > > > > It's worth noting that the way

Re: [PATCH] btrfs: remove empty header file extent-tree.h

Hi Chris, Would you please merge this patch? The empty header is introduced by my qgroup accounting rework, and the cleanup patch is missed in 4.2. Thanks, Qu Qu Wenruo wrote on 2015/07/03 09:17 +0800: The empty file is introduced as an careless 'git add', remove it. Reported-by: David

Re: btrfs receive bigger than original snapshot?

Hi, On Wed, Sep 23, 2015 at 09:41:21AM +0100, Filipe David Manana wrote: > On Tue, Sep 22, 2015 at 9:04 PM, Hugo Mills wrote: > > On Tue, Sep 22, 2015 at 09:52:19PM +0200, carlo von lynX wrote: > >> Hello, it's me again. This time I searched the web to make sure > >> I'm not

[PATCH 04/17] fs/btrfs: remove unnecessary new_valid_dev check

As new_valid_dev always returns 1, so !new_valid_dev check is not needed, remove it. Signed-off-by: Yaowei Bai --- fs/btrfs/inode.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 611b66d..0946790 100644 --- a/fs/btrfs/inode.c