On Mon, 20 Jun 2011 20:12:16 -0400, Josef Bacik wrote:
On 06/20/2011 05:51 PM, Henning Rohlfs wrote:
Hello,
I've migrated my system to btrfs (raid1) a few months ago. Since
then
the performance has been pretty bad, but recently it's gotten
unbearable: a simple sync called while the system is
Henning Rohlfs wrote (ao):
- space_cache was enabled, but it seemed to make the problem worse.
It's no longer in the mount options.
space_cache is a one time mount option which enabled space_cache. Not
supplying it anymore as a mount option has no effect (dmesg | grep btrfs).
Sander
I've been working to try to improve the write-ahead log's performance,
and I found that the bottleneck addresses in the checksum items,
especially when we want to make a random write on a large file, e.g a 4G file.
Then a idea for this suggested by Chris is to use sub transaction ids and just
to
Cause we've added sub transaction, if it do not want to cow a block, we also
need to get new sub transid recorded. This is used for log code to find the
most uptodate file extents.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.c | 34 +-
1
In multi-thread situations, writeback of a file may span across several
sub transactions, and we need to introduce first_sub_trans to get sub_transid of
teh first sub transaction recorded, so that log code can skip file extents which
have been logged or committed onto disk.
Signed-off-by: Liu Bo
We want to use btrfs_drop_extent() in log code.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/ctree.h|3 ++-
fs/btrfs/file.c |9 +++--
fs/btrfs/inode.c|6 +++---
fs/btrfs/ioctl.c|4 ++--
fs/btrfs/tree-log.c |2 +-
5 files changed, 15
If a inode is a BTRFS_INODE_NODATASUM one, it need not to look for csum items
any more.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/tree-log.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index
Introduce a new concept sub transaction,
the relation between transaction and sub transaction is
transaction A --- transid = x
sub trans a(1) --- sub_transid = x+1
sub trans a(2) --- sub_transid = x+2
... ...
sub trans a(n-1) --- sub_transid = x+n-1
sub trans a(n) ---
Due to DIO stuff, commit 1ef30be142d2cc60e2687ef267de864cf31be995 makes btrfs
not call btrfs_update_inode when it does not update i_disk_size, but in buffer
write case, we need to update btrfs internal inode's trans stuff, so that the
log code can find the inode's changes.
Signed-off-by: Liu Bo
There are two cases when BTRFS_I(inode)-logged_trans is zero:
a) an inode is just allocated;
b) iput an inode and reread it.
However, in b) if btrfs is not committed yet, and this inode _may_ still remain
in log tree.
So we need to check the log tree to get logged_trans a right value
in case it
The current code uses struct root's last_log_commit to check if an inode
has been logged, but the problem is that this root-last_log_commit is
shared among files. Say we have N inodes to be logged, after the first
inode, root-last_log_commit is updated and the N-1 remains will not be
logged.
As
fsync will wait for writeback till it finishes, and last_trans will get the real
transid recorded in writeback, so it does not need an extra +1 to ensure fsync's
process on the file.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/file.c | 13 -
1 files changed, 0
This reverts commit 8e531cdfeb75269c6c5aae33651cca39707848da.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/tree-log.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 166fda5..d4ccf91 100644
---
When logging an inode _A_, current btrfs will
a) clear all items belonged to _A_ in log,
b) copy all items belonged to _A_ from fs/file tree to log tree,
and this just wastes a lot of time, especially when logging big files.
So we want to use a smarter approach, i.e. find and merge.
The amount of
Currently we use the generation number of the super to read in the log
tree root after a crash. This doesn't always match the sub trans id and
so it doesn't always match the transid stored in the btree blocks.
We can use log_root_transid to record the log_root_tree's generation
so that when we
On Tue, 21 Jun 2011 10:00:59 +0200, Sander wrote:
Henning Rohlfs wrote (ao):
- space_cache was enabled, but it seemed to make the problem worse.
It's no longer in the mount options.
space_cache is a one time mount option which enabled space_cache. Not
supplying it anymore as a mount option
On Tue, Jun 21, 2011 at 03:40:56PM +1000, Dave Chinner wrote:
Modification of inode-i_state is not safe outside the
inode-i_lock.
We never actually set the new bit in i_state, we just use it as a key
for the hashed lookups. Or rather we try to, as I misunderstood how
wait_on_bit works, so
On Tuesday, June 21, 2011 01:50:10 PM Li Zefan wrote:
When the end of an extent exceeds the end of the specified range,
the extent will be accidentally truncated.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/free-space-cache.c |9 -
1 files changed, 8
Hello,
Nirbheek Chauhan nirbheek at gentoo.org writes:
However, recently, perhaps with 2.6.39, or after I quickly started
filling up my disk again, it has become impossible for me to work for
long periods on my machine.
Every few minutes, (I guess) when applications do fsync (firefox,
[HELP!] parent transid verify failed on 600755752960 wanted 757102 found 756726
Hi list, I've a broken btrfs filesystem to deal with can someone
please help me in recover the data?
The filesystem has been created a pair of years ago with 4 devices
with the command at #create and is mounted with
On 06/21/2011 04:49 AM, Liu Bo wrote:
When logging an inode _A_, current btrfs will
a) clear all items belonged to _A_ in log,
b) copy all items belonged to _A_ from fs/file tree to log tree,
and this just wastes a lot of time, especially when logging big files.
So we want to use a smarter
On 06/21/2011 04:49 AM, Liu Bo wrote:
There are two cases when BTRFS_I(inode)-logged_trans is zero:
a) an inode is just allocated;
b) iput an inode and reread it.
However, in b) if btrfs is not committed yet, and this inode _may_ still remain
in log tree.
So we need to check the log tree to
Welcome to the club, I have a similar issue. We pretty much have to wait for the
fsck tool to finish being developed. If possible unhook the drives and leave
them be until the tool is done. I don't know when it will be done as I am not a
developer, mearly a follower.
--
To unsubscribe from this
On Sat, Jun 18, 2011 at 01:45:58PM +0200, Jan Schmidt wrote:
+/*
+ * returns 0 if the path could be dumped (probably truncated)
+ * returns 0 in case of an error
+ */
+static int inode_to_path(u64 inum, struct btrfs_inode_ref *iref,
+ struct extent_buffer *eb_ir,
2011/6/21 Daniel Witzel dannyboy48...@gmail.com:
Welcome to the club, I have a similar issue. We pretty much have to wait for
the
fsck tool to finish being developed. If possible unhook the drives and leave
them be until the tool is done. I don't know when it will be done as I am not
a
On 21.06.2011 16:37, David Sterba wrote:
On Sat, Jun 18, 2011 at 01:45:58PM +0200, Jan Schmidt wrote:
+/*
+ * returns 0 if the path could be dumped (probably truncated)
+ * returns 0 in case of an error
+ */
+static int inode_to_path(u64 inum, struct btrfs_inode_ref *iref,
+
On 06/21/2011 05:26 AM, Henning Rohlfs wrote:
On Tue, 21 Jun 2011 10:00:59 +0200, Sander wrote:
Henning Rohlfs wrote (ao):
- space_cache was enabled, but it seemed to make the problem worse.
It's no longer in the mount options.
space_cache is a one time mount option which enabled
On Mon, 2011-06-20 at 23:51 +0200, Henning Rohlfs wrote:
Hello,
I've migrated my system to btrfs (raid1) a few months ago. Since then
the performance has been pretty bad, but recently it's gotten
unbearable: a simple sync called while the system is idle can take 20 up
to 60 seconds.
When doing DIO tracing I noticed we were doing a ton of allocations, a lot of
the time for extent_states. Some of the time we don't even use the prealloc'ed
extent_state, it just get's free'd up. So instead create a per-cpu cache like
the radix tree stuff. So we will check to see if our per-cpu
First, we can sometimes free the state we're merging, which means anybody who
calls merge_state() may have the state it passed in free'ed. This is
problematic because we could end up caching the state, which makes caching
useless as the state will no longer be part of the tree. So instead of
Christoph Hellwig h...@infradead.org writes:
Add a new rw_semaphore to protect bmap against truncate. Previous
i_alloc_sem was abused for this, but it's going away in this series.
In FAT case, -i_mutex was better. But, last time I saw, shmfs was using
-i_mutex to call -bmap. So, this was
OGAWA Hirofumi hirof...@mail.parknet.co.jp writes:
Christoph Hellwig h...@infradead.org writes:
Add a new rw_semaphore to protect bmap against truncate. Previous
i_alloc_sem was abused for this, but it's going away in this series.
In FAT case, -i_mutex was better. But, last time I saw,
On Wed, Jun 22, 2011 at 12:57:43AM +0900, OGAWA Hirofumi wrote:
Christoph Hellwig h...@infradead.org writes:
Add a new rw_semaphore to protect bmap against truncate. Previous
i_alloc_sem was abused for this, but it's going away in this series.
In FAT case, -i_mutex was better. But, last
On Tue, 21 Jun 2011 11:18:30 -0400, Josef Bacik wrote:
On 06/21/2011 05:26 AM, Henning Rohlfs wrote:
On Tue, 21 Jun 2011 10:00:59 +0200, Sander wrote:
Henning Rohlfs wrote (ao):
- space_cache was enabled, but it seemed to make the problem
worse.
It's no longer in the mount options.
On Mon, 20 Jun 2011, Christoph Hellwig wrote:
Add a new rw_semaphore to protect page_mkwrite against truncate. Previous
i_alloc_sem was abused for this, but it's going away in this series.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: linux-2.6/fs/ext4/inode.c
On Tue, Jun 21, 2011 at 06:34:50PM +0200, Lukas Czerner wrote:
this looks like a bug fix, so we should rather do it in a separate
commit. Could you send it separately, or at least mention that in commit
description ?
What looks like a bugfix?
--
To unsubscribe from this list: send the line
On Tue, 21 Jun 2011, Lukas Czerner wrote:
On Mon, 20 Jun 2011, Christoph Hellwig wrote:
Add a new rw_semaphore to protect page_mkwrite against truncate. Previous
i_alloc_sem was abused for this, but it's going away in this series.
Signed-off-by: Christoph Hellwig h...@lst.de
Josef Bacik jo...@redhat.com writes:
When doing DIO tracing I noticed we were doing a ton of allocations, a lot of
the time for extent_states. Some of the time we don't even use the
prealloc'ed
extent_state, it just get's free'd up. So instead create a per-cpu cache like
the radix tree
On 06/21/2011 04:20 PM, Andi Kleen wrote:
Josef Bacik jo...@redhat.com writes:
When doing DIO tracing I noticed we were doing a ton of allocations, a lot of
the time for extent_states. Some of the time we don't even use the
prealloc'ed
extent_state, it just get's free'd up. So instead
On Mon 20-06-11 16:15:33, Christoph Hellwig wrote:
i_alloc_sem has always been a bit of an odd lock. It's the only remaining
rw_semaphore that can be released by a different thread than the one that
locked it, and it's use case in the core direct I/O code is more like a
counter given that the
On 06/21/2011 10:00 PM, Josef Bacik wrote:
On 06/21/2011 04:49 AM, Liu Bo wrote:
There are two cases when BTRFS_I(inode)-logged_trans is zero:
a) an inode is just allocated;
b) iput an inode and reread it.
However, in b) if btrfs is not committed yet, and this inode _may_
still remain
in
---
Christopher Whelan wants to stay in better touch using some of
Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-ee9a324c7f-06c7f01d3e-rl8EXZ4nBadGESgcw_qYvUYj1Po
On Tue, 21 Jun 2011 02:08:54 +0200, David Sterba wrote:
On Mon, Jun 20, 2011 at 06:12:10PM +0800, Miao Xie wrote:
From 457f39393b2e3d475fbba029b90b6a4e17b94d43 Mon Sep 17 00:00:00 2001
From: Miao Xie mi...@cn.fujitsu.com
Date: Mon, 20 Jun 2011 17:21:51 +0800
Subject: [PATCH] btrfs: fix
The following functions always return 0.
- add_delayed_ref_head()
- add_delayed_tree_ref()
- add_delayed_data_ref()
- add_excluded_extent()
Therefore, check by BUG_ON() is unnecessary at the caller of these
functions.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
44 matches
Mail list logo
