On Wed, 2014-10-29 at 11:45 +0800, Anand Jain wrote:
> this is (most likely) due to patch below,
>
> commit 915902c5002485fb13d27c4b699a73fb66cc0f09
>
> btrfs-progs: fix device missing of btrfs fi show with seed devices
>
>
> Could you try to back out the
Original Message
Subject: Re: read block failed check_tree_block / Couldn't read chunk tree
From: Rene Thomas
To: Anand Jain
Date: 2014年10月31日 00:47
With commit patched out.
All devices in Place
uname -a
Linux engelserver 3.18.0-031800rc1-generic #201410192135 SMP Mon Oct
2
On Thu, Oct 30, 2014 at 9:02 PM, Tobias Holst wrote:
> Addition:
> I found some posts here about a general file system corruption in 3.17
> and 3.17.1 - is this the cause?
> Additionally I am using ro-snapshots - maybe this is the cause, too?
>
> Anyway: Can I fix that or do I have to reinstall? H
There might be more than one issue. I was trying solve errors
Check tree block failed, want=5845480062976, have=0
when 'btrfs fi show' was run. Thanks for confirming patchout
helped to fix that.
On 31/10/2014 00:47, Rene Thomas wrote:
With commit patched out.
All devices in Place
uname
On 30/10/2014 22:33, David Sterba wrote:
On Wed, Oct 15, 2014 at 08:51:09AM +0800, Anand Jain wrote:
--- a/volumes.c
+++ b/volumes.c
@@ -30,6 +30,7 @@
#include "print-tree.h"
#include "volumes.h"
#include "math.h"
+#include "utils.h"
struct stripe {
struct btrfs_device *dev;
@
This function is to register all devices found after scanning
the system. Before we had this functionality with in the
btrfs_scan_lblkid(), however scanning and registering are two
different distinct operation its better keep them separate.
Also we want to optimize btrfs_scan_lblkid and avoid multi
btrfs_scan_lblikd() is called by most the device related command functions.
And btrfs_scan_lblkid() is most expensive function and it becomes more expensive
as number of devices in the system increase. Further some threads call this
function more than once for absolutely no extra benefit and the re
On Oct 30, 2014, at 7:27 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Thu, 30 Oct 2014 12:04:48 -0600 as excerpted:
>
>>> Rob, That second drive was immediately put to use elsewhere. I figured
>>> having only the metadata on that drive, it wouldn't matter. The data
>>> staye
Hi David,
Thanks for the review..
On 30/10/2014 22:18, David Sterba wrote:
On Thu, Oct 23, 2014 at 02:30:08PM +0800, Anand Jain wrote:
introduce a global variable scan_done, which is set when scan is
done succssfully per thread. So that following calls to this function
will just re
btrfs_scan_lblikd() is called by most the device related command functions.
And btrfs_scan_lblkid() is most expensive function and it becomes more expensive
as number of devices in the system increase. Further some threads call this
function more than once for absolutely no extra benefit and the re
On Fri, Oct 31, 2014 at 12:33:43AM +0100, Toralf Förster wrote:
> On 10/30/2014 11:15 AM, Liu Bo wrote:
> > On Wed, Oct 29, 2014 at 05:56:33PM +0100, Toralf Förster wrote:
> >> > This is new in my eyes, or ? :
> > Also new to me, could you please turn on lock debug and try again?
> >
> > thanks,
>
Chris Murphy posted on Thu, 30 Oct 2014 12:04:48 -0600 as excerpted:
>> Rob, That second drive was immediately put to use elsewhere. I figured
>> having only the metadata on that drive, it wouldn't matter. The data
>> stayed single and wasn't part of the second drive, only the metadata
>> was. I m
Addition:
I found some posts here about a general file system corruption in 3.17
and 3.17.1 - is this the cause?
Additionally I am using ro-snapshots - maybe this is the cause, too?
Anyway: Can I fix that or do I have to reinstall? Haven't touched the
filesystem, just did a scrub (found 0 errors).
Hi
I was using a btrfs RAID1 with two disks under Ubuntu 14.04, kernel
3.13 and btrfs-tools 3.14.1 for weeks without issues.
Now I updated to kernel 3.17.1 and btrfs-tools 3.17. After a reboot
everything looked fine and I started some tests. While running
duperemover (just scanning, not doing any
Hello,
I am looking for some clarification on TRIM / SSD maintenance.
The wiki [1] suggests periodic fstrim, but fstrim does not discard
unallocated blocks[2].
Which makes sense, given that mkfs issues a device wide trim, so they
shouldn't have data.
But it seems like both a balance, and a pendin
On 10/30/2014 11:15 AM, Liu Bo wrote:
> On Wed, Oct 29, 2014 at 05:56:33PM +0100, Toralf Förster wrote:
>> > This is new in my eyes, or ? :
> Also new to me, could you please turn on lock debug and try again?
>
> thanks,
> -liubo
you mean CONFIG_PROVE_LOCKING=y right ?
--
Toralf
pgp key: 0076 E9
Does the new Linux 3.17.2 kernel have sufficient patches to safely use
btrfs with subvolume snapshots and incremental send/receive? I ask
because 3.17.1 was released just before the btrfs patches for these
issues, so I have been waiting for 3.17.2. However, from reading the
kernel changelog, it app
Hi,
At https://btrfs.wiki.kernel.org/index.php/Quota_support it's said that "Using
btrfs subvolume delete will break qgroup unshared space usage". Does it mean
that if the qgroup associated with the subvolume is attached to another qgroup,
this other qgroup won't be able to correctly apply its
Our gluster boxes were spending lots of time in statfs because our fs'es are
huge. The problem is statfs loops through all of the block groups looking for
read only block groups, and when you have several terabytes worth of data that
ends up being a lot of block groups. Move the read only block g
Hi,
At https://btrfs.wiki.kernel.org/index.php/Quota_support it's said that "Using
btrfs subvolume delete will break qgroup unshared space usage". Does it mean
that if the qgroup associated with the subvolume is attached to another qgroup,
this other qgroup won't be able to correctly apply its
On Oct 30, 2014, at 7:30 AM, Zack Coffey wrote:
> Rob, That second drive was immediately put to use elsewhere. I figured having
> only the metadata on that drive, it wouldn't matter. The data stayed single
> and wasn't part of the second drive, only the metadata was. I must not be
> capable o
Reported at https://github.com/openSUSE/snapper/issues/128
Commit cdb9e22e292275237c added another rbtree file that defines
functions that libbtrfs uses.
Signed-off-by: David Sterba
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 9c
With commit patched out.
All devices in Place
uname -a
Linux engelserver 3.18.0-031800rc1-generic #201410192135 SMP Mon Oct
20 01:37:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@engelserver:/# btrfs --version
Btrfs v3.17-dirty
root@engelserver:/# btrfs fi show
Label: 'mythstorage' uuid: 9b4
On Thu, Oct 30, 2014 at 02:34:06PM +0800, Qu Wenruo wrote:
> The following commit changed the argument requirement for
> '--subvol-extents', which causes it to call arg_strtou64() on NULL,
> resulting a segfault.
> d34cbe76 btrfs-progs: check: do not require argument for --subvol-extents
That was
On Thu, Oct 30, 2014 at 10:26:07AM +0100, lu...@plaintext.sk wrote:
> Hi,
> I want to ask, if deduplicated file content will be cached in linux kernel
> just once for two deduplicated files.
>
> To explain in deep:
> - I use btrfs for whole system with few subvolumes with some compression on
>
On Thu, Oct 30, 2014 at 09:30:46AM -0400, Zack Coffey wrote:
> Rob, That second drive was immediately put to use elsewhere. I
> figured having only the metadata on that drive, it wouldn't matter.
> The data stayed single and wasn't part of the second drive, only the
> metadata was. I must not be ca
On Tue, Oct 21, 2014 at 03:42:13PM +0800, Qu Wenruo wrote:
> 'btrfs fi df' needs exactly one arguments as mount option,
> and due to the introduce of human readable options, some check is not
> valid now, the new optind can point to the ending NULL string.
>
> For example, you can run 'btrfs fi df
On Wed, Oct 15, 2014 at 08:51:09AM +0800, Anand Jain wrote:
> --- a/volumes.c
> +++ b/volumes.c
> @@ -30,6 +30,7 @@
> #include "print-tree.h"
> #include "volumes.h"
> #include "math.h"
> +#include "utils.h"
>
> struct stripe {
> struct btrfs_device *dev;
> @@ -1533,6 +1534,30 @@ btrfs_f
Hi Everyone,
I wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes ab
On Thu, Oct 23, 2014 at 02:30:08PM +0800, Anand Jain wrote:
> introduce a global variable scan_done, which is set when scan is
> done succssfully per thread. So that following calls to this function
> will just return success.
The rest is good, I'm a bit concerned about the global variable.
Rob, That second drive was immediately put to use elsewhere. I figured
having only the metadata on that drive, it wouldn't matter. The data
stayed single and wasn't part of the second drive, only the metadata
was. I must not be capable of understanding why that wouldn't work.
I thought all I w
On 2014-10-30 05:26, lu...@plaintext.sk wrote:
Hi,
I want to ask, if deduplicated file content will be cached in linux kernel just
once for two deduplicated files.
To explain in deep:
- I use btrfs for whole system with few subvolumes with some compression on
some subvolumes.
- I have two
On Wed, Oct 29, 2014 at 05:56:33PM +0100, Toralf Förster wrote:
> This is new in my eyes, or ? :
Also new to me, could you please turn on lock debug and try again?
thanks,
-liubo
>
> Oct 29 17:53:04 n22kvmclone kernel: INFO: trying to register non-static key.
> Oct 29 17:53:04 n22kvmclone kernel
On Thu, Oct 30, 2014 at 11:46:18AM +0800, Qu Wenruo wrote:
>
> Original Message
> Subject: Re: [PATCH] btrfs: Enhance btrfs chunk allocation algorithm
> to reduce ENOSPC caused by unbalanced data/metadata allocation.
> From: Qu Wenruo
> To: bo.li@oracle.com
> Date: 2014年10月3
Hi,
I want to ask, if deduplicated file content will be cached in linux kernel just
once for two deduplicated files.
To explain in deep:
- I use btrfs for whole system with few subvolumes with some compression on
some subvolumes.
- I have two directories with eclipse SDK with slightly differen
The following lockdep warning is triggered during xfstests:
[ 1702.980872] =
[ 1702.981181] [ INFO: possible irq lock inversion dependency detected ]
[ 1702.981482] 3.18.0-rc1 #27 Not tainted
[ 1702.981781] ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Merillat schreef op 30-10-14 04:17:
> It's specifically BTRFS related, I was able to reproduce it on a bare
> drive (no lvm, no md, no bcache). It's not bad RAM, I was able to
> reproduce it on multiple machines running either 3.17 or late RCs.
37 matches
Mail list logo
