Hello,
On a 3.6.0-rc7 kernel, I launched:
# btrfs fi balance start -f -mconvert=single /mnt/tmp/
Current situation:
# df -h /mnt/tmp/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/alpha-lv1 3.6T 2.7T 801G 78% /mnt/tmp
# btrfs fi df /mnt/tmp/
Data: total=3.00TB,
Because the value of extent_map is only a correct value or NULL,
so IS_ERR is unnecessary.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/extent_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index
We should confirm the value of extent_map before calling
trace_btrfs_get_extent() because the value of extent_map has the
possibility of NULL.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Hi,
First, sorry if this isn't the place to get this kind of help...
If not, I appreciate some link , forum, where I can try get some answers...
My problem:
* Using btrfs + compression , flush of 60 MB/s take 4 minutes
(on this 4 minutes they keep constatly I/O of +- 4MB/s no disks)
(flush
On Mon, Oct 1, 2012 at 8:27 PM, Cesar Inacio Martins
cesar_inacio_mart...@yahoo.com.br wrote:
My problem:
* Using btrfs + compression , flush of 60 MB/s take 4 minutes
(on this 4 minutes they keep constatly I/O of +- 4MB/s no disks)
(flush from Informix database)
* OpenSuse 12.1
On Sun, Sep 30, 2012 at 05:28:23AM -0600, Alex Lyakas wrote:
Hi Josef,
I guess I am missing something, but I thought btrfs_next_leaf() should
just jump to the next leaf (or item, if it was added meanwhile)
irrespective of the key that is in the last slot of the current leaf.
The change you
On Fri, Sep 28, 2012 at 11:45:21AM -0600, Zach Brown wrote:
When we truncate existing items in the tree log we've been searching for
each individual item and removing them. This is unnecessary churn and
searching, just keep track of the slot we are on and how many items we need
to delete
Miao Xie miaox at cn.fujitsu.com writes:
This patchset introduce extent buffer cache to btrfs. The basic idea
is to reduce the search time and the contentions of the extent buffer
lock by re-using the last search result.
I ran stress.sh, xfstests and some other tools to test it, all of
When we truncate existing items in the tree log we've been searching for
each individual item and removing them. This is unnecessary churn and
searching, just keep track of the slot we are on and how many items we need
to delete and delete them all at once. Thanks,
Signed-off-by: Josef Bacik
I need everybody to go over this with a fine toothed comb since it is a pretty
big change. I think it is right and it seems to come out right, but if it's not
it will mean we screw up O_DIRECT on snapshotted files with preallocated
extents, so please, make sure it is correct :).
---
Subject:
From: Goffredo Baroncelli kreij...@inwind.it
pretty_sizes() returns incorrect values if the argument is 1024.
pretty_sizes(0) - 0.00 OK
pretty_sizes(102) - 0.10 WRONG
pretty_sizes(1023) - 1.00 WRONG
pretty_sizes(1024) - 1.00KBOK
Signed-off-by: Goffredo Baroncelli
On Tue, Oct 2, 2012 at 3:16 AM, Clemens Eisserer linuxhi...@gmail.com wrote:
I suggest you start by reading
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg18827.html
After that, PROBABLY start your database by preloading libeatmydata to
disable fsync completely.
Which will cure
12 matches
Mail list logo