On Wed, Mar 15, 2017 at 11:01:05AM +0800, Qu Wenruo wrote:
> Any comment on this patch?
It's already committed, see commit 726726d.
Thanks,
Eryu
--
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
Any comment on this patch?
Thanks,
Qu
At 03/08/2017 10:20 AM, Qu Wenruo wrote:
This test case will test if file system works well when handling large
write while available space are all fragmented.
This can expose a bug in a btrfs unmerged patch, which wrongly modified
the delayed allocation c
At 03/15/2017 10:27 AM, Liu Bo wrote:
On Wed, Mar 15, 2017 at 08:57:09AM +0800, Qu Wenruo wrote:
At 03/15/2017 04:33 AM, Liu Bo wrote:
We have similar code here and there, this merges them into a helper.
Signed-off-by: Liu Bo
I really hate to delay the merge, but unfortunately it seems
On Wed, Mar 15, 2017 at 08:57:09AM +0800, Qu Wenruo wrote:
>
>
> At 03/15/2017 04:33 AM, Liu Bo wrote:
> > We have similar code here and there, this merges them into a helper.
> >
> > Signed-off-by: Liu Bo
>
> I really hate to delay the merge, but unfortunately it seems that
> read_one_chunk()
At 03/15/2017 04:33 AM, Liu Bo wrote:
We have similar code here and there, this merges them into a helper.
Signed-off-by: Liu Bo
I really hate to delay the merge, but unfortunately it seems that
read_one_chunk() still contains the open code.
Sorry I didn't find it in previous version.
D
At 03/14/2017 07:55 PM, David Sterba wrote:
On Tue, Mar 14, 2017 at 12:55:06PM +0100, David Sterba wrote:
On Tue, Mar 14, 2017 at 04:05:02PM +0800, Qu Wenruo wrote:
v2:
Abstract the original code to read out data in one btrfs file to
btrfs_read_file().
Use simple_range and btrfs_reserve
On 2017-03-14 14:47, David Sterba wrote:
> On Tue, Mar 07, 2017 at 11:48:37AM +0800, Qu Wenruo wrote:
>> So raid56 bug fixes are the same case as qgroup fixes now?
>
> Not now, it's been like that forever. Or should have been, we're not
> perfect, but should strive not to skip reviews just because
These two BUG_ON()s would never be true, ensured by callers' logic.
Reviewed-by: Qu Wenruo
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 10f69d1..61b96ec 100644
--- a/fs/btrfs/vo
As the part of getting extra mirror in __btrfs_map_block is
self-independent, this puts it into a separate function.
Reviewed-by: Qu Wenruo
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 161 +
1 file changed, 89 insertions(+), 72 deletions(-)
This adds a helper to show directly whether ops require full stripe.
Reviewed-by: Qu Wenruo
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index bc9d6fc..10f69d1 100644
Since this part is mostly self-independent, this moves it to a separate
function.
Reviewed-by: Qu Wenruo
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 179 +
1 file changed, 98 insertions(+), 81 deletions(-)
diff --git a/fs/btrfs/volumes.c b
We have similar code here and there, this merges them into a helper.
Signed-off-by: Liu Bo
---
v2: add @length to the error message in get_chunk_map.
fs/btrfs/extent_io.c | 3 +-
fs/btrfs/volumes.c | 163 +--
fs/btrfs/volumes.h | 2 +-
3 f
Since DISCARD is not as important as an operation like write, we don't
copy it to target device during replace, and it makes __btrfs_map_block
less complex.
Signed-off-by: Liu Bo
---
v2:
- use the helper get_chunk_map to simplify code
- use round_up instead of ALIGN.
fs/btrfs/volumes.c | 289 ++
This is attempting to make __btrfs_map_block less scary :)
The major changes are
1) split operations for discard out of __btrfs_map_block and we don't copy
discard operations for the target device of dev replace since they're not
as important as writes.
2) put dev replace stuff into helpers sinc
With this, we can avoid allocating memory for dev replace copies if the
target dev is not available.
Reviewed-by: Qu Wenruo
Signed-off-by: Liu Bo
---
fs/btrfs/volumes.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 2fae6
On Thu, Feb 23, 2017 at 12:07:35AM +0100, Benedikt Morbach wrote:
> clone needs to resolve the paths of the involved subvolumes in the target
> fs from their UUIDs. When doing so it might need to strip the prefix
> that is mounted as the root of the fs from those paths.
>
> It didn't do so correct
On Fri, Feb 17, 2017 at 05:28:14PM -0800, Liu Bo wrote:
> This is attempting to make __btrfs_map_block less scary :)
>
> The major changes are
>
> 1) split operations for discard out of __btrfs_map_block and we don't copy
> discard operations for the target device of dev replace since they're not
From: Goldwyn Rodrigues
We are facing the same problem with EDQUOT which was experienced with
ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but
here is a fix. Let me know if it is too big a hammer.
Quotas are reserved during the start of an operation, incrementing
qg->re
On 03/14/2017 12:37 AM, Eryu Guan wrote:
> [please cc linux-btrfs@vger.kernel.org for btrfs specific tests]
>
> On Mon, Mar 13, 2017 at 04:37:16PM -0500, Goldwyn Rodrigues wrote:
>> From: Goldwyn Rodrigues
>>
>> If we create and delete files within the qgroup limits, qg->reserved
>> (allocation
On Tue, Mar 14, 2017 at 08:31:26AM -0500, Goldwyn Rodrigues wrote:
>
>
> On 03/14/2017 07:30 AM, David Sterba wrote:
> > On Tue, Mar 14, 2017 at 05:25:09AM -0500, Goldwyn Rodrigues wrote:
> >> From: Goldwyn Rodrigues
> >>
> >> Using an int value is causing qg->reserved to become negative and
> >
On Tue, Mar 07, 2017 at 11:48:37AM +0800, Qu Wenruo wrote:
> So raid56 bug fixes are the same case as qgroup fixes now?
Not now, it's been like that forever. Or should have been, we're not
perfect, but should strive not to skip reviews just because we want to
let new code in.
> No reviewer so no
On Tue, Mar 14, 2017 at 10:23 AM, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> We are facing the same problem with EDQUOT which was experienced with
> ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but
> here is a fix. Let me know if it is too big a hammer.
>
> Q
On Wed, Mar 08, 2017 at 08:28:21AM +0800, Qu Wenruo wrote:
> >> But I must say, that's very frustrating to see bug fixes just get dropped
> >> again and again just due to new cleanups and lack of reviewers.
> >
> > That's life of a kernel developer.
>
> Right, that's life.
>
> That's also why I l
On 03/14/2017 07:30 AM, David Sterba wrote:
> On Tue, Mar 14, 2017 at 05:25:09AM -0500, Goldwyn Rodrigues wrote:
>> From: Goldwyn Rodrigues
>>
>> Using an int value is causing qg->reserved to become negative and
>> exclusive -EDQUOT to be reached prematurely.
>
> V1 had a reproducer, I think it
On Wed, Mar 08, 2017 at 09:24:05AM -0500, Jeff Mahoney wrote:
> On 3/6/17 3:08 AM, Qu Wenruo wrote:
> > Any response?
> >
> > These patches are already here for at least 2 kernel releases.
> > And are all bug fixes, and fix bugs that are already reported.
> >
> > I didn't see any reason why it sh
On Fri, Mar 10, 2017 at 11:09:48AM -0800, Liu Bo wrote:
> While debugging truncate problems, I found that these tracepoints could
> help us quickly know what went wrong.
>
> Two sets of tracepoints are created to track regular/prealloc file item
> and inline file item respectively, I put inline as
On Tue, Mar 14, 2017 at 05:25:09AM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Using an int value is causing qg->reserved to become negative and
> exclusive -EDQUOT to be reached prematurely.
V1 had a reproducer, I think it's fine to keep it here so I'll copy it.
Reviewed-by:
On Tue, Mar 14, 2017 at 05:23:50AM -0500, Goldwyn Rodrigues wrote:
> @@ -2402,6 +2404,19 @@ static int qgroup_reserve(struct btrfs_root *root, u64
> num_bytes, bool enforce)
> qg = unode_aux_to_qgroup(unode);
>
> if (enforce && !qgroup_check_limits(qg, num_bytes)) {
>
On Tue, Mar 14, 2017 at 02:35:33PM +0530, Chandan Jay Sharma wrote:
> This commit impliments FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR ioctls for
> BTRFS.
Can you please write more about what's the usecase and what's the
difference against normal XATTRs that btrfs already support?
Description, link
On Tue, Mar 14, 2017 at 12:55:06PM +0100, David Sterba wrote:
> On Tue, Mar 14, 2017 at 04:05:02PM +0800, Qu Wenruo wrote:
> > v2:
> > Abstract the original code to read out data in one btrfs file to
> > btrfs_read_file().
> > Use simple_range and btrfs_reserved_ranges[] to cleanup open code.
On Tue, Mar 14, 2017 at 04:05:02PM +0800, Qu Wenruo wrote:
> v2:
> Abstract the original code to read out data in one btrfs file to
> btrfs_read_file().
> Use simple_range and btrfs_reserved_ranges[] to cleanup open code.
> v3:
> Rebased to v4.10.
> Squash modification in later commits to
From: Goldwyn Rodrigues
Using an int value is causing qg->reserved to become negative and
exclusive -EDQUOT to be reached prematurely.
Signed-off-by: Goldwyn Rodrigues
---
Changes since v1:
- changed reserved from long to u64
fs/btrfs/ctree.h | 2 +-
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/
From: Goldwyn Rodrigues
We are facing the same problem with EDQUOT which was experienced with
ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but
here is a fix. Let me know if it is too big a hammer.
Quotas are reserved during the start of an operation, incrementing
qg->re
At 03/14/2017 05:06 PM, Stefan Priebe - Profihost AG wrote:
Thanks Qu, removing BTRFS_I from the inode fixes this issue to me.
Greets,
Stefan
Glad to hear that.
And a small tip is, when compiling kernel(at least btrfs module), any
warning should be checked carefully.
Such type mismatch
Thanks Qu, removing BTRFS_I from the inode fixes this issue to me.
Greets,
Stefan
Am 14.03.2017 um 03:50 schrieb Qu Wenruo:
>
>
> At 03/13/2017 09:26 PM, Stefan Priebe - Profihost AG wrote:
>>
>> Am 13.03.2017 um 08:39 schrieb Qu Wenruo:
>>>
>>>
>>> At 03/13/2017 03:26 PM, Stefan Priebe - Prof
This commit impliments FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR ioctls for BTRFS.
Signed-off-by: Chandan Jay Sharma
---
fs/btrfs/ioctl.c | 146 +++
1 file changed, 146 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 33f967d
At 03/13/2017 03:42 PM, Anand Jain wrote:
Now when counting number of error devices we don't need to count
them separately once during send and wait, as because device error
counted during send is more of static check.
Also kindly note that as of now there is no code which would set
dev->bdev
At 03/13/2017 03:42 PM, Anand Jain wrote:
The only error that write dev flush (send) will fail is due
to the ENOMEM then, as its not a device specific error and
rather a system wide issue, we should rather stop further
iterations and perpetuate the -ENOMEM error to the caller.
Signed-off-by: A
At 03/14/2017 04:26 PM, Anand Jain wrote:
The objective of this patch is to cleanup barrier_all_devices()
so that the error checking is in a separate loop independent of
of the loop which submits and waits on the device flush requests.
By doing this it helps to further develop patches which wo
The objective of this patch is to cleanup barrier_all_devices()
so that the error checking is in a separate loop independent of
of the loop which submits and waits on the device flush requests.
By doing this it helps to further develop patches which would tune
the error-actions as needed.
Here fu
The patchset can be fetched from my github, based on v4.10 now.
https://github.com/adam900710/btrfs-progs/tree/rollback_rework_v4.10
Rework rollback to provide a easier to understand new mechnisim, which can
handle both old convert behavior and new convert behavior.
And with these patchset, we ca
Convert is now a little complex due to that fact we need to separate
meta and data chunks for different profiles.
Add a comment with ascii art explaining the whole workflow and points
out the really complex part, so any newcomers interested in convert can
get a quick overview of it before digging
Introduce a new function, btrfs_read_file(), to read out data of a file
inode.
This function will iterate through EXTENT_DATA items and handle
inline/prealloc/hole file extents.
Compression is not supported yet.
Signed-off-by: Qu Wenruo
---
ctree.h | 2 +
file.c | 169 ++
Introduce a new function, read_reserved_ranges(), to allow later
rollback to use these data to do rollback.
Signed-off-by: Qu Wenruo
---
convert/main.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/convert/main.c b/convert/main.c
index e834c6f9..505b4a70 10
Since we have reserved ranges array now, we can use them to skip all
these open codes.
And add some comment and asciidoc art for related part.
Signed-off-by: Qu Wenruo
---
convert/main.c | 138 ++---
1 file changed, 63 insertions(+), 75 deleti
Rework rollback to a more easy to understand way.
New convert behavior makes us to have a more flex chunk layout, which
only data chunk containing old fs data will be at the same physical
location, while new chunks (data/meta/sys) can be mapped anywhere else.
This behavior makes old rollback beha
Introduce a new strucutre, simple_range, to present one continuous
range.
Also, use such structure to define btrfs_reserved_ranges(), which
convert and rollback will use.
Suggested-by: David Sterba
Signed-off-by: Qu Wenruo
---
convert/common.h | 27 +++
convert/main.c
Introduce a function, check_convert_image() to check if that image is
rollback-able.
This means all file extents excepts one in btrfs reserved ranges, must
be mapped 1:1 on disk.
1:1 mapped file extents must match the following condition:
1) Their file_offset(key.offset) matches its disk_bytenr
2
48 matches
Mail list logo