Don't bother zeroing the page if it's already a hole under there.
We can save one allocation from this.
Signed-off-by: Li Dongyang jerry87...@gmail.com
---
fs/btrfs/inode.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 85a1e50
We should look at path-slots[0] rather than path-slots[0]+1 while trying to
merge with the hole behind us.
Also this patch will delete the the latter one if we can merge with both front
and back, leaving one hole covers all three.
Signed-off-by: Li Dongyang jerry87...@gmail.com
---
fs/btrfs
On Tuesday, June 21, 2011 01:49:19 PM Li Zefan wrote:
We're taking a free space extent out of the free space cache, trimming
it and then putting it back into the cache.
sorry for the late reply, I can hardly to find time look at this.
However for an extent that is smaller than the specified
from
blkdev_issue_discard.
This won't affect the return value of fstrim on the drives without DISCARD,
because we've already checked that in btrfs_ioctl_fitrim, Thanks
Changes v2:
better name for the discard flag
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/extent-tree.c | 24
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
from
blkdev_issue_discard.
This won't affect the return value of fstrim on the drives without DISCARD,
because we've already checked that in btrfs_ioctl_fitrim, Thanks
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/extent-tree.c | 24
fs/btrfs/volumes.c
On Friday, June 10, 2011 08:00:17 AM David Sterba wrote:
On Thu, Jun 09, 2011 at 03:28:09PM +0800, Li Dongyang wrote:
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -45,6 +45,7 @@ struct btrfs_device {
int running_pending;
u64 generation;
+ int discard;
can you
On Friday, May 20, 2011 10:15:46 PM Josef Bacik wrote:
On 05/20/2011 07:52 AM, David Sterba wrote:
On Wed, May 18, 2011 at 11:29:14AM +0800, Li Dongyang wrote:
Thanks for the fix, I thought EOPNOTSUPP could be useful by the caller
that time, and maybe we could do somthing like remove
On Wednesday, May 18, 2011 12:00:31 AM David Sterba wrote:
xfstests/013 crashes when the test partition is mounted with -o discard:
walk_up_log_tree
btrfs_free_reserved_extent
btrfs_discard_extent
return -EOPNOTSUPP
BUG_ON ret
btrfs_discard_extent() should be fine when
stupid, thanks for fixing ;-)
Br,
Li Dongyang
BTW, I just rebased this so the incremental fix was before merging into
Linus' tree.
-chris
-chris
Thanks!
-chris
Changelog V4:
*make btrfs_map_block() return full mapping.
Changelog V3:
*fix
We take an free extent out from allocator, trim it, then put it back,
but before we trim the block group, we should make sure the block group is
cached, so plus a little change to make cache_block_group() run without a
transaction.
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs
btrfs_map_block() will only return a single stripe length, but we want the
full extent be mapped to each disk when we are trimming the extent,
so we add length to btrfs_bio_stripe and fill it if we are mapping for
REQ_DISCARD.
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs
is not a EOPNOTSUPP
2. no device supports discard
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/disk-io.c |5 -
fs/btrfs/extent-tree.c | 45 ++---
3 files changed, 31 insertions(+), 21 deletions(-)
diff --git
Dear list,
This is V4 of batched discard support, now we will get full mapping of
the free space on each device for RAID0/1/10/DUP instead of just a single
stripe length, and tested with xfsstests 251, Thanks.
Changelog V4:
*make btrfs_map_block() return full mapping.
Changelog V3:
*fix
Make the function public as we should update the reserved extents calculations
after taking out an extent for trimming.
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/ctree.h|2 ++
fs/btrfs/extent-tree.c | 16 +++-
2 files changed, 9 insertions(+), 9
the extent stripe by stripe, or make the free extent be mapped as a whole,
and that could been done in another patch, Thanks.
Signed-off-by: Li Dongyang lidongy...@novell.com
Reviewed-by: David Sterba dste...@suse.cz
Reviewed-by: Kurt Garloff garl...@suse.de
---
Changelog V3:
*fix style problems
On Friday, February 25, 2011 04:16:27 PM Li Dongyang wrote:
Thanks for your comments, here is the updated patch.
I've tested it with xfstests 251(thanks to Lukas), and it looks fine to me.
when we call btrfs_map_block() for RAID0/1/10/ or DUP, it only returns a single
stripe
length at most
Thanks for your comments, here is the updated patch.
I've tested it with xfstests 251(thanks to Lukas), and it looks fine to me.
Signed-off-by: Li Dongyang lidongy...@novell.com
Reviewed-by: David Sterba dste...@suse.cz
Reviewed-by: Kurt Garloff garl...@suse.de
---
Changelog V2:
*Check if we
we should recalculate the thresholds everytime when we add/free a bitmap,
make sure we do this in btrfs_remove_free_space() by calling
free_bitmap(),Thanks
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/free-space-cache.c | 10 +-
1 files changed, 5 insertions(+), 5
this
should be fixed, Thanks.
Signed-off-by: Li Dongyang lidongy...@novell.com
---
fs/btrfs/ctree.h|3 +-
fs/btrfs/disk-io.c |5 ++-
fs/btrfs/extent-tree.c | 81 ---
fs/btrfs/free-space-cache.c | 79
Have a look at line 998, ioctl.c, inside btrfs_ioctl_clone(),
the src-i_size(the size of the testfile created by touch) is just 0, and this
will cause btrfs_ioctl_clone just return -EINVAL.
I'm not sure if it makes sense to clone a file which actually doesn't have any
data extents.
On Wednesday
fix comipler warning with tree_search
Signed-off-by: Li Dongyang jerry87...@gmail.com
---
fs/btrfs/ordered-data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index ab21c29..8877fa0 100644
--- a/fs/btrfs/ordered
we should not make a raid0 array go below 2 devices.
Signed-off-by: Li Dongyang jerry87...@gmail.com
---
fs/btrfs/volumes.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 20cbd2e..801b8d0 100644
--- a/fs/btrfs
23 matches
Mail list logo