On 07/18/2011 12:53 PM, Wang Sheng-Hui wrote:
The patch is against 3.0-rc7 kernel.
From d22497ac8c5dd55a2ef9a47de5f2ddee55f8ec50 Mon Sep 17 00:00:00 2001
From: Wang Sheng-Huishh...@gmail.com
Date: Sun, 17 Jul 2011 21:45:01 -0500
Subject: [PATCH 3.0-rc7] btrfs: Update git repository links for
On 2011年07月18日 14:06, Wanlong Gao wrote:
On 07/18/2011 12:53 PM, Wang Sheng-Hui wrote:
The patch is against 3.0-rc7 kernel.
From d22497ac8c5dd55a2ef9a47de5f2ddee55f8ec50 Mon Sep 17 00:00:00 2001
From: Wang Sheng-Huishh...@gmail.com
Date: Sun, 17 Jul 2011 21:45:01 -0500
Subject: [PATCH
From c04da1655df6d75db834ddbd3a3b4a58a0d9a0c9 Mon Sep 17 00:00:00 2001
From: Wang Sheng-Hui shh...@gmail.com
Date: Mon, 18 Jul 2011 02:17:31 -0500
Subject: [PATCH] btrfs-progs-unstable: replace debug-tree to btrfs-debug-tree
in INSTALL
debug-tree doesn't exist after btrfs-progs installed.
Use
On 17.07.2011 16:01, Jan Schubert wrote:
Jan Schubert jan.schubert at gmx.li writes:
Please find some data and log below. Is there any chance to fix this?
After playing around (incl. deleting the log) I get the strong feeling
it has something todo with compression=lzo. Dunno why it started
2011-07-17 10:17:37 +0100, Stephane Chazelas:
2011-07-16 13:12:10 +0100, Stephane Chazelas:
Still on my btrfs-based backup system. I still see one BUG()
reached in btrfs-fixup per boot time, no memory exhaustion
anymore. There is now however something new: write performance
is down to a
Don't need to check the return value of __btrfs_add_inode_defrag(),
since it will always return 0.
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
---
fs/btrfs/file.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index
This is the next patch series for scrub userland tools.
Change log v1-v2:
- commands now reachable as btrfs scrub ... instead of btrfs filesystem
scrub ...
- ability to scrub a single device instead of a whole file system
- superfluous command line options removed
- resume is now a separate
- scrub commands added
- open_file_or_dir no longer static (needed by scrub.c)
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
Makefile |4 ++--
btrfs.c | 23 +++
btrfs_cmds.c |2 +-
btrfs_cmds.h |5 +
4 files changed, 31 insertions(+), 3
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
man/btrfs.8.in | 64 +++-
1 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index e1a6ad9..84a60cd 100644
--- a/man/btrfs.8.in
+++
new version of check_mounted() returning more information gathered while
searching. check_mounted() is now a wrapper for check_mounted_where(). the
new version is needed by scrub.c
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
utils.c | 29 ++---
utils.h |
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
scrub.c | 1666 +++
1 files changed, 1666 insertions(+), 0 deletions(-)
diff --git a/scrub.c b/scrub.c
new file mode 100644
index 000..9dca5f6
--- /dev/null
+++ b/scrub.c
@@
- scrub structs added
- ioctls for scrub
- BTRFS_FSID_SIZE moved
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
---
ctree.h |2 +-
ioctl.h | 54 +-
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/ctree.h b/ctree.h
On 07/17/2011 11:04 PM, liubo wrote:
On 07/16/2011 02:29 AM, Josef Bacik wrote:
Currently we reserve enough space to COW an entirely full btree for every
extent
we have reserved for an inode. This _sucks_, because you only need to COW
once,
and then everybody else is ok. Unfortunately we
On Tue, 2011-06-07 at 04:28 +0530, Nirbheek Chauhan wrote:
Every few minutes, (I guess) when applications do fsync (firefox,
xchat, vim, etc), all applications that use fsync() hang for several
seconds, and applications that use general IO suffer extreme
slowdowns. iotop shows various
The following series implements...
---
Goffredo Baroncelli (6):
Add info for the commands.
Add the header/footer/introduction of the man page.
helpextract: tool to extract the info for the help from the source.
Update the makefile for generating the man page.
Show
Currently we reserve enough space to COW an entirely full btree for every extent
we have reserved for an inode. This _sucks_, because you only need to COW once,
and then everybody else is ok. Unfortunately we don't know we'll all be able to
get into the same transaction so that's what we have
On 07/18/2011 02:11 PM, Josef Bacik wrote:
Currently we reserve enough space to COW an entirely full btree for every
extent
we have reserved for an inode. This _sucks_, because you only need to COW
once,
and then everybody else is ok. Unfortunately we don't know we'll all be able
to
On 06/06/2011 06:58 PM, Nirbheek Chauhan wrote:
Hello list,
I've been using btrfs on my personal machines for about two years now,
and on this machine for about a year with absolutely no problems.
Infact, it has held up better than ext4 with regards to reliability.
However, recently,
2011-07-18 11:39:12 +0100, Stephane Chazelas:
2011-07-17 10:17:37 +0100, Stephane Chazelas:
2011-07-16 13:12:10 +0100, Stephane Chazelas:
Still on my btrfs-based backup system. I still see one BUG()
reached in btrfs-fixup per boot time, no memory exhaustion
anymore. There is now
Hi Tsutomu,
Thanks for the review, it is appreciated!
On Fri, Jul 15, 2011 at 11:43:52AM +0900, Tsutomu Itoh wrote:
@@ -1037,7 +1037,8 @@ static noinline int find_next_chunk(struct btrfs_root
*root,
struct btrfs_key found_key;
path = btrfs_alloc_path();
-
On Fri, Jul 15, 2011 at 12:04:46PM +0900, Tsutomu Itoh wrote:
(2011/07/15 7:15), Mark Fasheh wrote:
In addition to properly handling allocation failure from btrfs_alloc_path, I
also fixed up the kzalloc error handling code immediately below it.
Need not you correct the caller of
Sorry,
discard this email
On 07/18/2011 07:33 PM, Goffredo Baroncelli wrote:
The following series implements...
---
Goffredo Baroncelli (6):
Add info for the commands.
Add the header/footer/introduction of the man page.
helpextract: tool to extract the info for the
Excerpts from Mark Fasheh's message of 2011-07-18 17:36:57 -0400:
Hi Tsutomu,
Thanks for the review, it is appreciated!
On Fri, Jul 15, 2011 at 11:43:52AM +0900, Tsutomu Itoh wrote:
@@ -1037,7 +1037,8 @@ static noinline int find_next_chunk(struct
btrfs_root *root,
struct
Hi, Mark,
(2011/07/19 7:09), Mark Fasheh wrote:
On Fri, Jul 15, 2011 at 12:04:46PM +0900, Tsutomu Itoh wrote:
(2011/07/15 7:15), Mark Fasheh wrote:
In addition to properly handling allocation failure from btrfs_alloc_path, I
also fixed up the kzalloc error handling code immediately below it.
:
This is a test message.
Best Regards,
Smart Williams
wsmar...@yahoo.nl
Sent on 2011-07-18
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
25 matches
Mail list logo
