The current code returns from the function when the call to ioctl
fails. This may leak cache_dir_name and cache_full_name. Fix it.
Signed-off-by: chandan chan...@linux.vnet.ibm.com
---
btrfs-list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs-list.c b/btrfs-list.c
From: Wang Shilong wangsl-f...@cn.fujitsu.com
You might want to list qgroups in order of some items, such as 'qgroupid',
'rfer'
and so on, you can use '--sort'. Now you can sort the qgroups by 'qgroupid',
'rfer','excl','max_rfer' and 'max_excl'.
For example:
If you want to list qgroups
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The current show_qgroups() just shows a little information, and it is hard to
add some functions which the users need in the future, so i restructure it, make
it easy to add new functions.
In order to improve the scalability of show_qgroups(), i add
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This patch introduces '-f' option which can help you filter the qgroups
by the path name, you may use it like:
btrfs qgroup show -f path
For example:
qgroupid(2/0)
/ \
You can use it like:
btrfs qgroup show --block-size=m mnt
Here, block size supports k/K/m/M/g/G/t/T/p/P/e/E.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
cmds-qgroup.c | 16 +---
qgroup.c | 78 ---
This is a short cut for people who don't want to use '--block-size',it
will print sizes in human readable format.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
cmds-qgroup.c | 17 +---
qgroup.c | 62 +++
Sometimes, we need to catch length of snprintf() in pretty_size_snprintf().
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
utils.c | 9 +
utils.h | 4 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/utils.c b/utils.c
index 4ed7405..7b42022 100644
---
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This patch introduce '-e' option to print max exclusive size of qgroups.
You may use it like this:
btrfs qgroup -e path
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This patch introduces '-c' option to print the ID of the child qgroups.
You may use it like:
btrfs qgroup show -c path
For Example:
qgroupid(2/0)
/ \
/ \
/
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This patch introduces '-p' option to print the ID of the parent qgroups.
You may use it like:
btrfs qgroup show -p path
For Example:
qgroupid(2/0)
/ \
/ \
/
hi,
i've got the same problem kernel BUG at fs/btrfs/relocation.c:1060.
this was solved by patching the kernel with following patch
https://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/commit/?id=b6c60c8018c4e9beb2f83fc82c09f9d033766571
i've also found, that this patch is NOT
Following this patch the idea is to use lblkid to scan
for the btrfs disks by default which means we don't
use BTRFS_SCAN_PROC any more.
Firstly, i would like to know if we will get any different results between
scanning
/proc/partions and using lbkid.
I take blkid as a more authoritative
Alfredo Esteban posted on Sun, 06 Oct 2013 13:10:49 +0200 as excerpted:
I'm getting an error when trying to delete a device from a raid1 (data
and metadata mirrored).
btrfs filesystem show
failed to read /dev/sr0
Label: none uuid: 78b5162b-489e-4de1-a989-a47b91adef50
Total devices 2
Replace progresses strictly from lower to higher offsets, and the
progress is tracked in chunks, by storing the physical offset of the
dev_extent which is being copied in the cursor_left field of
btrfs_dev_replace_item. When we are done copying the chunk,
left_cursor is updated to point one byte
Structures of the types tree_mod_elem and qgroup_update are allocated
during transaction commit but were not being released if the call to
btrfs_run_delayed_items() returned an error.
Stack trace reported by kmemleak:
unreferenced object 0x880679f0b398 (size 128):
comm umount, pid 21508,
Hi,
I have added 2x2Tb to my existing 2x2Tb raid 1 btrfs filesystem and
then ran a balance:
# btrfs filesystem show
Total devices 4 FS bytes used 1.74TB
devid3 size 1.82TB used 0.00 path /dev/sdd
devid4 size 1.82TB used 0.00 path /dev/sde
devid2 size
On Mon, Oct 07, 2013 at 01:45:29PM +0200, Laurent Humblet wrote:
I have added 2x2Tb to my existing 2x2Tb raid 1 btrfs filesystem and
then ran a balance:
# btrfs filesystem show
Total devices 4 FS bytes used 1.74TB
devid3 size 1.82TB used 0.00 path /dev/sdd
devid
Hugo Mills posted on Mon, 07 Oct 2013 13:06:23 +0100 as excerpted:
On Mon, Oct 07, 2013 at 01:45:29PM +0200, Laurent Humblet wrote:
I have added 2x2Tb to my existing 2x2Tb raid 1 btrfs filesystem and
then ran a balance:
# btrfs filesystem show
Total devices 4 FS bytes used 1.74TB
The transactions should be cleaning up their reservations on failure, this just
causes us to have warnings on unmount because we go negative by free'ing
reservations that have already been free'ed. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/disk-io.c | 2 --
1 file
Any clues or educated comment please?
Can the corrupt directory tree safely be ignored and left in place? Or
might that cause everything to fall over in a big heap as soon as I try
to write data again?
Could these other tricks work-around or fix the corrupt tree:
Run a scrub?
Make a snapshot
On Mon, 30 Sep 2013 14:58:02 -0700, Zach Brown wrote:
I discovered one minor bug in BTRFS filesystem.
You sure did.
ERROR: ioctl(BTRFS_IOC_GET_DEV_STATS) on /dev/sde failed: No such device
But this is not true ... all specified devices exist and are members
of btrfs filesystem. In dmesg
On Oct 7, 2013, at 4:38 AM, Duncan 1i5t5.dun...@cox.net wrote:
Since your btrfs in raid1 mode has two devices currently, you won't be
able to delete one of them as-is. You will need to ADD a device first
(bringing the total to three devices), optionally do a balance, and THEN
delete the
alloc_extent_buffer() uses radix_tree_lookup() when radix_tree_insert()
fails with EEXIST. That part of the code is very similar to the code in
find_extent_buffer(). This patch replaces radix_tree_lookup() and
surrounding code in alloc_extent_buffer() with find_extent_buffer().
Note that
On Oct 7, 2013, at 9:44 AM, Chris Murphy li...@colorremedies.com wrote:
On Oct 7, 2013, at 4:38 AM, Duncan 1i5t5.dun...@cox.net wrote:
Since your btrfs in raid1 mode has two devices currently, you won't be
able to delete one of them as-is. You will need to ADD a device first
(bringing
On Oct 7, 2013, at 8:56 AM, Martin m_bt...@ml1.co.uk wrote:
Or try mount -o recovery,noatime again?
Because of this: free space inode generation (0) did not match free space cache
generation (1607)
Try mount option clear_cache. You could then use iotop to make sure the
btrfs-freespace
I think the wiki has descriptions for check_int and check_int_data reversed:
check_int (since 3.3)
Switch on integrity checker for data and metadata (if compiled in)
check_int_data (since 3.3)
Switch on integrity checker for data (if compiled in)
On error we will wait and free the tree log at unmount without a transaction.
This means that the actual freeing of the blocks doesn't happen which means we
complain about space leaks on unmount. So to fix this just skip the transaction
specific cleanup part of the tree log free'ing if we don't
If we abort a transaction we will do the tree log cleanup at unmount, but this
happens after we free up the block groups. This makes all the leak detection
warnings go off because we think we've leaked space but in reality we just
haven't cleaned it up yet. So instead do the block group cleanup
While trying to track down a reserved space leak I noticed a few places where we
won't properly clean up reserved space if we have an error, this patch fixes
those up. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c | 21 +++--
fs/btrfs/inode.c
In trying to track down where we were leaking reserved space I noticed our
reserve extent tracepoints are a little off. First we were saying that the
reserved space had been alloced in btrfs_reserve_extent, which isn't the case,
this needs to be triggered when we actually allocate the space when
The btrfs_insert_empty_item() function doesn't modify its
key argument.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
fs/btrfs/tree-log.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 964c583..2a1f690
On Sat, Oct 05, 2013 at 04:52:18PM -0700, Greg KH wrote:
On Fri, Sep 20, 2013 at 09:53:02AM -0700, Greg KH wrote:
On Fri, Sep 20, 2013 at 06:34:39PM +0200, David Sterba wrote:
Hi stable team,
please add the following commits to 3.11 tree, they fix user visible
problems,
were
btrfs-corrupt-block added some untested path allocations. These showed
up in static analysis when they pass their path to btrfs_search_slot()
which unconditionally dereferences the path.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-corrupt-block.c | 10 --
1 file changed, 8
Check for fopen() failure. This shows up in static analysis as a
possible null pointer derference.
Signed-off-by: Zach Brown z...@redhat.com
---
cmds-send.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/cmds-send.c b/cmds-send.c
index 374d040..5f6ff86 100644
--- a/cmds-send.c
+++
Hi friends,
Eric imported a newer git snapshot of btrfs-progs into Red Hat's
universe which kicked off a static analysis run which found a bunch
of problems. This series is my attempt to fix the warnings that I
agreed were either real bugs or messy code to clean up.
This is against Dave's
Don't carry around dead code. If its needed again, it's only a few git
commands away. This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
cmds-check.c | 50 --
1 file changed, 50 deletions(-)
diff --git
This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
cmds-check.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index ebba58e..b6035d7 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -3228,13 +3228,13 @@ static
Presumably people missed these warnings because btrfs-fragments isn't
built by default.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-fragments.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/btrfs-fragments.c b/btrfs-fragments.c
index cedbc57..160429a 100644
---
find_collision() allocates name_len bytes for its sub array so the index
must be less than name_len. This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-image.c
This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-image.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/btrfs-image.c b/btrfs-image.c
index 03ad4e9..d10447f 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -1541,6 +1541,7 @@ next:
Stop iteration at the number of elements in the colors[] array when
initializing the elements. Rather than a magic number. This was found
by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-fragments.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
commit 4782e8ebdb583dfa3615f7b38dee729d34f62ec1 accidentally replaced
[0] with [-1]. Put it back. This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
send-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/send-test.c b/send-test.c
index
In principle, link_subvol() can be given an abitrary string as the name
of the saved subvolume. It copies it into a fixed-size stack buffer and
then uses it as dirent names without testing its length.
This limits its length to BTRFS_NAME_LEN. This was found by static
analsys.
Signed-off-by:
search_for_chunk_blocks() allocates a fixed-size buffer and then reads
arbitrary u32 sized buffers in to it. Instead let's fail if the item is
bigger than the buffer. This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-image.c | 14 +++---
1 file
On 10/7/13 4:43 PM, Zach Brown wrote:
commit 4782e8ebdb583dfa3615f7b38dee729d34f62ec1 accidentally replaced
[0] with [-1]. Put it back. This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
eeehhhyeah. Thanks for being charitable. ;)
Really, I have no idea how that
On Mon, Oct 07, 2013 at 09:20:44PM +0100, Filipe David Borba Manana wrote:
The btrfs_insert_empty_item() function doesn't modify its
key argument.
Looks reasonable to me.
Reviewed-by: Zach Brown z...@redhat.com
- z
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
Hello,
I'm hitting similar bug with the patch from Lui Bo.
But If I revert: 573aecafca1cf7a974231b759197a1aebcf39c2a,
Btrfs: actually limit the size of delalloc range) everything works fine.
Here are the 2 backtraces from my machines with 3.12-rc4:
http://imgur.com/sVkjGK6,mWUtzMV#0
On Mon, Oct 07, 2013 at 04:45:01PM -0500, Eric Sandeen wrote:
On 10/7/13 4:43 PM, Zach Brown wrote:
commit 4782e8ebdb583dfa3615f7b38dee729d34f62ec1 accidentally replaced
[0] with [-1]. Put it back. This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
On Mon, Oct 07, 2013 at 03:16:01PM -0400, Josef Bacik wrote:
If we abort a transaction we will do the tree log cleanup at unmount, but this
happens after we free up the block groups. This makes all the leak detection
warnings go off because we think we've leaked space but in reality we just
Originally, when executing btrfs balance right after
btrfs subvolume snaphot btrfs subvolume delete,
a kernel BUG arises.
This problem is caused by the patch:
[PATCH 1/2] Btrfs: fix for patch cleanup: don't check
the same thing twice
The commit id: 48475471728f060bfd2e686f592ef208d3ba8b7d
(in
On Tue, Oct 08, 2013 at 12:36:11AM +0200, Jan Killius wrote:
Hello,
I'm hitting similar bug with the patch from Lui Bo.
But If I revert: 573aecafca1cf7a974231b759197a1aebcf39c2a,
Btrfs: actually limit the size of delalloc range) everything works fine.
Here are the 2 backtraces from my
On Tue, Oct 08, 2013 at 12:36:11AM +0200, Jan Killius wrote:
Hello,
I'm hitting similar bug with the patch from Lui Bo.
But If I revert: 573aecafca1cf7a974231b759197a1aebcf39c2a,
Btrfs: actually limit the size of delalloc range) everything works fine.
Here are the 2 backtraces from my
for mounted btrfs filesystem this patch proposes to add
mount point and group profile to the filesystem show output.
this helps user to quickly understand short details of the
btrfs filesystem quickly.
end user using this new btrfs fi show would surely notice this
will reduce other commands
As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user wants to cross verify their operation like,
label or device delete or add... etc. so this
patch will read from the kernel ioctl if it finds
that disk is mounted.
v4:
rebase on
btrfs progs has to scan for the btrfs disks for two main reasons,
one to register them with the btrfs kernel (under btrfs dev scan)
2nd to report btrfs disks to the user (under btrfs fi show)
(there few more minor reasons like check_mounted etc..).
To facilitate the scan, in total we have the
On Monday 07 Oct 2013 2:43:01 PM you wrote:
This was found by static analysis.
Signed-off-by: Zach Brown z...@redhat.com
---
cmds-check.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index ebba58e..b6035d7 100644
---
56 matches
Mail list logo
