On mon, 07 Mar 2011 08:25:47 +0900, Tsutomu Itoh wrote:
(2011/03/05 16:01), Itaru Kitayama wrote:
Hi Miao,
The V3 patch on top of the next-rc fails to pass an xfstests test 13.
In the btrfs link path, we need to reserve one more metadata in the
trans_block_rsv for the delayed inode update
Hi, Chris and Josef
Recently, I am interested in chunk tree backups, which is described in
Project ideas web. But I found it is hard to be implemented.
The description said make the mappings discoverable via a block device
scan so that we can recover from corrupted chunk trees, I think it is
Hi, Kitayama-san
Sorry for my late reply.
On Thu, 24 Feb 2011 23:02:55 +0900, Itaru Kitayama wrote:
I have applied the V2 patch on top of the next-rc branch of btrfs-unstable
and ran dbench 50. The run never finished and lots of stall messages recorded
in the log.
Looking at the stack trace,
Hi, Chris and Liu
On thu, 24 Feb 2011 09:35:32 -0500, Chris Mason wrote:
[SNIP]
[PATCH] btrfs: fix OOPS of empty filesystem after balance
btrfs will exclude unused block groups via a thread.
When a empty filesystem is balanced, the block group with tag DATA may be
dropped,
and after umount,
Hi, Chris
CC Tsutomu Itoh
On Thu, 17 Feb 2011 20:09:00 -0500, Chris Mason wrote:
Excerpts from Miao Xie's message of 2011-02-17 00:48:40 -0500:
Compare with Ext3/4, the performance of file creation and deletion on btrfs
is very poor. the reason is that btrfs must do a lot of b+ tree
Any comments for these patches?
Thanks
Miao
On wed, 05 Jan 2011 18:07:11 +0800, Miao Xie wrote:
I have a bunch of random fixes of the space management in
git://repo.or.cz/linux-btrfs-devel.git space-manage
They are the ENOSPC fixes, as well as fixes for df command.
The first one
Hello, Chris
I have a bunch of random fixes of the space management in
git://repo.or.cz/linux-btrfs-devel.git space-manage
They are the ENOSPC fixes, as well as fixes for df command.
The first one and the last one fixed the wrong free space information reported
by df command. The second one
Josef has implemented mixed data/metadata chunks, we must add those chunks'
space just like data chunks.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/super.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index
- make it return the start position and length of the max free space when it can
not find a suitable free space.
- make it more readability
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |4 +-
fs/btrfs/volumes.c | 155
when chunk allocation failed.
This patch fixes it by committing the current transaction to reclaim some
space when chunk allocation fails.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Reviewed-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/extent-tree.c |9 +++--
1 files changed, 7
as large as possible when
the devices' space is not enough and make full use of the devices.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
Changelog V2 - V3:
- fix panic caused by freeing a invalid memory address, which was pointed out by
Mitch Harder.
Changelog V1 - V2:
- fix compiler errors
appling this patch, df can show correct space information:
# df -TH
Filesystem TypeSizeUsedAvail Use%Mounted on
/dev/sda9 btrfs 17G 8.6G0 100%/mnt
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h |2 +
fs/btrfs/extent-tree.c
chunk allocation. It is because the device
space that a dup chunk needs is twice as large as the chunk size, if we use
the size of the residual free space as the length of a dup chunk, we can not
get enough free space. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
Changelog V1 - V2
Hi, Mitch
Could you test the third version of this patchset for me?
Thanks
Miao
On mon, 3 Jan 2011 23:46:00 -0600, Mitch Harder wrote:
2010/12/29 Miao Xiemi...@cn.fujitsu.com:
Hello, Chris
I have a bunch of random fixes of the space management in
git://repo.or.cz/linux-btrfs-devel.git
Hi, Kitayama-san
Firstly, thanks for your test.
On Sat, 1 Jan 2011 00:43:41 +0900, Itaru Kitayama wrote:
Hi Miao,
The HEAD of the perf-improve fails to boot on my virtual machine.
The system calls btrfs_delete_delayed_dir_index() with trans block_rsv set to
NULL,
thus selects, in
On mon, 3 Jan 2011 23:46:00 -0600, Mitch Harder wrote:
2010/12/29 Miao Xiemi...@cn.fujitsu.com:
Hello, Chris
I have a bunch of random fixes of the space management in
git://repo.or.cz/linux-btrfs-devel.git space-manage
They are the ENOSPC fixes, as well as fixes for df command.
The
Hello, Chris
I have a bunch of random fixes of the space management in
git://repo.or.cz/linux-btrfs-devel.git space-manage
They are the ENOSPC fixes, as well as fixes for df command.
The first one and the last one fixed the wrong free space information reported
by df command. The second one
chunk allocation. It is because the device
space that a dup chunk needs is twice as large as the chunk size, if we use
the size of the residual free space as the length of a dup chunk, we can not
get enough free space. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
Changelog V1 - V2
Josef has implemented mixed data/metadata chunks, we must add those chunks'
space just like data chunks.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/super.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index
when chunk allocation failed.
This patch fixes it by committing the current transaction to reclaim some
space when chunk allocation fails.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Reviewed-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/extent-tree.c |9 +++--
1 files changed, 7
as large as possible when
the devices' space is not enough and make full use of the devices.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
Changelog V1 - V2:
- fix compiler errors x86_32 machines which were caused by u64 division.
- fix wrong check of the min number of the devices when
appling this patch, df can show correct space information:
# df -TH
Filesystem TypeSizeUsedAvail Use%Mounted on
/dev/sda9 btrfs 17G 8.6G0 100%/mnt
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h |2 +
fs/btrfs/extent-tree.c
- make it return the start position and length of the max free space when it can
not find a suitable free space.
- make it more readability
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |4 +-
fs/btrfs/volumes.c | 155
Hello,
I have a bunch of random fixes of the space management in
git://repo.or.cz/linux-btrfs-devel.git space-manage
They are the ENOSPC fixes, as well as fixes for df command.
The first one and the last one fixed the wrong free space information reported
by df command. The second one fixed
Josef has implemented mixed data/metadata chunks, we must add those chunks'
space just like data chunks.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/super.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index
when chunk allocation failed.
This patch fixes it by committing the current transaction to to reclaim some
space when chunk allocation fails.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs
- make it return the start position and length of the max free space when it can
not find a suitable free space.
- make it more readability
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |4 +-
fs/btrfs/volumes.c | 155
chunk allocation. It is because the device
space that a dup chunk needs is twice as large as the chunk size, if we use
the size of the residual free space as the length of a dup chunk, we can not
get enough free space. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c
appling this patch, df can show correct space information:
# df -TH
Filesystem TypeSizeUsedAvail Use%Mounted on
/dev/sda9 btrfs 17G 8.6G0 100%/mnt
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h |2 +
fs/btrfs/extent-tree.c
, if there is no enough space on the device, we just ignore it.
Sometimes, we must retain the original semantic.
Thanks
Miao
As both patches address the same problem, it might be good to compare
them in more detail.
--
Arne
On 22.12.2010 11:47, Miao Xie wrote:
- make it return the start
Hi, Chris
There is something wrong with this patch:
commit 83a50de97fe96aca82389e061862ed760ece2283
Author: Chris Mason chris.ma...@oracle.com
Date: Mon Dec 13 15:06:46 2010 -0500
Btrfs: prevent RAID level downgrades when space is low
The extent allocator has code that allows us
On Mon, 20 Dec 2010 07:44:06 -0500, Chris Mason wrote:
Excerpts from Miao Xie's message of 2010-12-20 07:25:10 -0500:
Hi, Chris
There is something wrong with this patch:
commit 83a50de97fe96aca82389e061862ed760ece2283
Author: Chris Masonchris.ma...@oracle.com
Date: Mon Dec 13 15:06:46 2010
On wed, 08 Dec 2010 08:53:55 +0900, Tsutomu Itoh wrote:
I think that the disk allocation size of each file becomes a monotone
increase
when the file is made.
But, it sometimes return to 0. Is it correct?
The # of blocks is:
stat-blocks = (inode_get_bytes(inode) +
On thu, 02 Dec 2010 11:33:40 -0500, Chris Mason wrote:
Excerpts from Miao Xie's message of 2010-12-01 03:09:35 -0500:
Compare with Ext3/4, the performance of file creation and deletion on btrfs
is very poor. the reason is that btrfs must do a lot of b+ tree insertions,
such as inode item,
Compare with Ext3/4, the performance of file creation and deletion on btrfs is
very poor. the reason is that btrfs must do a lot of b+ tree insertions, such as
inode item, directory name item, directory name index and so on.
If we can do some delayed b+ tree insertion or deletion, we can improve
restructure btrfs_insert_dir_item() and introduce a function
btrfs_insert_dir_index_item() to insert dir index item.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h|6
fs/btrfs/dir-item.c | 69 +++---
2 files changed
With the old code, we must map the page every time we want to set a member
variable of the inode item, it is inefficient. We just do it at first.
By this way, we can improve the performance of file creation and deletion
by ~2%
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/inode.c
: 5
Total time: 1.439360
Average time: 0.29
[1] http://marc.info/?l=linux-btrfsm=128212635122920q=p3
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/Makefile|2 +-
fs/btrfs/btrfs_inode.h |2 +
fs/btrfs/ctree.c | 13 +-
fs
From: Liu Bo liubo2...@cn.fujitsu.com
When the filesystem is readonly, commit transaction is forbiddened.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/transaction.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff
On Thu, 25 Nov 2010 19:42:53 +0800, Wenyi Liu wrote:
Hi Xie Miao:
I cannot understand the btrfs_decode_error(). why you chose the
three errnos? what about others? eager for Ur replay. Thanks!!
I think liu chose these three errors is because these errors are familiar ones
that are hard to
bio_endio() will free dip and dip-csums, so dip and dip-csums twice will
be freed twice. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/inode.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 558cac2
extent_bio_alloc() and compressed_bio_alloc() are similar, cleanup
similar source code.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/compression.c | 15 +--
fs/btrfs/extent_io.c |8
fs/btrfs/extent_io.h |3 +++
3 files changed, 8 insertions(+), 18
bios when we submit bios.
Reported-by: Tsutomu Itoh t-i...@jp.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Tested-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c | 205 --
1 files changed, 184 insertions(+), 21 deletions
Hi, Josef
On wed, 17 Nov 2010 04:37:21 -0500, Josef Bacik wrote:
Heh so I was going to fix this after the hole punching stuff. The fact is btrfs
maps everything that is ok to do in one IO via get_blocks(). So all we need to
do is add another DIO_ flag to tell us to treat each get_blocks()
On wed, 17 Nov 2010 11:55:28 -0500, Chris Mason wrote:
Excerpts from Josef Bacik's message of 2010-11-17 07:50:11 -0500:
On Wed, Nov 17, 2010 at 06:11:03PM +0800, Miao Xie wrote:
Hi, Josef
On wed, 17 Nov 2010 04:37:21 -0500, Josef Bacik wrote:
Heh so I was going to fix this after
We restructured btrfs_merge_bio_hook(). And the new function will be used to
fix a panic problem that caused by direct IO.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/inode.c | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/fs
BTRFS can not submit bios that span its chunks or stripes, so it needs a
function to check it when we want to add a page into the bios. So we add a
can_merge_io hook to do it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/block_dev.c |3 ++-
fs/btrfs/inode.c
into the bios.
Reported-by: Tsutomu Itoh t-i...@jp.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Tested-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index
On Mon, 18 Oct 2010 10:41:41 +0800, Shaohua Li wrote:
Hi Miao Chris,
On Wed, Oct 13, 2010 at 05:00:56PM +0800, Miao Xie wrote:
When I investigated the performance problem of file creation/deletion, I found
btrfs spends lots of time in the b-tree search, so I consider whether we can use
Hi, Chris
When I investigated the performance problem of file creation/deletion, I found
btrfs spends lots of time in the b-tree search, so I consider whether we can use
the latest search result in the same transaction or not.
My idea follows:
we can add mask or time stamp into b-tree's node and
On Tue, 12 Oct 2010 14:43:23 -0400, Chris Mason wrote:
On Tue, Oct 12, 2010 at 05:43:14PM +0800, Miao Xie wrote:
This patch reduces the CPU time spent in the extent buffer search by using the
radix tree instead of the rbtree and using the rcu lock instead of the spin
lock.
I did a quick test
1.2210738%UP
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
arch/x86/include/asm/string_64.h |1 +
arch/x86/lib/Makefile|2 +-
arch/x86/lib/memcpy_bwd_64.S | 137 ++
arch/x86/lib/memmove_64.c| 10 ++-
4 files
On Thu, 16 Sep 2010 08:48:25 +0200 (cest), Andi Kleen wrote:
When the dest and the src do overlap and the memory area is large, memmove
of
x86_64 is very inefficient, and it led to bad performance, such as btrfs's
file
deletion performance. This patch improved the performance of memmove on
On Thu, 16 Sep 2010 10:40:08 +0200, Andi Kleen wrote:
On Thu, 16 Sep 2010 15:16:31 +0800
Miao Xiemi...@cn.fujitsu.com wrote:
On Thu, 16 Sep 2010 08:48:25 +0200 (cest), Andi Kleen wrote:
When the dest and the src do overlap and the memory area is large,
memmove of
x86_64 is very inefficient,
Hi, Andi
On Thu, 2 Sep 2010 12:40:08 +0200, Andi Kleen wrote:
So I improve the generic version of memcpy and memmove, and x86_64's memmove
which are implemented by byte copy.
One should also add that most memmove()s and memcpy()s are actually
generated by gcc as inlines (especially if you
On Wed, 8 Sep 2010 14:19:25 +0200 (cest), Andi Kleen wrote:
According to the data, the length of the most copies is=128.
Thanks for the data. Large is easier to optimize than small, that's good.
Could you also measure how many memsets need the backwards copy?
(should be easy to add)
I
On Wed, 8 Sep 2010 15:05:19 +0200, Andi Kleen wrote:
On Wed, 08 Sep 2010 20:57:07 +0800
Miao Xiemi...@cn.fujitsu.com wrote:
On Wed, 8 Sep 2010 14:19:25 +0200 (cest), Andi Kleen wrote:
According to the data, the length of the most copies is=128.
Thanks for the data. Large is easier to
On Thu, 02 Sep 2010 15:55:44 +1000, Chris Samuel wrote:
Hiya,
On 02/09/10 15:44, Miao Xie wrote:
Ok, I will change it.
Did you just change the 2.1 to 2 in your patch, or did you find
a specifically version 2 licensed version of that code ?
If so, where was that ?
I just change the 2.1
On Thu, 2 Sep 2010 08:53:47 +0200, Ingo Molnar wrote:
* Miao Xiemi...@cn.fujitsu.com wrote:
- change the version of GPL from version 2.1 to version 2
How were you able to do this? If the code derives from glibc (as your
comments in the patches suggest), and if glibc is under the GPL v2.1,
On Thu, 02 Sep 2010 10:55:58 +0200, Andi Kleen wrote:
Miao Xiemi...@cn.fujitsu.com writes:
Changes from V1 to V2:
- change the version of GPL from version 2.1 to version 2
the kernel's memcpy and memmove is very inefficient. But the glibc version is
quite fast, in some cases it is 10 times
When I looked into the performance problem of the btrfs, I found some memory
copy functions of the kernel(such as: x86_64's memmove)is very inefficient,
but the glibc version is quite fast, in some cases it is 10 times faster than
the kernel version.
This patchset introduced some macros and
functions is:
1. Copy bytes until the destination pointer is aligned.
2. Copy words in unrolled loops. If the source and destination are not aligned
in the same way, use word memory operations, but shift and merge two read
words before writing.
3. Copy the few remaining bytes.
Signed-off-by: Miao
the performance of memcpy and memmove of the general version is
very inefficient, this patch improved them.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
lib/string.c | 32 ++--
1 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/lib/string.c b/lib
-rc1 + patchset
file creation 0.9668070.9475921.9%UP
file deletion 1.3556711.21778710.2%UP
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
arch/x86/lib/memmove_64.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git
On Wed, 01 Sep 2010 17:25:36 +0200, Peter Zijlstra wrote:
On Wed, 2010-09-01 at 18:36 +0800, Miao Xie wrote:
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either
Changes from V1 to V2:
- change the version of GPL from version 2.1 to version 2
When I looked into the performance problem of the btrfs, I found some memory
copy functions of the kernel(such as: x86_64's memmove)is very inefficient,
but the glibc version is quite fast, in some cases it is 10
words before writing.
3. Copy the few remaining bytes.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
include/linux/memcopy.h | 226 ++
lib/Makefile|3 +-
lib/memcopy.c | 403 +++
3 files changed
-rc1 + patchset
file creation 0.9668070.9475921.9%UP
file deletion 1.3556711.21778710.2%UP
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
arch/x86/lib/memmove_64.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git
the performance of memcpy and memmove of the general version is
very inefficient, this patch improved them.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
lib/string.c | 32 ++--
1 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/lib/string.c b/lib
.
Thanks
Miao Xie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
: 0.660.20
The results were measured on a x86_64 server with 4 cores and 2 SAS disks.
By debuging, we found the btrfs spent a lot of time on searching and
inserting/removing items in the ctree.
Is anyone looking at this issue?
Regards
Miao Xie
/* gcc creat_unlink.c -o
Ext4
Total times: 2.4843921.505082
Average: 0.500.30
Delete file performance
BtrFS Ext4
Total times: 3.3694691.024886
Average: 0.670.20
Which kernel you use?
v2.6.35
Regards
Miao Xie
2010/8/18
?
I'm looking at it now, which kernel were you on? We do spend some CPU
time on the btree but it shouldn't be a big bottleneck compared to the
disk.
I tested it on v2.6.35 kernel.
Regards
Miao Xie
This should be very similar to the performance regression that Steve
Pratt hit. Our deletion
.
The radix tree is a much easier and more contained project.
It is good idea, We will try to do it.
Thanks
Miao Xie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Hi, Adi
On Mon, 02 Aug 2010 21:37:16 +0200, Adi wrote:
now i get that error (on btrfsck):
parent transid verify failed on 5403553792 wanted 103380 found 103378
btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root-node)' failed.
if i want to mount it, it shows the same error in
On Thu, 29 Jul 2010 13:27:09 +0200, Ulrich Hecht wrote:
+static long btrfs_ioctl_compsize(struct file *file, void __user *argp)
+{
+ /* This ioctl returns the compressed size of an inode on disk
+ * by counting the on-disk space used by all of its extents.
+ */
+ struct
On Thu, 29 Jul 2010 15:50:28 +0800, Wang Shaoyan wrote:
Hi.
I want a subvolume in root to be compressed, I try to do this:
# mkfs.btrfs /dev/sda8
# mount /dev/sda8 /home/usr/btrfs
# cd /home/usr/btrfs
# btrfs subvolume create mysubvolume
# mount -o compress,subvol=mysubvolume /dev/sda8
From: Liu Bo liubo2...@cn.fujitsu.com
Only when a page is not found by page_index, we'll go to the error check.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/compression.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
If btrfs_start_workers() failed, we must stop mounting the btrfs, otherwise
the btrfs can't run well because there is no kthread to deal with the request
submited by it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/disk-io.c | 33 -
1 files changed
to deal with the
requests.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/async-thread.c | 51 +++---
1 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index eb3ec2d..49d25e6 100644
by check_pending_worker_creates()
we use __btrfs_start_workers() instead of btrfs_start_workers() to fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/async-thread.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs
On Thu, 29 Jul 2010 16:55:03 +0800, Wang Shaoyan wrote:
A prerequisite is: when first mounted file system, not specify '-o
compress' options, only on mount subvolume
Below is my test:
# mkfs.btrfs /dev/sda8
# mount /dev/sda8 btrfs
# df
Used: 56k
# btrfs subvolume create mysubvolume
# mkdir
On Thu, 29 Jul 2010 18:38:39 +0800, Yan, Zheng wrote:
2010/7/29 Miao Xiemi...@cn.fujitsu.com:
From: Liu Boliubo2...@cn.fujitsu.com
Only when a page is not found by page_index, we'll go to the error check.
Signed-off-by: Liu Boliubo2...@cn.fujitsu.com
Signed-off-by: Miao
On Mon, 26 Jul 2010 12:27:43 +0400, Kulikov Vasiliy wrote:
worker_loop() uses schedule_timeout() without setting state to
STATE_(UN)INTERRUPTIBLE. As it is called in cycle without checking of
pending signals, use schedule_timeout_uninterruptible().
Signed-off-by: Kulikov
the filesystem. I have met this kind of
problem
some time ago.
If there is no problem with your disk and memory, Could you tell us the
parameter of
mkfs.btrfs and mount?
Thanks
Miao Xie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord
that is managed by David Woodhouse.
http://git.infradead.org/users/dwmw2/btrfs-raid56.git
Regards
Miao Xie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
to initialize the blocksize of the block
device,
not the blocksize of the btrfs, so the btrfs doesn't check the blocksize of the
btrfs.
Thanks
Miao Xie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info
? though I have tested them and
everything
works well.
[PATCH 1/2] btrfs: restructure try_release_extent_buffer()
[PATCH 2/2] btrfs: fix oops when leafsize is greator than nodesize
[PATCH] btrfs-progs: fix wrong extent buffer size when reading tree block
Thanks
Miao Xie
--
To unsubscribe from
Thanks
Miao Xie
On Tue Jul 13 2010 16:55:55 GMT+0800 (CST), Miao Xie wrote:
oops occured when we ran the following commands on the filesystem whose
leafsize is greater than its nodesize.
# mkfs.btrfs -l 8192 /dev/sda1
2 * PAGESIZE
# mount /dev/sda1 /mnt
# cat /dev/zero /mnt/tmp_file0
# umount
which is
greater than the page size just like ext2/3/4, though we can use
mkfs.btrfs to make a filesystem with a big sectorsize. Am I right?
If yes, we must do more check in the mkfs.btrfs.
Thanks
Miao Xie
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
the length of the old extent buffer.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent_io.c | 90 +++--
1 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 70b7cc5..b4f1c42
restructure try_release_extent_buffer() and write a function to release the
extent buffer. It will be used later.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent_io.c | 48 +---
1 files changed, 37 insertions(+), 11 deletions
the root extent buffer of a tree may not be a leaf, so we must get the right
size by its level when reading it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
debug-tree.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/debug-tree.c b/debug-tree.c
index 40628e0
Hi,
on 2010-6-28 19:17, Dan Carpenter wrote:
The break was in front of the nr = i assignment so that was never hit.
This bug has been fixed a month ago, and the patch has been merged into the
btrfs-unstable tree.
http://marc.info/?l=linux-btrfsm=127434036913484w=2
Thanks
Miao
either -write_begin or -write
the VFS API, so we fix it by setting -write to do_sync_write().
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/file.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 79437c5..abcb918 100644
Hi, Chris
on 2010-5-27 23:15, Chris Mason wrote:
My commits here are just integrating the two and fixing a few bugs in
the result.
Zheng Yan (13) commits (+4076/-2679):
Btrfs: Integrate metadata reservation with start_transaction (+678/-528)
Btrfs: Update metadata reservation for
Hi, Chris
Could you review this patchset for us?
Regards
Miao
on 2010-5-20 15:13, Miao Xie wrote:
From: Liu Bo liubo2...@cn.fujitsu.com
Fix return value to get from read_extent_buffer_pages().
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
on 2010-5-20 16:32, Christoph Hellwig wrote:
On Thu, May 20, 2010 at 03:21:50PM +0800, Miao Xie wrote:
+if (!mapping-a_ops-readpage)
+return -ENOEXEC;
I don't think there's any instance of address_space operations without
a readpage method in btrfs.
But, Btrfs is being
on 2010-5-20 17:01, Mike Fedyk wrote:
On Thu, May 20, 2010 at 12:22 AM, Miao Xie mi...@cn.fujitsu.com wrote:
the ctime of file has not been updated when I create a link for it.
Steps to reproduce:
# touch file1
# stat -c %Z file1
1273592239
# link flink1 file1
# stat -c %Z file1
-by: Liu Bo liubo2...@cn.fujitsu.com
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/compression.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 1d54c53..1bd4d92 100644
--- a/fs/btrfs
901 - 1000 of 1023 matches
Mail list logo
