The test case passes file offsets which are aligned to 4k block size. This
causes btrfs_ioctl_clone() to return with -EINVAL for larger block sizes. Fix
this by computing file offsets at run time based on the block size of the
underlying filesystem.
Signed-off-by: Chandan Rajendra
-Original Message-
From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
ow...@vger.kernel.org] On Behalf Of Chris Murphy
Sent: Wednesday, 25 March 2015 3:10 AM
To: Chris Mason; Chris Murphy; Btrfs BTRFS
Subject: Re: kvm bug, guest I/O blk device errors when qcow2 backing file
Do you need any financial assistance? if yes,
Contact us with this email:
richardmalc...@foxmail.commailto:richardmalc...@foxmail.com
In Spanish
¿Necesita alguna ayuda económica? en caso afirmativo,
Póngase en contacto con nosotros con este correo electrónico:
Hello Filipe,
On Thursday 26 Mar 2015 10:59:28 Filipe David Manana wrote:
On Thu, Mar 26, 2015 at 9:07 AM, Chandan Rajendra
chan...@linux.vnet.ibm.com wrote:
The test case passes file offsets which are aligned to 4k block size.
This
causes btrfs_ioctl_clone() to return with -EINVAL for
On Thu, Mar 26, 2015 at 9:07 AM, Chandan Rajendra
chan...@linux.vnet.ibm.com wrote:
The test case passes file offsets which are aligned to 4k block size. This
causes btrfs_ioctl_clone() to return with -EINVAL for larger block sizes. Fix
this by computing file offsets at run time based on the
Just like to share this :
CC fs/btrfs/print-tree.o
fs/btrfs/extent-tree.c: In function ‘find_free_extent’:
fs/btrfs/extent-tree.c:6402:34: warning: ‘used_bg’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
struct btrfs_block_group_cache *used_bg;
On Mar 26 2015, Chris Murphy li...@colorremedies.com wrote:
On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath nikol...@rath.org wrote:
I'm running 4.0-rc3, and I'm regularly getting these warnings in my
kernel log:
Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID:
28958 at
On Thu, Mar 26, 2015 at 12:28:42PM -0500, Eric Sandeen wrote:
commit:
5e8b9e6 btrfs: add regression test for remount with thread_pool resized
did weird things to _filter_mkfs; aside from broken indentation,
it also short-circuited the default non-xfs behavior, which was to
emit a default
On Thu, Mar 26, 2015 at 9:39 PM, Nikolaus Rath nikol...@rath.org wrote:
Thanks. Does this mean that I risk data corruption when using btrfs with
4.0-rc3, or is this relatively harmless?
I can't answer that. I'd say use 3.18.9 or 3.19.2 if you want reduced
risk of corruption, or use the current
On Thu, Mar 26, 2015 at 12:11:51PM -0500, Eric Sandeen wrote:
On 3/26/15 9:48 AM, Chris Mason wrote:
On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen sand...@redhat.com wrote:
...
9c4f61f btrfs: simplify insert_orphan_item
made the whole path alloc/free go away.
so I think
On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath nikol...@rath.org wrote:
I'm running 4.0-rc3, and I'm regularly getting these warnings in my
kernel log:
Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at
fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()
On 3/26/15 9:48 AM, Chris Mason wrote:
On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen sand...@redhat.com wrote:
...
9c4f61f btrfs: simplify insert_orphan_item
made the whole path alloc/free go away.
so I think there's no need for my patch; may as well just send the above to
stable
and
commit:
5e8b9e6 btrfs: add regression test for remount with thread_pool resized
did weird things to _filter_mkfs; aside from broken indentation,
it also short-circuited the default non-xfs behavior, which was to
emit a default block inode size. And that was all because btrfs/082
was using
On Thu, Mar 26, 2015 at 5:11 PM, Eric Sandeen sand...@redhat.com wrote:
On 3/26/15 9:48 AM, Chris Mason wrote:
On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen sand...@redhat.com wrote:
...
9c4f61f btrfs: simplify insert_orphan_item
made the whole path alloc/free go away.
so I think
On 25/03/15 01:30, Rich Freeman wrote:
On Mon, Mar 23, 2015 at 7:22 PM, Hugo Mills h...@carfax.org.uk wrote:
On Mon, Mar 23, 2015 at 11:10:46PM +, Martin wrote:
As titled:
Does btrfs have dedup (on raid1 multiple disks) that can be enabled?
The current state of play is on the wiki:
For anyone stumbling across this thread:
For my example, all was cleaned up by using the btrfs scrub:
btrfs scrub start /mountpoint
No data lost.
Good luck,
Martin
On 25/03/15 09:38, Martin wrote:
Is that btrfs system formatted with a previous kernel (pre-
skinny-metadata) and is now
On Thu, Mar 26, 2015 at 8:07 PM, Martin m_bt...@ml1.co.uk wrote:
Anyone with any comments on how well duperemove performs for TB-sized
volumes?
Took many hours but less than a day for a few TB - I'm not sure
whether it is smart enough to take less time on subsequent scans like
bedup.
Does
Hello,
I'm running 4.0-rc3, and I'm regularly getting these warnings in my
kernel log:
Mar 26 17:31:13 vostro kernel: [21480.088671] [ cut here
]
Mar 26 17:31:13 vostro kernel: [21480.088682] WARNING: CPU: 0 PID: 28958 at
fs/btrfs/inode.c:8693
Hi Duncan,
Thanks very much, it's very helpful to know this. I do have in the low
thousands of subvolumes now (and as you say, normal usage is fine but
the btrfs management commands take some time). I'll make sure that the
number doesn't get much higher.
Anand
On Wed, Mar 25, 2015 at 10:28 PM,
On 3/26/15 5:23 AM, Filipe David Manana wrote:
On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen sand...@redhat.com wrote:
Looks like btrfs: fix leak of path in btrfs_find_item got sent
to stable trees, but in my testing, it causes deadlocks on mount:
[23379.359246] mount D
On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen sand...@redhat.com
wrote:
On 3/26/15 5:23 AM, Filipe David Manana wrote:
On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen sand...@redhat.com
wrote:
Looks like btrfs: fix leak of path in btrfs_find_item got sent
to stable trees, but in my testing,
21 matches
Mail list logo
