return ret;
2212 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
From 620ff16527bd711e7b6677ba7d5ecfb4467c231a Mon Sep 17 00:00:00 2001
From: Gerhard Heift gerh...@heift.name
2014-01-30 Gerhard Heift gerh...@heift.name:
By copying each found item seperatly to userspace, we do not need extra
memory in the kernel. This allows to run a large search inside of a single
call.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 52
This patch series first rewrites tree_search to copy found items directly to
userspace and then adds a new ioctl TREE_SEARCH_V2 with which we could store
them in a varying buffer. Now even items larger than 3992 bytes or a large
amount of items can be returned. This is the case for some
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index b1c5b4f..9b66eac 100644
--- a/fs/btrfs
this buffer are for
example some of the type EXTENT_CSUM.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 40
include/uapi/linux/btrfs.h | 10 ++
2 files changed, 50 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs
By copying each found item seperatly to userspace, we do not need extra
buffer in the kernel.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs
If the amount of items reached the given limit of nr_items, we can leave
copy_to_sk without updating the key. Also by returning 1 we leave the loop in
search_ioctl without rechecking if we reached the given limit.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 12
If an item in tree_search is too large to be stored in the given buffer, return
the needed size (including the header).
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
If an item in tree_search is too large to be stored in the given buffer, return
the needed size (including the header).
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs
This patch series adds a new ioctl TREE_SEARCH_V2 with which we could store the
results in a varying buffer. With that even items larger than 3992 bytes or a
large amount of items can be returned. This is the case e.g. for some
EXTENT_CSUM items, which could have a size up to 16k.
I had a few
this buffer are for
example some of the type EXTENT_CSUM.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 40
include/uapi/linux/btrfs.h | 10 ++
2 files changed, 50 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 34772cb..6aa79e0 100644
--- a/fs/btrfs
This new function reads the content of an extent directly to user memory.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/extent_io.c | 37 +
fs/btrfs/extent_io.h | 3 +++
2 files changed, 40 insertions(+)
diff --git a/fs/btrfs/extent_io.c b/fs
By copying each found item seperatly to userspace, we do not need extra
memory in the kernel. This allows to run a large search inside of a single call.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 52
1 file changed
(as suggested in [2]) will eliminate the
double-copy of data and needs less memory in the kernel.
[1] http://article.gmane.org/gmane.comp.file-systems.btrfs/31765
[2] http://article.gmane.org/gmane.comp.file-systems.btrfs/32064
Thanks, Anand
On 01/27/2014 09:28 PM, Gerhard Heift wrote
This patch series adds a new ioctl TREE_SEARCH_V2 with which we could store the
results in a varying buffer. Now even items larger than 3992 bytes or a large
amount of items can be returned.
I have a few questions:
Which value should I assign to TREE_SEARCH_V2?
Should we limit the buffer
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 3970f32..be4c780 100644
--- a/fs/btrfs
To prevent unexpectet values in the unused fields of the search key fail early.
Otherwise future extensions would break the behavior of the search if current
implementations in userspace set them to values other than zero.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 3
Instead of allocting and releasing a buffer for each leaf, which will be
visited during a search, allocate (and expand) a buffer for the whole search.
This saves a few allocations and deallocations during larger searchs, which
visits more leafs.
Signed-off-by: Gerhard Heift gerh...@heift.name
By copying each found item seperatly to userspace, we only need a small buffer
in the kernel. This allows to run a large search inside of a single call.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 107 ---
1 file
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 919d928
is limited to 32 pages.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 48 ++
include/uapi/linux/btrfs.h | 8
2 files changed, 56 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 9fa222d
2014-01-27 David Sterba dste...@suse.cz:
On Mon, Jan 27, 2014 at 02:28:28PM +0100, Gerhard Heift wrote:
To prevent unexpectet values in the unused fields of the search key fail
early.
Otherwise future extensions would break the behavior of the search if current
implementations in userspace
2014-01-27 David Sterba dste...@suse.cz:
On Mon, Jan 27, 2014 at 02:28:30PM +0100, Gerhard Heift wrote:
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2032,6 +2032,52 @@ static noinline int btrfs_ioctl_tree_search(struct
file *file,
return ret;
}
+static noinline int
2014-01-27 David Sterba dste...@suse.cz:
On Mon, Jan 27, 2014 at 02:28:31PM +0100, Gerhard Heift wrote:
By copying each found item seperatly to userspace, we only need a small
buffer
in the kernel. This allows to run a large search inside of a single call.
Signed-off-by: Gerhard Heift gerh
This patch series adds a new ioctl TREE_SEARCH_V2 with which we could store the
results in a varying buffer. Now even items larger than 3992 bytes or a large
amount of items can be returned.
I have a few questions:
Which value should I assign to TREE_SEARCH_V2?
Should we limit the buffer
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 3970f32..be4c780 100644
--- a/fs/btrfs
By copying each found item seperatly to userspace, we only need a small amount
of memory in the kernel. This allows to run a large search inside of a single
call.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 105 +--
1
To prevent unexpectet values in the unused fields of the search key fail early.
Otherwise future extensions would break the behavior of the search if current
implementations in userspace set them to values other than zero.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 3
is limited to 32 pages.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 48 ++
include/uapi/linux/btrfs.h | 8
2 files changed, 56 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 9fa222d
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift gerh...@heift.name
---
fs/btrfs/ioctl.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 919d928
;
__u64 buf_len
char __user *buf;
};
And against which commit should I rebase them?
2014/1/15 David Sterba dste...@suse.cz:
On Fri, Jan 10, 2014 at 12:44:17AM +0100, Gerhard Heift wrote:
I'm playing around with the BTRFS_IOC_SEARCH_TREE to extract the csums
of the physical blocks. During
2014/1/15 David Sterba dste...@suse.cz:
The owner and capability checks in IOC_SUBVOL_SETFLAGS and
SET_RECEIVED_SUBVOL should be called before any other checks are done.
Also unify the error code to EPERM.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ioctl.c | 22
2014/1/6 David Sterba dste...@suse.cz:
On Mon, Jan 06, 2014 at 12:02:51AM +0100, Gerhard Heift wrote:
I am currently playing with snapshots and manual deduplication of
files. During these tests I noticed the change of ctime and mtime in
the snapshot after the deduplication
Hello,
I'm playing around with the BTRFS_IOC_SEARCH_TREE to extract the csums
of the physical blocks. During the tests some item_header had len = 0,
which indicates the buffer was to small to hold the item. I added a
printk into the kernel to get the original size of the item and it was
around
Hello,
I am currently playing with snapshots and manual deduplication of
files. During these tests I noticed the change of ctime and mtime in
the snapshot after the deduplication with FILE_EXTENT_SAME. Does this
happens on purpose? Otherwise I would like to have ctime and mtime
left unmodified,
38 matches
Mail list logo
