ULT;
> 2210
> 2211 return ret;
> 2212 }
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
From 620ff16527bd711e7b6677ba7d5ecfb4467c231a Mon Sep
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift
---
fs/btrfs/ioctl.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 9b66eac..4e32ac2
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
---
fs/btrfs/ioctl.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/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
---
fs/btrfs/ioctl.c | 12 +++-
1 file
By copying each found item seperatly to userspace, we do not need extra
buffer in the kernel.
Signed-off-by: Gerhard Heift
---
fs/btrfs/ioctl.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs
this buffer are for
example some of the type EXTENT_CSUM.
Signed-off-by: Gerhard Heift
---
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/btrfs/ioctl.c
index
This new function reads the content of an extent directly to user memory.
Signed-off-by: Gerhard Heift
---
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/btrfs/extent_io.c
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift
---
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/ioctl.c
+++ b/fs
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 EXTENT_CSUM
2014-01-30 Gerhard Heift :
> 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
> ---
>
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift
---
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/ioctl.c
+++ b/fs
This new function reads the content of an extent directly to user memory.
Signed-off-by: Gerhard Heift
---
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/btrfs/extent_io.c
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
---
fs/btrfs/ioctl.c | 52
1 file changed, 36 insertions
this buffer are for
example some of the type EXTENT_CSUM.
Signed-off-by: Gerhard Heift
---
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/btrfs/ioctl.c
index
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
---
fs/btrfs/ioctl.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/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 ques
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift
---
fs/btrfs/ioctl.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 6aa79e0..04e1a98
ted 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 wro
2014-01-27 David Sterba :
> 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.
>>
>
2014-01-27 David Sterba :
> 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;
2014-01-27 David Sterba :
> 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
>> imple
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
---
fs/btrfs/ioctl.c | 107 ---
1 file changed, 71 insertions
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift
---
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..9fa222d 100644
is limited to 32 pages.
Signed-off-by: Gerhard Heift
---
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..c44fcdd 100644
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift
---
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/ioctl.c
+++ b/fs
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
---
fs/btrfs/ioctl.c | 3 +++
1 file
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
---
fs/btrfs/ioctl.c
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 size?
.
tree_search changes -EOVERFLOW back to 0 to behave similiar to the way it
behaved before this patch.
Signed-off-by: Gerhard Heift
---
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..9fa222d 100644
rewrite search_ioctl to accept a buffer with varying size
Signed-off-by: Gerhard Heift
---
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/ioctl.c
+++ b/fs
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
---
fs/btrfs/ioctl.c | 105 +--
1 file changed, 71
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
---
fs/btrfs/ioctl.c | 3 +++
1 file
is limited to 32 pages.
Signed-off-by: Gerhard Heift
---
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..cc82bd9 100644
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 size?
2014/1/15 David Sterba :
> 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
> ---
> fs/btrfs/ioctl.c | 22 +-
> 1 file cha
;
__u64 buf_len
char __user *buf;
};
And against which commit should I rebase them?
2014/1/15 David Sterba :
> 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. D
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 660
2014/1/6 David Sterba :
> 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 with F
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, be
39 matches
Mail list logo
