Test for a btrfs incremental send issue where we end up sending a
wrong section of data from a file extent if the corresponding file
extent is compressed and the respective file extent item has a non
zero data offset.
Fixed by the following linux kernel btrfs patch:
Btrfs: use right clone
For non compressed extents, iterate_extent_inodes() gives us offsets
that take into account the data offset from the file extent items, while
for compressed extents it doesn't. Therefore we have to adjust them before
placing them in a send clone instruction. Not doing this adjustment leads to
the
If we punch beyond the size of an inode, we'll correctly remove any prealloc
extents,
but we'll also insert file extent items representing holes (disk bytenr == 0)
that start
with a key offset that lies beyond the inode's size and are not contiguous with
the last
file extent item.
Example:
On Fri, 14 Feb 2014 14:29:35 -0500
Josef Bacik jba...@fb.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/14/2014 02:25 PM, Johannes Hirte wrote:
On Thu, 6 Feb 2014 16:19:46 -0500 Josef Bacik jba...@fb.com
wrote:
Ok so I thought I reproduced the problem but I just
On Sat, Feb 1, 2014 at 2:00 AM, Filipe David Borba Manana
fdman...@gmail.com wrote:
This fixes a case that the commit titled:
Btrfs: fix infinite path build loops in incremental send
didn't cover. If the parent-child relationship between 2 directories
is inverted, both get renamed, and
On Sat, Feb 1, 2014 at 2:02 AM, Filipe David Borba Manana
fdman...@gmail.com wrote:
The commit titled Btrfs: fix infinite path build loops in incremental send
didn't cover a particular case where the parent-child relationship inversion
of directories doesn't imply a rename of the new parent
Hello Hugo,
Is this issue specific to the receive ioctl?
Because what you are describing applies to any user-kernel ioctl-based
interface, when you compile the user-space as 32-bit, which the kernel
space has been compiled as 64-bit. For that purpose, I believe, there
exists the compat_ioctl
On Sat, Feb 15, 2014 at 09:42:30PM +0200, Alex Lyakas wrote:
Hello Hugo,
Is this issue specific to the receive ioctl?
Yes. Everything else I've tried has worked perfectly on that test
system. The issue is not pointer size (which is, I think, your
thunking idea below), but structure
Hi list - I'm having problems with btrfs send in general, and
incremental send in particular.
1. Performance: in kernel 3.11, btrfs send would send data at 500+MB/sec
from a Samsung 840 series solid state drive. In kernel 3.12 and up,
btrfs send will only send 30-ish MB/sec from the same
On Fri, Feb 14, 2014 at 09:02:08PM -0600, Eric Sandeen wrote:
On 2/14/14, 7:39 PM, Dave Chinner wrote:
On Fri, Feb 14, 2014 at 05:48:59PM -0600, Eric Sandeen wrote:
On 2/14/14, 4:24 PM, Dave Chinner wrote:
On Fri, Feb 14, 2014 at 10:41:16AM -0600, Eric Sandeen wrote:
On 2/14/14, 10:39 AM,
On Feb 14, 2014, at 11:34 AM, Hugo Mills h...@carfax.org.uk wrote:
On Fri, Feb 14, 2014 at 07:27:57PM +0100, Goffredo Baroncelli wrote:
On 02/14/2014 07:11 PM, Roman Mamedov wrote:
On Fri, 14 Feb 2014 18:57:03 +0100
Goffredo Baroncelli kreij...@libero.it wrote:
On 02/13/2014 10:00 PM,
I'm on my phone so apologies for top posting but please try btrfs-next, I
recently fixed a pretty epic performance problem with send which should help
you, I'd like to see how much. Thanks,
Josef
Jim Salter j...@jrs-s.net wrote:
Hi list - I'm having problems with btrfs send in general, and
12 matches
Mail list logo
