headers
Laurent Humblet | 22 May 2013 15:22
Picon

Top shows brtfs-cache-1 and brtfs-endio-met while the hard drives seem busy

Hi,

I have setup about a year ago a BTRFS RAID 1 filesystem on two 2TB
Western Digital WD20EARS hard drives and I have created subvolumes
that I mount regularly as I need them.  I put mostly music, videos and
various files on them as well as some Git bare repositories for my
work files but for the last couple of weeks, there seems to be some
activity happening on the drives for a few minutes and the following
processes are showing up while this happens: brtfs-cache-1 and
brtfs-endio-met.  It seems that brtfs-cache-1 is more 'busy' than
brtfs-endio-met but after a while everything seems fine again.

Is there anything I should worry about?  I will soon do a full backup
on ext4 just to make sure I don't loose anything but is there any
checks I can run on the drives to make sure everything is fine both on
a hardware standpoint and on a data integrity standoint?

Thank you for your help,
All the best,
Laurent
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Liu Bo | 22 May 2013 14:07
Picon
Favicon

[PATCH 2/2] Btrfs: check if leaf's parent exists before pushing items around

During splitting a leaf, pushing items around to hopefully get some space only
works when we have a parent, ie. we have at least one sibling leaf.

Signed-off-by: Liu Bo <bo.li.liu <at> oracle.com>
---
 fs/btrfs/ctree.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index c07b6ea..f4654f8 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
 <at>  <at>  -3986,7 +3986,7  <at>  <at>  static noinline int split_leaf(struct btrfs_trans_handle *trans,
 		return -EOVERFLOW;

 	/* first try to make some room by pushing left and right */
-	if (data_size) {
+	if (data_size && path->nodes[1]) {
 		wret = push_leaf_right(trans, root, path, data_size,
 				       data_size, 0, 0);
 		if (wret < 0)
--

-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liu Bo | 22 May 2013 14:06
Picon
Favicon

[PATCH 1/2] Btrfs: dont do log_removal in insert_new_root

As for splitting a leaf, root is just the leaf, and tree mod log does not apply
on leaf, so in this case, we don't do log_removal.

As for splitting a node, the old root is kept as a normal node and we have nicely
put records in tree mod log for moving keys and items, so in this case we don't do
that either.

As above, insert_new_root can get rid of log_removal.

Signed-off-by: Liu Bo <bo.li.liu <at> oracle.com>
---
 fs/btrfs/ctree.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 02fae7f..c07b6ea 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
 <at>  <at>  -3143,7 +3143,7  <at>  <at>  static int balance_node_right(struct btrfs_trans_handle *trans,
  */
 static noinline int insert_new_root(struct btrfs_trans_handle *trans,
 			   struct btrfs_root *root,
-			   struct btrfs_path *path, int level, int log_removal)
+			   struct btrfs_path *path, int level)
 {
 	u64 lower_gen;
 	struct extent_buffer *lower;
 <at>  <at>  -3194,7 +3194,7  <at>  <at>  static noinline int insert_new_root(struct btrfs_trans_handle *trans,
 	btrfs_mark_buffer_dirty(c);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Lyakas | 22 May 2013 12:37
Favicon

Re: [PATCH] Btrfs: clear received_uuid field for new writable snapshots

Hi Stephan,
I fully understand the first part of your fix, and I believe it's
quite critical. Indeed, a writable snapshot should have no evidence
that it has an ancestor that was once "received".

Can you pls let me know that I understand the second part of your fix.
In btrfs-progs the following code in tree_search() would have
prevented us from mistakenly selecting such snapshot as a parent for
"receive":
        if (type == subvol_search_by_received_uuid) {
            entry = rb_entry(n, struct subvol_info,
                    rb_received_node);
            comp = memcmp(entry->received_uuid, uuid,
                    BTRFS_UUID_SIZE);
            if (!comp) {
                if (entry->stransid < stransid)
                    comp = -1;
                else if (entry->stransid > stransid)
                    comp = 1;
                else
                    comp = 0;
            }
The code checks both received_uuid (which would have been wrongly
equal to what we need), but also the stransid (which was the ctransid
on the send side), which would have been zero, so it wouldn't match.

Now after your fix, the stransid field becomes not needed, correct?
Because if we have a valid received_uuid, this means that either we
are the "received" snapshot, or our whole chain of ancestors are
read-only, and eventually there was an ancestor that was "received".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Holger Fischer | 22 May 2013 07:08
Picon

btrfs-tools: debian/patches/09-unaligned-memaccess.patch

Dear BTRFS-Community,
attached is a patch that probably could be applied upstream:
It is ... Fixing unaligned memory accesses ...
Details to this patch could be read under
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656955

I rechecked against latest git.
As far as I can see, it's not applied yet.

Best Regards
Holger Fischer
Attachment (09-unaligned-memaccess.patch): text/x-diff, 2342 bytes
Permalink | Reply | 0 comments |
headers
Qu Wenruo | 22 May 2013 02:18
Favicon

[PATCH 1/2] btrfs-progs: Add block group check funtion.

From: Cheng Yang <chenyang.fnst <at> cn.fujitsu.com>

This patch adds the function to check correspondence
between block group, chunk and device extent.

Signed-off-by: Cheng Yang <chenyang.fnst <at> cn.fujitsu.com>
Signed-off-by: Wang Shilong <wangsl-fnst <at> cn.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo <at> cn.fujitsu.com>
---
 Makefile           |   4 +-
 cmds-check.c       | 517 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 dev-extent-cache.c | 187 +++++++++++++++++++
 dev-extent-cache.h |  60 +++++++
 extent-cache.h     |   4 +-
 5 files changed, 762 insertions(+), 10 deletions(-)
 create mode 100644 dev-extent-cache.c
 create mode 100644 dev-extent-cache.h

diff --git a/Makefile b/Makefile
index da7438e..92c5850 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -6,7 +6,7  <at>  <at>  CFLAGS = -g -O1
 objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
 	  root-tree.o dir-item.o file-item.o inode-item.o inode-map.o \
 	  extent-cache.o extent_io.o volumes.o utils.o repair.o \
-	  qgroup.o raid6.o free-space-cache.o
+	  qgroup.o raid6.o free-space-cache.o dev-extent-cache.o
 cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
 	       cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Fasheh | 21 May 2013 20:28
Picon

[PATCH 0/4] btrfs: offline dedupe v1

Hi,

The following series of patches implements in btrfs an ioctl to do
offline deduplication of file extents.

To be clear, "offline" in this sense means that the file system is
mounted and running, but the dedupe is not done during file writes,
but after the fact when some userspace software initiates a dedupe.

The primary patch is loosely based off of one sent by Josef Bacik back
in January, 2011.

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/8508

I've made significant updates and changes from the original. In
particular the structure passed is more fleshed out, this series has a
high degree of code sharing between itself and the clone code, and the
locking has been updated.

The ioctl accepts a struct:

struct btrfs_ioctl_same_args {
	__u64 logical_offset;	/* in - start of extent in source */
	__u64 length;		/* in - length of extent */
	__u16 dest_count;	/* in - total elements in info array */
	__u16 reserved1;
	__u32 reserved2;
	struct btrfs_ioctl_same_extent_info info[0];
};
(Continue reading)

Permalink | Reply | 4 comments |
headers
George Mitchell | 21 May 2013 16:26
Favicon

Re: Virtual Device Support

In my case, I am backing up a system spanning five drives formatted 
btrfs, on a separate drive containing a separate backup volume and 
multiple complete backups, each from a different point in time.  This 
gives me protection from filesystem corruption, since the backups are on 
a separate volume, also protection from accidental deletion and other 
such issues by having backups spread over time going back as far as 
three months.  It also makes things very simple since I can just mount 
one of these backup subvolumes in place of the original and immediately 
be up and running.  Of course, all btrfs volumes could die at once as a 
result of some obscure problem such as a poison update or something like 
that, and that is why I keep a constantly updated JFS (and period 
backups to bluray) copy on hand.  I realize this is not foolproof, and 
actually plan to extend it further.  But huge drives are terribly 
inexpensive right now and this is one way I can take advantage of that.  
Of course I could have done this using multiple partitions, and I may 
one day regret not doing it that way for the very reasons you point out. 
However, I believe that I am sufficiently protected at this point to 
take the risk.  I really figure that if something were to corrupt both 
my main system AND the backup volume at the same time, it would probably 
knock out separate partitions as well. But ... perhaps not.  But I am 
indeed aware that one filesystem corruption could knock out all of those 
backups in one sweep.  As for the umount issue, it is ridiculously easy 
to script around, it just seems like somebody, either on the util-linux 
side, or on the btrfs side, could provide a more elegant solution, but 
it seems to fly in the face of entrenched ideologies on both sides. 
Fortunately, my only real problem that I can't script around is the boot 
issue and that is hopefully, just a matter of time before it gets 
fixed.  Thanks for your thoughts,  George

On 05/21/2013 01:16 AM, Michael Johnson - MJ wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matteo Fortini | 21 May 2013 13:53
Picon

Regression in kernel v3.9.3

Hi,
I just built and installed kernel v3.9.3 (was using v3.9.0 before) and
if I do a git fetch on a quite small (<1MB) directory, the system
starts thrashing and I can't even kill -9 git.
It's a btrfs partition with no fancy mount options (just relatime) on
a core i7 with 8GB RAM, Debian testing.

Please tell me if there's any test I can do to help.

Thank you
Matteo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Joeri Vanthienen | 21 May 2013 10:37
Picon

panic BTRFS error (device sdp) in __btrfs_inc_extent_ref:1935: Object already exists [Linux 3.8.4]

Hi all,

I tried to replace a failed device in a btrfs filesystem on Linux kernel 3.8.4.
After adding a new harddisk (/dev/sdf) to the btrfs pool and removing
the failed device with "btrfs device delete missing /btrfs" the server
panicked.
We can still mount the filesystem in degraded mode, what are the
options to resolve this :) ?

SANOS1:~ # btrfs fi show
Label: 'firstpool'  uuid: 517e8cfa-4275-4589-8da4-6a46ad613daa
        Total devices 15 FS bytes used 2.68TB
        devid   14 size 931.51GB used 394.87GB path /dev/sdp
        devid   13 size 931.51GB used 394.87GB path /dev/sdo
        devid   12 size 931.51GB used 394.87GB path /dev/sdn
        devid   11 size 931.51GB used 394.87GB path /dev/sdm
        devid   10 size 931.51GB used 394.87GB path /dev/sdl
        devid    9 size 931.51GB used 394.87GB path /dev/sdk
        devid    8 size 931.51GB used 394.87GB path /dev/sdj
        devid    7 size 931.51GB used 394.87GB path /dev/sdi
        devid    6 size 931.51GB used 394.87GB path /dev/sdh
        devid   16 size 931.51GB used 373.29GB path /dev/sdf
        devid    5 size 931.51GB used 394.87GB path /dev/sdg
        devid   15 size 931.51GB used 394.87GB path /dev/sde
        devid    2 size 931.51GB used 394.87GB path /dev/sdd
        devid    1 size 931.51GB used 394.87GB path /dev/sdc
        *** Some devices missing

May 20 22:54:00 SANOS1 kernel: btrfs: found 3289 extents
May 20 22:54:07 SANOS1 kernel: ------------[ cut here ]------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wei Yongjun | 21 May 2013 04:39
Picon

[PATCH -next] Btrfs: return error code in btrfs_check_trunc_cache_free_space()

From: Wei Yongjun <yongjun_wei <at> trendmicro.com.cn>

Fix to return error code instead always return 0 from function
btrfs_check_trunc_cache_free_space().
Introduced by commit 7b61cd92242542944fc27024900c495a6a7b3396
(Btrfs: don't use global block reservation for inode cache truncation)

Signed-off-by: Wei Yongjun <yongjun_wei <at> trendmicro.com.cn>
---
 fs/btrfs/free-space-cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index e530096..73577f4 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
 <at>  <at>  -213,7 +213,7  <at>  <at>  int btrfs_check_trunc_cache_free_space(struct btrfs_root *root,
 	else
 		ret = 0;
 	spin_unlock(&rsv->lock);
-	return 0;
+	return ret;
 }

 int btrfs_truncate_free_space_cache(struct btrfs_root *root,

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |

Gmane