I am sorry that this has missed my eyes.
There is a regression in this patch and most
the commands are failing.
---
# btrfs fi df /btrfs
ERROR: couldn't get space info on '/btrfs' - Bad file descriptor
---
+if (fd 0)
+fd = -3;
+if (dirstream)
+
After calling opendir() successfully, closedir() should be
also called to free memory. Otherwise, memory leak happens.
Signed-off-by: Anand Jain anand.j...@oracle.com
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
Reviewed-by: Anand Jain anand.j...@oracle.com
---
utils.c |6 --
1
Jérôme Carretero posted on Sat, 13 Jul 2013 12:14:04 -0400 as excerpted:
- `btrfsck` was crashing because the code would progress even if fs_root
was null... fixed with this patch:
AFAIK (based on what I've seen go by on the list, tho I'm not technical
enough to actually make sense of the
I need some help as may have lost some number of files on a btrfs raid
1 volume. I'm not quite sure what happend which, I know, only adds to
the problem.
On my computer #1 I had only a month or so ago installed Fedora 19
Beta and at the time of install chose BTRFS, raid 1. Recently one of
the
On Sun, Jul 14, 2013 at 01:43:41PM +, Dave Barnum wrote:
I need some help as may have lost some number of files on a btrfs raid
1 volume. I'm not quite sure what happend which, I know, only adds to
the problem.
On my computer #1 I had only a month or so ago installed Fedora 19
Beta and
Thanks for your reply. I have tried -o degraded and recover but I
keep getting the error messages above in dmesg such as: btrfs: failed
to read chunk root on sdc2
On Sun, Jul 14, 2013 at 1:49 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jul 14, 2013 at 01:43:41PM +, Dave Barnum wrote:
Hello Anand and David,
I use the tool valgrind to whether there exists memory leak:
valgrind --tool=memcheck --trace-origins=yes --leak-chek=full btrfs sub list
/mnt
There still exists memory leak related to open_file_or_dir() (After applying
this patch).
I guess it is because we should
Hello,
You call pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
Miao implement chunk tree recover function, you can try it with like.
btrfs chunk-recover /dev
Maybe this can help you.
Thanks,
Wang
I need some help as may have lost some number of
From: Wang Shilong wangsl.f...@cn.fujitsu.com
Listing subvolumes and getting default subvol in the filesystem don't need a
subv path,Any valid path related to Btrfs filesystem is ok to finish the work.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
cmds-subvolume.c | 23
On 14/07/2013 21:58, Wang Shilong wrote:
Hello Anand and David,
I use the tool valgrind to whether there exists memory leak:
valgrind --tool=memcheck --trace-origins=yes --leak-chek=full btrfs sub
list /mnt
There still exists memory leak related to open_file_or_dir() (After applying
Can one btrfs filesystem handle different RAID levels e.g. for different
subvolumes? If so, how does deduplication with bedup
(https://github.com/g2p/bedup) across them work?
(It has been asked already on the Net
On 14/07/2013 21:58, Wang Shilong wrote:
Hello Anand and David,
I use the tool valgrind to whether there exists memory leak:
valgrind --tool=memcheck --trace-origins=yes --leak-chek=full btrfs sub
list /mnt
There still exists memory leak related to open_file_or_dir() (After
On Sun, Jul 14, 2013 at 04:50:35PM +0200, Adam Ryczkowski wrote:
Can one btrfs filesystem handle different RAID levels e.g. for
different subvolumes? If so, how does deduplication with bedup
(https://github.com/g2p/bedup) across them work?
No, not yet.
It's planned at some point
On Jul 13, 2013, at 2:59 PM, Chris Murphy li...@colorremedies.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=984236
kernel-3.10.0-1.fc20.x86_64
Should it be possible to mkfs.btrfs on a virtual LV backed by LVM thinp? I
can successfully create an XFS fs on the same virtual
Hi,
On Thu, Jul 4, 2013 at 10:52 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi David,
On Thu, Jul 4, 2013 at 8:03 PM, David Sterba dste...@suse.cz wrote:
On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote:
@@ -7363,6 +7365,12 @@ int btrfs_drop_snapshot(struct btrfs_root
On Fedora 19 with all updates, when I mkfs.btrfs and then mount the volume, I'm
getting this in dmesg:
[ 280.534868] Btrfs loaded
[ 280.581799] device fsid 94ed05cb-89a9-4d6b-a1e2-5312687b59f5 devid 1 transid
4 /dev/mapper/vg1-brick1
[ 280.590140] btrfs: super block crcs don't match, older
On Sun, Jul 14, 2013 at 12:11:04PM -0600, Chris Murphy wrote:
On Fedora 19 with all updates, when I mkfs.btrfs and then mount the volume,
I'm getting this in dmesg:
[ 280.534868] Btrfs loaded
[ 280.581799] device fsid 94ed05cb-89a9-4d6b-a1e2-5312687b59f5 devid 1
transid 4
On Jul 14, 2013, at 12:13 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jul 14, 2013 at 12:11:04PM -0600, Chris Murphy wrote:
On Fedora 19 with all updates, when I mkfs.btrfs and then mount the volume,
I'm getting this in dmesg:
[ 280.534868] Btrfs loaded
[ 280.581799] device fsid
On Jul 14, 2013, at 12:19 PM, Chris Murphy li...@colorremedies.com wrote:
On Jul 14, 2013, at 12:13 PM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jul 14, 2013 at 12:11:04PM -0600, Chris Murphy wrote:
On Fedora 19 with all updates, when I mkfs.btrfs and then mount the volume,
I'm
A complete fix for the memory leak caused by device_list_add()
is more complicated than initial idea and so sorry that I
have to pull back this patch as well.
The main reason-
There are uncoordinated scan for btrfs which would result
in doing the same thing multiple times.
I am sending a patch to fix the the memory leak. So
its fine if this patch just address the close issue.
This is more complicated than initially thought and it
isn't ready. As explained in the other thread.
Thanks, Anand
--
To unsubscribe from this list: send the line unsubscribe
Hello,
I'm trying to run the varmail personality in filebench, on a 50GB btrfs
filesystem. I am also starting the scrubber at the same time. I have
applied the latest patches for 3.8.13 (hoping to fix log tree issues).
Every time, after the scrubber completes, however, I get the following:
[
This is the rebased patch set, rebased on top of the
integration-20130710
Dropped
btrfs-progs: obtain used_bytes in BTRFS_IOC_FS_INFO ioctl
Introduced
btrfs-progs: move out print in cmd_df to another function
btrfs-progs: get string for the group profile and type
btrfs_scan_for_fsid uses only one argument run_ioctl out of 3
so remove the rest two of them
Signed-off-by: Anand Jain anand.j...@oracle.com
---
btrfs-find-root.c |2 +-
disk-io.c |2 +-
utils.c |5 ++---
utils.h |3 +--
4 files changed, 5
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c |2 +-
man/btrfs.8.in|8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 222e458..a1a8830 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@
the btrfs device scan usage didnt publish --all-devices
option so add it
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index 9e7328b..c94fcd5 100644
--- a/cmds-device.c
+++
This would help to reuse the function
v1-v2: removed static and updated .h file, in a preparation
work for the following patch
Signed-off-by: Anand Jain anand.j...@oracle.com
---
utils.c | 18 +-
utils.h |1 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff
the dev scan to find btrfs is performed at two locations
all most the same way one at filesystem show and another
at device scan. They both follow the same steps. This
patch does not alter anything except that it brings these
two same logic into the function scan_for_btrfs so that
we can play
Code can be well reused and this is the prepatory work
for the patch following this.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 83 ++--
ctree.h | 11 +++
2 files changed, 59 insertions(+), 35
when user runs command btrfs dev del the raid requisite error if any
goes to the /var/log/messages, its not good idea to clutter messages
with these user (knowledge) errors, further user don't have to review
the system messages to know problem with the cli it should be dropped
to the user as part
As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user want to verify their last operation like,
labeling or device delete or add... etc.
This patch adds --kernel option to the 'filesystem show'
subcli, which will read from the kernel instead
Currently, btrsf fi show and btrfs dev scan uses
/proc/partitions (by default) (which gives priority
to dm-x over sdy paths) and with --all-devices it
will scan /dev only (where it skips links under /dev/mapper).
However using /dev/mapper paths are in common practice
with mount, fstab, and lvm,
This is a prepatory work for the following btrfs fi show command
fixes. So that we have a function get_df to get the fs sizes.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-filesystem.c | 96 +++--
1 files changed, 56 insertions(+), 40
close_all_devices() is declared once in disk-io.c and again
in btrfs-find-root.c I see no reasons or is there any ?
This patch will fix it.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
btrfs-find-root.c | 17 +
disk-io.c |3 +--
disk-io.h |1 +
3
trivial: cmds-replace.c contains long lines fix it
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-replace.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/cmds-replace.c b/cmds-replace.c
index 6397bb5..c68986a 100644
--- a/cmds-replace.c
+++
Anand Jain (2):
btrfs-progs: fix the long lines
btrfs-progs: close_all_devices() declared in multiple files
btrfs-find-root.c | 17 +
cmds-replace.c| 17 ++---
disk-io.c |3 +--
disk-io.h |1 +
4 files changed, 13 insertions(+), 25
36 matches
Mail list logo
