For a filesystem that has lots of files in it, the first time we mount
it with free ino caching support, it can take quite a long time to
setup the caching before we can create new files.
Here we fill the cache with [highest_ino, BTRFS_LAST_FREE_OBJECTID]
before we start the caching thread to
On 26.05.2011 08:38, Li Zefan wrote:
For a filesystem that has lots of files in it, the first time we mount
it with free ino caching support, it can take quite a long time to
setup the caching before we can create new files.
Here we fill the cache with [highest_ino, BTRFS_LAST_FREE_OBJECTID]
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
the first sub transaction recorded, so that log code can skip file extents which
have been logged or committed into 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
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) ---
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
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
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
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
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
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
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 includes the two patches that we've discussed before.
I sent this as a whole just in case you have to patch the code by yourself. :)
thanks,
liubo
On 05/26/2011 04:19 PM, Liu Bo wrote:
I've been working to try to improve the write-ahead log's performance,
and I found that the bottleneck
On 25/05/11 22:30, Josef Bacik wrote:
I noticed when running an enospc test that we would get stuck committing the
transaction in check_data_space even though we truly didn't have enough space.
So check to see if bytes_pinned is bigger than num_bytes, if it's not don't
commit the transaction.
Hi,
On Mon, May 23, 2011 at 02:59:06PM +0200, Arne Jansen wrote:
+static struct reada_zone *reada_find_zone(struct btrfs_fs_info *fs_info,
+ struct btrfs_device *dev, u64 logical,
+ struct btrfs_multi_bio *multi)
+{
On Mon, May 23, 2011 at 12:13:07PM -0400, Josef Bacik wrote:
On 05/21/2011 10:11 PM, Al Viro wrote:
On Fri, May 20, 2011 at 01:44:30PM -0400, Josef Bacik wrote:
+ if (unlikely(d_need_lookup(dentry))) {
+ if (nameidata_dentry_drop_rcu(nd, dentry))
+
On thu, 26 May 2011 12:14:21 +0200, David Sterba wrote:
Hi,
On Mon, May 23, 2011 at 02:59:06PM +0200, Arne Jansen wrote:
+static struct reada_zone *reada_find_zone(struct btrfs_fs_info *fs_info,
+ struct btrfs_device *dev, u64 logical,
+
On 26.05.2011 12:47, Miao Xie wrote:
On thu, 26 May 2011 12:14:21 +0200, David Sterba wrote:
Hi,
On Mon, May 23, 2011 at 02:59:06PM +0200, Arne Jansen wrote:
+static struct reada_zone *reada_find_zone(struct btrfs_fs_info *fs_info,
+ struct btrfs_device
On 05/26/2011 04:57 AM, Adrian Hunter wrote:
On 25/05/11 22:30, Josef Bacik wrote:
I noticed when running an enospc test that we would get stuck
committing the
transaction in check_data_space even though we truly didn't have
enough space.
So check to see if bytes_pinned is bigger than
Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
for readdir, but unfortunately in the case of anything that stats the files in
order that readdir spits back (like oh say ls) that means we still have to do
the normal lookup of the file, which means looking up our other
On 05/26/2011 02:50 PM, Andi Kleen wrote:
Josef Bacik jo...@redhat.com writes:
+
+newkey = kzalloc(sizeof(struct btrfs_key),
+ GFP_NOFS);
+if (!newkey)
+
On Thu, May 26, 2011 at 03:02:42PM -0400, Josef Bacik wrote:
+ /*
+ * If this dentry needs lookup, don't set the referenced flag so that it
+ * is more likely to be cleaned up by the dcache shrinker in case of
+ * memory pressure.
+ */
+ if
On 05/26/2011 04:03 PM, Andi Kleen wrote:
On Thu, May 26, 2011 at 03:02:42PM -0400, Josef Bacik wrote:
+/*
+ * If this dentry needs lookup, don't set the referenced flag so that it
+ * is more likely to be cleaned up by the dcache shrinker in case of
+ * memory pressure.
+
On May 26, 2011, at 14:03, Andi Kleen wrote:
On Thu, May 26, 2011 at 03:02:42PM -0400, Josef Bacik wrote:
+/*
+ * If this dentry needs lookup, don't set the referenced flag so that it
+ * is more likely to be cleaned up by the dcache shrinker in case of
+ * memory pressure.
+
Hiya,
I get a btrfs sub list output that I don't understand:
# btrfs sub list /backup/
ID 257 top level 5 path u1/linux/lvm+btrfs/storage/data/data
ID 260 top level 5 path u2/linux/lvm/linux/var/data
ID 262 top level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-11
ID 263 top level 5
26 matches
Mail list logo
