David Sterba | 3 Jul 18:51 2015
Picon

Re: [PATCH] Integer underflow in ctree.c

On Fri, Jun 19, 2015 at 11:31:16AM -0500, Sandino Araico Sánchez wrote:
> :btrfs check crashed while trying to fix my corrupted filesystem.
> 
> btrfs check --repair /dev/sdd3
> enabling repair mode
> Checking filesystem on /dev/sdd3
> UUID: 58222ebc-79ca-4dc4-891f-129aae342313
> checking extents
> bad key ordering 0 1
> bad block 3535142326272
> Errors found in extent allocation tree or chunk allocation
> Fixed 0 roots.
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> bad key ordering 0 1
> bad key ordering 0 1
> The following tree block(s) is corrupted in tree 814:
>         tree block bytenr: 3535142346752, level: 0, node key:
> (1270098042880, 168, 4096)
> Try to repair the btree for root 814
> Segmentation fault
> 
> What I found on the gdb backtrace:
> 
> (gdb) bt
> #0Â  0x00006fc5cb578411 in ?? ()
> #1Â  0x000009d5fe028bab in memmove_extent_buffer (dst=0x9d76942cf30,
> dst_offset=1586, src_offset=1619, len=141733920735) at extent_io.c:880
> #2Â  0x000009d5fe002e1b in btrfs_del_ptr (trans=0x9d7669ec990,
(Continue reading)

fdmanana | 3 Jul 09:48 2015

[PATCH] Btrfs: fix memory leak in the extent_same ioctl

From: Filipe Manana <fdmanana <at> suse.com>

We were allocating memory with memdup_user() but we were never releasing
that memory. This affected pretty much every call to the ioctl, whether
it deduplicated extents or not.

This issue was reported on IRC by Julian Taylor and on the mailing list
by Marcel Ritter, credit goes to them for finding the issue.

Reported-by: Julian Taylor (jtaylor <at> IRC)
Reported-by: Marcel Ritter <ritter.marcel <at> gmail.com>
Signed-off-by: Filipe Manana <fdmanana <at> suse.com>
---
 fs/btrfs/ioctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index c86b835..78e6a28 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
 <at>  <at>  -2958,7 +2958,7  <at>  <at>  out_unlock:
 static long btrfs_ioctl_file_extent_same(struct file *file,
 			struct btrfs_ioctl_same_args __user *argp)
 {
-	struct btrfs_ioctl_same_args *same;
+	struct btrfs_ioctl_same_args *same = NULL;
 	struct btrfs_ioctl_same_extent_info *info;
 	struct inode *src = file_inode(file);
 	u64 off;
 <at>  <at>  -2988,6 +2988,7  <at>  <at>  static long btrfs_ioctl_file_extent_same(struct file *file,
(Continue reading)

Marcel Ritter | 3 Jul 08:58 2015
Picon

linux 4.1 - memory leak (possibly dedup related)

Hi,

I've been running some btrfs tests (mainly duperemove related) with
linux kernel 4.1 for the last few days.

Now I noticed by accident (dying processes), that all my memory (128
GB!) is gone.
"Gone" meaning, there's no user space process allocating this memory.

Digging deeper I found the missing memory using slabtop (see output of
/proc/slabinfo is attached): Looks like I got a lot of kernel memory
allocated by kmalloc-1024 (memory leak?).
Given the fact that the test machine does little more than btrfs
testing I think this may be btrfs related.

I was running duperemove on a 1.5 TB volume around the time the first
"Out of memory" error were logged, so maybe the memory leak can be
found somewhere in this code path.

I'm still waiting for a scrub run to finish, after that I'll reboot
the machine and try to reproduce this behaviour with a fresh btrfs
filesystem.

Have there been any fixes concerning memory leaks since 4.1 release I could try?
Any other ideas how to track down this potential memory leak?

Bye,
   Marcel
(Continue reading)

Rich Rauenzahn | 3 Jul 07:32 2015
Picon

btrfs full, but not full, can't rebalance

Running on CentOS7 ... / got full, I removed the files, but it still
thinks it is full.  I've tried following the FAQ, even adding a
loopback device during the rebalance.

# btrfs fi show /
Label: 'centos7'  uuid: 35f0ce3f-0902-47a3-8ad8-86179d1f3e3a
        Total devices 2 FS bytes used 24.27GiB
        devid    1 size 111.11GiB used 111.05GiB path /dev/sdf3
        devid    2 size 111.11GiB used 111.05GiB path /dev/sdg3

# btrfs fi df /
Data, RAID1: total=107.02GiB, used=22.12GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=4.05GiB, used=2.15GiB
GlobalReserve, single: total=512.00MiB, used=0.00

# btrfs balance start -v -dusage=1 /
Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x2): balancing, usage=1
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail

# btrfs balance start -m /
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail

What can I do?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Qu Wenruo | 3 Jul 03:17 2015

[PATCH] btrfs: remove empty header file extent-tree.h

The empty file is introduced as an careless 'git add', remove it.

Reported-by: David Sterba <dsterba <at> suse.cz>
Signed-off-by: Qu Wenruo <quwenruo <at> cn.fujitsu.com>
---
 fs/btrfs/extent-tree.h | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 fs/btrfs/extent-tree.h

diff --git a/fs/btrfs/extent-tree.h b/fs/btrfs/extent-tree.h
deleted file mode 100644
index e69de29..0000000
--

-- 
2.4.4

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

Kyle Gates | 2 Jul 19:01 2015
Picon

possible enhancement: failing device converted to a seed device

I'll preface this with the fact that I'm just a user and am only posing a question for a possible enhancement
to btrfs.

I'm quite sure it isn't currently allowed but would it be possible to set a failing device as a seed instead of
kicking it out of a multi-device filesystem? This would make the failing device RO, while keeping the
filesystem as a whole RW thereby allowing the user additional protection when recovering/balancing. Is
this a feasible/realistic request?

Thanks,
Kyle  		 	   		  --
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

Christoph Anton Mitterer | 2 Jul 18:12 2015
Picon

strange corruptions found during btrfs check

Hi.

This is on a btrfs created and used with a 4.0 kernel.

Not much was done on it, apart from send/receive snapshots from another
btrfs (with -p).
Some of the older snapshots (that were used as parents before) have
been removed in the meantime).

Now a btrfs check gives this:
# btrfs check /dev/mapper/image
Checking filesystem on /dev/mapper/data-b
UUID: 250ddae1-7b37-4b22-89e9-4dc5886c810f
checking extents
ref mismatch on [468697088 16384] extent item 0, found 1
Backref 468697088 parent 4159 root 4159 not found in extent tree
backpointer mismatch on [468697088 16384]
owner ref check failed [468697088 16384]
ref mismatch on [1002373120 16384] extent item 0, found 1
Backref 1002373120 parent 4159 root 4159 not found in extent tree
backpointer mismatch on [1002373120 16384]
ref mismatch on [1013940224 16384] extent item 0, found 1
Backref 1013940224 parent 4159 root 4159 not found in extent tree
backpointer mismatch on [1013940224 16384]
ref mismatch on [525281738752 16384] extent item 0, found 1
Backref 525281738752 parent 4159 root 4159 not found in extent tree
backpointer mismatch on [525281738752 16384]
owner ref check failed [525281738752 16384]
ref mismatch on [525317095424 16384] extent item 0, found 1
Backref 525317095424 parent 4159 root 4159 not found in extent tree
(Continue reading)

Qu Wenruo | 2 Jul 08:52 2015

[PATCH 1/2] btrfs-progs: fsck:Add repair function for I_ERR_FILE_WRONG_NBYTES.

Some unknown kernel bug makes inode nbytes modification out of sync with
file extent update.

But it's quite easy to fix in btrfs-progs anyway.

So just fix it by adding a new function repair_inode_nbytes by using the
found_size in inode_record.

Reported-by: Christian <cdysthe <at> gmail.com>
Reported-by: Chris Murphy <lists <at> colorremedies.com>
Signed-off-by: Qu Wenruo <quwenruo <at> cn.fujitsu.com>
---
 cmds-check.c | 38 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/cmds-check.c b/cmds-check.c
index 778f141..dd2fce3 100644
--- a/cmds-check.c
+++ b/cmds-check.c
 <at>  <at>  -1918,6 +1918,39  <at>  <at>  static int repair_inode_orphan_item(struct btrfs_trans_handle *trans,
 	return ret;
 }

+static int repair_inode_nbytes(struct btrfs_trans_handle *trans,
+			       struct btrfs_root *root,
+			       struct btrfs_path *path,
+			       struct inode_record *rec)
+{
+	struct btrfs_inode_item *ei;
+	struct btrfs_key key;
(Continue reading)

Roel Niesen | 1 Jul 19:15 2015
Picon

urgent: disk space problem

Hello,

I'm using 8 2TB disk  in RAID10 for data and meta.
Zo a native usable spavce of 7.3TB is acceptable (logical).

I created 1 volume with all disk and mount them on /btrfs.

2 folders are created:
iscsi = containing iscsi volumes
samba= contiing folders for Samba.

When I do a du -h /btfs I use 4.8TB of disk, but btrfs is telling me the filesystem is full.

btrfs fi sh:
root <at> sanos1:~# btrfs fi sh
Label: none  uuid: f07e804e-c5a8-468c-8d84-5e3cc92991e9
        Total devices 8 FS bytes used 7.19TiB
        devid    1 size 1.82TiB used 1.82TiB path /dev/sdb
        devid    2 size 1.82TiB used 1.82TiB path /dev/sdc
        devid    3 size 1.82TiB used 1.82TiB path /dev/sdd
        devid    4 size 1.82TiB used 1.82TiB path /dev/sde
        devid    5 size 1.82TiB used 1.82TiB path /dev/sdf
        devid    6 size 1.82TiB used 1.82TiB path /dev/sdg
        devid    7 size 1.82TiB used 1.82TiB path /dev/sdh
        devid    8 size 1.82TiB used 1.82TiB path /dev/sdi

Btrfs v3.18.2

btrfs fi df /btrfs:
root <at> sanos1:~# btrfs fi df /btrfs
(Continue reading)

edt | 1 Jul 19:19 2015
Picon

send/receive broken with btrfs-progs 4.1?

Hi

My backups broke sometime after june 26th (about the time btrfs-progs 4.1 
came out).  I am using btrfs-progs from git and 4.1.1 + the 4.2 for-linux 
branch along with a few patches from the list.

The following is based on the wiki at: 
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

Here is a log of what is happening along with a few subvolume lists

---
btrfs subvolume snapshot -r /snap/homevol 
/snap/homevol/backup.2015-27-3_07-01_07:30
Create a readonly snapshot of '/snap/homevol' in 
'/snap/homevol/backup.2015-27-3_07-01_07:30'

btrfs send -ve /snap/homevol/backup.2015-27-3_07-01_07:30 | btrfs receive 
-v /backup/home
At subvol /snap/homevol/backup.2015-27-3_07-01_07:30
At subvol backup.2015-27-3_07-01_07:30
receiving subvol backup.2015-27-3_07-01_07:30 
uuid=cff4f305-6ef3-234e-ac6d-bdfd87d926d7, stransid=392551

BTRFS_IOC_SEND returned 0
joining genl thread
BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=cff4f305-6ef3-234e-ac6d-bdfd87d926d7, 
stransid=392551

btrfs subvol delete -c /snap/homevol/backup
(Continue reading)

Donald Pearson | 1 Jul 17:39 2015
Picon

Any hope of pool recovery?

Hello,

"darkling" was helping me on IRC for a while before he had to drop
off, thanks for the help darkling.

To pick up where we left off...
In summary, I have a 10 disk raid6 pool that I cannot mount.

btrfs fi show output is here ->  http://pastebin.com/aidGV20e
'tank' is the pool in question.

mounting fails with errors in dmesg with or without
recovery,degraded,ro options.

[  142.588443] BTRFS: device label tank devid 1 transid 14796 /dev/sdc
[  142.589646] BTRFS info (device sdc): enabling auto recovery
[  142.589658] BTRFS info (device sdc): allowing degraded mounts
[  142.589665] BTRFS info (device sdc): disk space caching is enabled
[  142.589669] BTRFS: has skinny extents
[  142.592199] BTRFS: failed to read chunk root on sdc
[  142.612988] BTRFS: open_ctree failed

What precipitated all this was horrible performance from the pool,
seeing that service times for /dev/sdg were ~ 3 seconds and smartctl
reported many sector issues with /dev/sdg.
I issued the commant btrfs device delete /dev/sdg  and then monitored
btrfs fi show but saw no change in allocated data to /dev/sdg for
several hours.
I then attempted wipefs -a /dev/sdg  but it was still listed in the
btrfs fi show.
(Continue reading)


Gmane