Re: [PATCH] fstests: fix _filter_mkfs regression on btrfs

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 de

Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

On Thu, Mar 26, 2015 at 9:39 PM, Nikolaus Rath 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 week's rc (whic

Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

On Mar 26 2015, Chris Murphy wrote: > On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath 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_destr

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

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 wrote: > > ... > > 9c4f61f btrfs: simplify insert_orphan_item > > made the whole path alloc/free go away. > >> > >> so I thin

Re: Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

On Thu, Mar 26, 2015 at 6:38 PM, Nikolaus Rath 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]() It's known.

Kernel warning at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x1fa/0x2a0 [btrfs]()

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 btrfs_destroy_inode+0x1fa/0

Re: btrfs dedup - available or experimental? Or yet to be?

On Thu, Mar 26, 2015 at 8:07 PM, Martin 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 it work across

Re: btrfs-transacti causing IO problem to btrfs (skinny-metadata?)

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

Re: btrfs dedup - available or experimental? Or yet to be?

On 25/03/15 01:30, Rich Freeman wrote: > On Mon, Mar 23, 2015 at 7:22 PM, Hugo Mills 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:

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

On 3/26/15 12:25 PM, Filipe David Manana wrote: > On Thu, Mar 26, 2015 at 5:11 PM, Eric Sandeen wrote: >> On 3/26/15 9:48 AM, Chris Mason wrote: >>> On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen wrote: >> >> ... >> >> 9c4f61f btrfs: simplify insert_orphan_item >> >> made the whole

[PATCH] fstests: fix _filter_mkfs regression on btrfs

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 _fil

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

On Thu, Mar 26, 2015 at 5:11 PM, Eric Sandeen wrote: > On 3/26/15 9:48 AM, Chris Mason wrote: >> On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen wrote: > > ... > > 9c4f61f btrfs: simplify insert_orphan_item > > made the whole path alloc/free go away. >>> >>> so I think there's no nee

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

On 3/26/15 9:48 AM, Chris Mason wrote: > On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen 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 >> a

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen wrote: On 3/26/15 5:23 AM, Filipe David Manana wrote: On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen 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: [23

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

On 3/26/15 5:23 AM, Filipe David Manana wrote: > On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen 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

compile warning with for an UML config

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;

Re: [RFC PATCH] btrfs/052: Fix test case to work on variable block size.

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 > > 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 size

Re: [RFC PATCH] btrfs/052: Fix test case to work on variable block size.

On Thu, Mar 26, 2015 at 9:07 AM, Chandan Rajendra 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 block size of the > under

[no subject]

Do you need any financial assistance? if yes, Contact us with this email: richardmalc...@foxmail.com In Spanish ¿Necesita alguna ayuda económica? en caso afirmativo, Póngase en contacto con nosotros con este correo electrónico: richardmalc...@foxma

Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

On Thu, Mar 26, 2015 at 3:24 AM, Eric Sandeen 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 0 22541 22274 > 0x0080 > [23379.366326] 8

RE: kvm bug, guest I/O blk device errors when qcow2 backing file is on Btrfs

> -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

[RFC PATCH] btrfs/052: Fix test case to work on variable block size.

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 --- There are

Re: Metadata about to fill up, how to make it bigger next time?

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, D