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 w
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 ->s_bde
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 cl
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 d
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
---
fs/read_write.c | 5 -
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
don'
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 checks that should be
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 offloading in the near
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 a
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 82c4933..38cc251 100644
--- a/fs/rea
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
+++ b/fs/btrfs/ioctl.c
@@ -44,6 +44,7 @@
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
--- a/fs/read_write.c
+++ b/fs/read_
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 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
2 files changed
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
---
man2/copy_file_range.2 |
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
---
fs/read_write.c | 6 +++---
1 fi
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 ther
-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 -
-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
> susp
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 i
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
在 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 t
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 specif
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 supp
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 to
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 com
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 check_crossing_stripes will
> 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
>
> On Fri, Sep 11, 2015 at 10:39 AM, Jonas von Malottki wrote:
> > Hi
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 "could not write
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
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
30 matches
Mail list logo