Helmut Hullen hul...@t-online.de schrieb:
If I want to manage a complete disk with btrfs, what's the Best
Practice? Would it be best to create the btrfs filesystem on
/dev/sdb, or would it be better to create just one partition from
start to end and then do mkfs.btrfs /dev/sdb1?
Would the
sctx is removed from the argument of the function that
doesn't use sctx.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/send.c | 189 +++-
1 file changed, 90 insertions(+), 99 deletions(-)
diff --git a/fs/btrfs/send.c
In the find_parent_nodes(), if read_tree_block() fails, we can
not return directly, we should free some allocated memory otherwise
memory leak happens.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
---
Since Chris has already setup his pull, we'd like to send
another patch.
---
In replace_path(), if read_tree_block() fails, we cannot return
directly, we should free some allocated memory otherwise memory
leak happens.
Similar to Wang's Btrfs: fix possible memory leak in the
find_parent_nodes() patch, the current commit fixes an issue that
is related to the Btrfs: fix all
On Wed, May 08, 2013 at 02:24 (+0200), Kai Krakow wrote:
Kai Krakow hurikhan77+bt...@gmail.com schrieb:
I can reliably reproduce it from two different approaches. I'd like to
only apply the commits fixing it. Can you name them here?
In git log order:
6ced2666 Btrfs: separate sequence
On 05/08/2013 12:31 AM, Kai Krakow wrote:
Helmut Hullen hul...@t-online.de schrieb:
If I want to manage a complete disk with btrfs, what's the Best
Practice? Would it be best to create the btrfs filesystem on
/dev/sdb, or would it be better to create just one partition from
start to end and
I'm sorry, theres no excuse for this sort of work. We need to use
root-leafsize since eb may be NULL. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/disk-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
I noticed a slight problem with btrfs-image, since it was building a chunk tree
by setting the physical offset of the stripes to the same as the logical offset
it created this problem where the super block was now mapped into the file
system differently than it was before. This isn't a huge deal
This catches block groups that are too large to properly cache. We deal with
this case fine, so the warning just confuses users. Remove the warning.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/free-space-cache.c |4 +---
1 files changed, 1 insertions(+), 3
On Wed, May 08, 2013 at 11:34:40AM -0600, Alexander Skwar wrote:
Hello Josef
Did you have a chance to look at that image? Did you find anything?
Or should I simply create a new filesystem and forget about the issue?
So the file system isn't corrupt, you just got a giant block group for
Hi guys,
Just to absolutely sure I am doing the right thing here I wanted to
ask you a question about system chunk duplication.
I performed the following command on my converted root volume to
enable metadata duplication:
root@host:~# btrfs balance start -mconvert=dup /
Done, had to relocate 1
Hi guys,
Just to absolutely sure I am doing the right thing here I wanted to
ask you a question about system chunk duplication.
I performed the following command on my converted root volume to
enable metadata duplication:
root@host:~# btrfs balance start -mconvert=dup /
Done, had to relocate 1
HI, all
I saw that bcache will be merged into kernel upstream soon, so i
want to know if btrfs hot relocation support is still meanful, if no,
i will not continue to work on it. can anyone let me know this?
thanks.
On Mon, May 6, 2013 at 4:53 PM, zwu.ker...@gmail.com wrote:
From: Zhi Yong
the -k option was missing from the usage() output and was present
only in the man page synopsis. Say a few more words about it.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
diff --git a/blktrace.c b/blktrace.c
index 89c..4e96573 100644
--- a/blktrace.c
+++ b/blktrace.c
@@ -450,6
On 5/8/13 8:33 PM, Eric Sandeen wrote:
the -k option was missing from the usage() output and was present
only in the man page synopsis. Say a few more words about it.
Gah, sorry. email address auto-fill bit me. :(
Signed-off-by: Eric Sandeen sand...@redhat.com
---
diff --git
15 matches
Mail list logo
