Re: btrfs corruption / bug after sending and receiving and repair

On Fri, Sep 11, 2015 at 10:39 AM, Jonas von Malottki wrote: > Hi Btrfslers, > > I was playing around with send and receive facility to store backups at a > remote machine. Unfortunately I send more data to a device that it could > handle. So the receive operation was ended with

Re: [PATCH 0/2] btrfs: fortification for GFP_NOFS allocations

On Wed 09-09-15 18:13:39, Vlastimil Babka wrote: > On 08/19/2015 08:17 PM, Chris Mason wrote: > >On Wed, Aug 19, 2015 at 02:17:39PM +0200, mho...@kernel.org wrote: > >>Hi, > >>these two patches were sent as a part of a larger RFC which aims at > >>allowing GFP_NOFS allocations to fail to help sort

btrfs corruption / bug after sending and receiving and repair

Hi Btrfslers, I was playing around with send and receive facility to store backups at a remote machine. Unfortunately I send more data to a device that it could handle. So the receive operation was ended with "could not write file, no more space left on device". So far so good, no big deal. To

Aw: Re: btrfs corruption / bug after sending and receiving and repair

> Gesendet: Freitag, 11. September 2015 um 11:49 Uhr > Von: "Filipe David Manana" > An: "Jonas von Malottki" > Cc: "linux-btrfs@vger.kernel.org" > Betreff: Re: btrfs corruption / bug after sending and receiving and repair > >

Re: btrfs regression since 4.X kernel NULL pointer dereference

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/25/15 5:00 AM, Christoph Hellwig wrote: > I think this is btrfs using a struct block_device that doesn't > have a valid queue pointer in it's gendisk for ->s_bdev. And there > are some fishy looking ->s_bdev assignments in the code which I >

Re: btrfs regression since 4.X kernel NULL pointer dereference

On Fri, Sep 11, 2015 at 02:55:17PM -0400, Jeff Mahoney wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 8/25/15 5:00 AM, Christoph Hellwig wrote: > > I think this is btrfs using a struct block_device that doesn't > > have a valid queue pointer in it's gendisk for ->s_bdev. And

Re: [PATCH] Btrfs: keep dropped roots in cache until transaciton commit

On Fri, Sep 11, 2015 at 09:25:25AM +0800, Qu Wenruo wrote: > Josef Bacik wrote on 2015/09/10 16:27 -0400: > >When dropping a snapshot we need to account for the qgroup changes. If we > >drop > >the snapshot in all one go then the backref code will fail to find blocks > >from > >the snapshot we

Re: btrfs regression since 4.X kernel NULL pointer dereference

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/15 2:55 PM, Jeff Mahoney wrote: > On 8/25/15 5:00 AM, Christoph Hellwig wrote: >> I think this is btrfs using a struct block_device that doesn't >> have a valid queue pointer in it's gendisk for ->s_bdev. And >> there are some fishy looking

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

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 case of NFS). Signed-off-by: Anna Schumaker

[PATCH v2 2/9] x86: add sys_copy_file_range to syscall tables

From: Zach Brown Add sys_copy_file_range to the x86 syscall tables. Signed-off-by: Zach Brown [Anna Schumaker: Update syscall number in syscall_32.tbl] Signed-off-by: Anna Schumaker --- arch/x86/entry/syscalls/syscall_32.tbl | 1 +

[PATCH v2 9/9] btrfs: btrfs_copy_file_range() only supports reflinks

Reject copies that don't have the COPY_FR_REFLINK flag set. Signed-off-by: Anna Schumaker --- fs/btrfs/ioctl.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 4311554..2e14b91 100644 --- a/fs/btrfs/ioctl.c +++

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

This is perfectly valid for BTRFS and XFS, so let's leave this up to filesystems to check. Signed-off-by: Anna Schumaker --- fs/read_write.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index 38cc251..d32549b 100644 ---

[PATCH v2 6/9] vfs: Copy should use file_out rather than file_in

The way to think about this is that the destination filesystem reads the data from the source file and processes it accordingly. This is especially important to avoid an infinate loop when doing a "server to server" copy on NFS. Signed-off-by: Anna Schumaker ---

[GIT PULL] Btrfs

Hi Linus, We have a few more for the btrfs tree in my for-linus-4.3 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.3 These are small cleanups, and also some fixes for our async worker thread initialization. I was having some trouble testing these, but

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

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. I make this configurable by adding two new flags. Users who only want

[PATCH v2 1/9] vfs: add copy_file_range syscall and vfs helper

From: Zach Brown Add a copy_file_range() system call for offloading copies between regular files. This gives an interface to underlying layers of the storage stack which can copy without reading and writing all the data. There are a few candidates that should support copy

[PATCH v2 3/9] btrfs: add .copy_file_range file operation

From: Zach Brown This rearranges the existing COPY_RANGE ioctl implementation so that the .copy_file_range file operation can call the core loop that copies file data extent items. The extent copying loop is lifted up into its own function. It retains the core btrfs error

[PATCH v2 0/9] VFS: In-kernel copy system call

Copy system calls came up during Plumbers a couple of weeks ago, because several filesystems (including NFS and XFS) are currently working on copy acceleration implementations. We haven't heard from Zach Brown in a while, so I volunteered to push his patches upstream so individual filesystems

[PATCH v2 7/9] vfs: Remove copy_file_range mountpoint checks

I still want to do an in-kernel copy even if the files are on different mountpoints, and NFS has a "server to server" copy that expects two files on different mountpoints. Let's have individual filesystems implement this check instead. Signed-off-by: Anna Schumaker

[PATCH v2 4/9] vfs: Copy should check len after file open mode

I don't think it makes sense to report that a copy succeeded if the files aren't open properly. Signed-off-by: Anna Schumaker --- fs/read_write.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index

Re: btrfs regression since 4.X kernel NULL pointer dereference

Am 11.09.2015 um 21:05 schrieb Jeff Mahoney: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/15 2:55 PM, Jeff Mahoney wrote: On 8/25/15 5:00 AM, Christoph Hellwig wrote: I think this is btrfs using a struct block_device that doesn't have a valid queue pointer in it's gendisk for

Re: btrfs regression since 4.X kernel NULL pointer dereference

Stefan Priebe wrote... > Thanks. We're using schroot like the user in this bugreport: > https://bugzilla.kernel.org/show_bug.cgi?id=100911 > > But he also claims he found another way to reproduce using vfcgbackup (last > comment). FWIW, this was still the same thing, just stripped down to get

[PATCH] btrfs: skip waiting on ordered range for special files

In btrfs_evict_inode, we properly truncate the page cache for evicted inodes but then we call btrfs_wait_ordered_range for every inode as well. It's the right thing to do for regular files but results in incorrect behavior for device inodes for block devices. filemap_fdatawrite_range gets called

Re: [PATCH] btrfs-progs: fix cross stripe boundary check

On Thu, Sep 10, 2015 at 5:02 PM, David Sterba wrote: > Commit 854437ca3c228d8ab3eb24d2efc1c21b5d56a635 ("btrfs-progs: > extent-tree: avoid allocating tree block that crosses stripe boundary") > does not work for 64k nodesize. Due to an off-by-one error, all queries > to

Re: [PATCH] btrfs-progs: fix cross stripe boundary check

On Fri, Sep 11, 2015 at 03:16:02PM +0200, Holger Hoffstätte wrote: > Am I correct that this also causes false positives with btrfs check? I just > ran a sanity check on an fs that had no problems whatsoever and was > definitely not converted (so 16k nodesize) and got thousands of > cross-stripe

Re: [PATCH] btrfs-progs: fix cross stripe boundary check

On Fri, Sep 11, 2015 at 08:27:17AM +0800, Qu Wenruo wrote: > BTW, any idea to add mkfs test? Yes, I'll add a test that will cycle through combinations of various options (nodesize, raid profiles). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message

Re: [PATCH 0/4] Fix for btrfs-convert chunk type and fsck support

On Thu, Sep 10, 2015 at 10:34:13AM +0800, Qu Wenruo wrote: > Again the buggy btrfs-convert, even David tried to ban mixed-bg features > for btrfs-convert, it will still put data and metadata extents into the > same chunk, without marking the chunk mixed. > > So in the patchset, first add fsck

Re: [PATCH 0/4] Fix for btrfs-convert chunk type and fsck support

在 2015年09月11日 22:56, David Sterba 写道: On Thu, Sep 10, 2015 at 10:34:13AM +0800, Qu Wenruo wrote: Again the buggy btrfs-convert, even David tried to ban mixed-bg features for btrfs-convert, it will still put data and metadata extents into the same chunk, without marking the chunk mixed. So in

Re: [PATCH 1/3] btrfs-progs: Fix infinite loop of btrfs-image

On Wed, Sep 09, 2015 at 09:32:21PM +0800, Zhao Lei wrote: > Bug: > # btrfs-image -t0 -c9 /dev/sda6 /tmp/btrfs_image.img > (hang) > # btrfs-image -r -t0 /tmp/btrfs_image.img /dev/sda6 > (hang) > > Reason: > Program need to create at least 1 thread for compress/decompress. > but if user

Re: [PATCH] Btrfs: keep dropped roots in cache until transaciton commit

On 09/10/2015 09:25 PM, Qu Wenruo wrote: Josef Bacik wrote on 2015/09/10 16:27 -0400: When dropping a snapshot we need to account for the qgroup changes. If we drop the snapshot in all one go then the backref code will fail to find blocks from the snapshot we dropped since it won't be able to