There is no reason to put this check in (!qgroup)'s else branch because if
qgroup is null, it will goto out directly. So move it out to reduce
indent.
No Functional Change.
Signed-off-by: Lu Fengqi
---
fs/btrfs/qgroup.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
There is no functional change. Just improve readablity.
PATCH 1-4 parameter cleanup patches
PATCH 5 cleanup about btrfs_select_ref_head
PATCH 6 switch int to bool; add some comment
Lu Fengqi (6):
btrfs: delayed-ref: pass delayed_refs directly to
btrfs_select_ref_head()
btrfs:
Since trans is only used for referring to delayed_refs, there is no need
to pass it instead of delayed_refs to btrfs_delayed_ref_lock().
No functional change.
Signed-off-by: Lu Fengqi
---
fs/btrfs/delayed-ref.c | 5 +
fs/btrfs/delayed-ref.h | 2 +-
fs/btrfs/extent-tree.c | 2 +-
3 files
Since trans is only used for referring to delayed_refs, there is no need
to pass it instead of delayed_refs to btrfs_select_ref_head().
No functional change.
Signed-off-by: Lu Fengqi
---
fs/btrfs/delayed-ref.c | 5 +
fs/btrfs/delayed-ref.h | 2 +-
fs/btrfs/extent-tree.c | 2 +-
3 files
If the return value of find_ref_head() is NULL, the only possibility is
that delayed_refs' head ref rbtree is empty. Hence, the second
find_ref_head() is pointless.
Besides, the local variables loop and start are unnecessary, just remove
them.
Signed-off-by: Lu Fengqi
---
The avg_delayed_ref_runtime can be referenced from the transaction handle.
Signed-off-by: Lu Fengqi
---
fs/btrfs/ctree.h | 3 +--
fs/btrfs/extent-tree.c | 5 ++---
fs/btrfs/inode.c | 5 ++---
fs/btrfs/transaction.c | 2 +-
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git
It can be referenced from the transaction handle.
Signed-off-by: Lu Fengqi
---
fs/btrfs/ctree.h | 3 +--
fs/btrfs/extent-tree.c | 6 +++---
fs/btrfs/inode.c | 2 +-
fs/btrfs/transaction.c | 2 +-
4 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ctree.h
Using bool is more suitable than int here, and add the comment about the
return_bigger.
Signed-off-by: Lu Fengqi
---
fs/btrfs/delayed-ref.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c
index
On Thu, Oct 11, 2018 at 7:14 AM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> Plumb in a remap flag that enables the filesystem remap handler to
> shorten remapping requests for callers that can handle it. Now
> copy_file_range can report partial success (in case we run up against
>
On Thu, Oct 11, 2018 at 11:26:00AM +0800, Anand Jain wrote:
> If btrfs need to be tested at its default blockgroup which is non-mixed,
> then it needs at least 256mb.
>
> Signed-off-by: Anand Jain
> ---
> v2->v3:
> separated from the patch set of 9.
> notrun for the cases where
From: Darrick J. Wong
Back when the XFS reflink code only supported clone_file_range, we were
only able to return zero or negative error codes to userspace. However,
now that copy_file_range (which returns bytes copied) can use XFS'
clone_file_range, we have the opportunity to return partial
From: Darrick J. Wong
Now that we've moved the partial EOF block checks to the VFS helpers, we
can remove the redundantn functionality from XFS.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_reflink.c | 20
1 file changed, 20 deletions(-)
diff --git
From: Darrick J. Wong
Change the ocfs2 remap code to allow for returning partial results.
Signed-off-by: Darrick J. Wong
---
fs/ocfs2/file.c |7 +
fs/ocfs2/refcounttree.c | 73 ++-
fs/ocfs2/refcounttree.h | 12
3 files
From: Darrick J. Wong
Prior to remapping blocks, it is necessary to remove pages from the
destination file's page cache. Unfortunately, the truncation is not
aggressive enough -- if page size > block size, we'll end up zeroing
subpage blocks instead of removing them. So, round the start offset
From: Darrick J. Wong
When cloning blocks into another file, truncate the page cache before we
start remapping blocks so that concurrent reads wait for us to finish.
Signed-off-by: Darrick J. Wong
---
fs/ocfs2/refcounttree.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
From: Darrick J. Wong
Prior to remapping blocks, it is necessary to remove pages from the
destination file's page cache. Unfortunately, the truncation is not
aggressive enough -- if page size > block size, we'll end up zeroing
subpage blocks instead of removing them. So, round the start offset
From: Darrick J. Wong
For a given dedupe request, the bytes_deduped field in the control
structure tells userspace if we managed to deduplicate some, but not all
of, the requested regions starting from the file offsets supplied.
However, due to sloppy coding, the current dedupe code returns
From: Darrick J. Wong
There are no callers of vfs_dedupe_file_range_compare, so we might as
well make it a static helper and remove the export.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/read_write.c| 191 ++--
From: Darrick J. Wong
Create a RFR_TO_SRC_EOF flag to explicitly declare that the caller wants
the remap implementation to remap to the end of the source file, once
the files are locked.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/ioctl.c |3 ++-
From: Darrick J. Wong
Plumb in a remap flag that enables the filesystem remap handler to
shorten remapping requests for callers that can handle it. Now
copy_file_range can report partial success (in case we run up against
alignment problems, resource limits, etc.).
Signed-off-by: Darrick J.
From: Darrick J. Wong
Plumb a remap_flags argument through the vfs_dedupe_file_range_one
functions so that dedupe can take advantage of it.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/overlayfs/file.c |3 ++-
fs/read_write.c |9 ++---
include/linux/fs.h
From: Darrick J. Wong
Pass the same remap flags to generic_remap_checks for consistency.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/read_write.c|2 +-
include/linux/fs.h |2 +-
mm/filemap.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
From: Darrick J. Wong
Change the remap_file_range functions to take a number of bytes to
operate upon and return the number of bytes they operated on. This is a
requirement for allowing fs implementations to return short clone/dedupe
results to the user, which will enable us to obey resource
From: Darrick J. Wong
Plumb a remap_flags argument through the {do,vfs}_clone_file_range
functions so that clone can take advantage of it.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/ioctl.c |2 +-
fs/nfsd/vfs.c |2 +-
fs/overlayfs/copy_up.c
From: Darrick J. Wong
Since we use clone_verify_area for both clone and dedupe range checks,
rename the function to make it clear that it's for both.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/read_write.c | 10 +-
1 file changed, 5 insertions(+), 5
From: Darrick J. Wong
Don't bother calling the filesystem for a zero-length dedupe request;
we can return zero and exit.
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
Reviewed-by: Amir Goldstein
---
fs/read_write.c |5 +
1 file changed, 5 insertions(+)
diff --git
From: Darrick J. Wong
The vfs_clone_file_prep is a generic function to be called by filesystem
implementations only. Rename the prefix to generic_ and make it more
clear that it applies to remap operations, not just clones.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
From: Darrick J. Wong
Combine the clone_file_range and dedupe_file_range operations into a
single remap_file_range file operation dispatch since they're
fundamentally the same operation. The differences between the two can
be made in the prep functions.
Signed-off-by: Darrick J. Wong
From: Darrick J. Wong
Create a new VFS helper to handle inode metadata updates when remapping
into a file. If the operation can possibly alter the file contents, we
must update the ctime and mtime and remove security privileges, just
like we do for regular file writes. Wire up ocfs2 to ensure
From: Darrick J. Wong
A deduplication data corruption is exposed by fstests generic/505 on
XFS. It is caused by extending the block match range to include the
partial EOF block, but then allowing unknown data beyond EOF to be
considered a "match" to data in the destination file because the
From: Darrick J. Wong
Move the file range checks from vfs_clone_file_prep into a separate
generic_remap_checks function so that all the checks are collected in a
central location. This forms the basis for adding more checks from
generic_write_checks that will make cloning's input checking more
From: Darrick J. Wong
vfs_clone_file_prep_inodes cannot return 0 if it is asked to remap from
a zero byte file because that's what btrfs does.
Signed-off-by: Darrick J. Wong
---
fs/read_write.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index
From: Darrick J. Wong
File range remapping, if allowed to run past the destination file's EOF,
is an optimization on a regular file write. Regular file writes that
extend the file length are subject to various constraints which are not
checked by range cloning.
This is a correctness problem
Hi all,
Dave, Eric, and I have been chasing a stale data exposure bug in the XFS
reflink implementation, and tracked it down to reflink forgetting to do
some of the file-extending activities that must happen for regular
writes.
We then started auditing the clone, dedupe, and copyfile code and
From: Darrick J. Wong
Add a "xfs_tprintk" macro so that developers can use trace_printk to
print out arbitrary debugging information with the XFS device name
attached to the trace output.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_error.h |6 ++
1 file changed, 6 insertions(+)
On Wed, Oct 10, 2018 at 9:07 PM, Larkin Lowrey
wrote:
> On 10/10/2018 10:51 PM, Chris Murphy wrote:
>>
>> On Wed, Oct 10, 2018 at 8:12 PM, Larkin Lowrey
>> wrote:
>>>
>>> On 10/10/2018 7:55 PM, Hans van Kranenburg wrote:
On 10/10/2018 07:44 PM, Chris Murphy wrote:
>
>
> I'm
On 10/11/2018 11:14 AM, Anand Jain wrote:
On 10/06/2018 07:25 PM, Eryu Guan wrote:
On Tue, Sep 25, 2018 at 12:24:16PM +0800, Anand Jain wrote:
If btrfs need to be tested at its default blockgroup which is non-mixed,
then it needs at least 256mb.
Signed-off-by: Anand Jain
(Sorry for
If btrfs need to be tested at its default blockgroup which is non-mixed,
then it needs at least 256mb.
Signed-off-by: Anand Jain
---
v2->v3:
separated from the patch set of 9.
notrun for the cases where filler is not big enough to fill the
fssize.
v2->v1: ref the
On 10/06/2018 07:25 PM, Eryu Guan wrote:
On Tue, Sep 25, 2018 at 12:24:16PM +0800, Anand Jain wrote:
If btrfs need to be tested at its default blockgroup which is non-mixed,
then it needs at least 256mb.
Signed-off-by: Anand Jain
(Sorry for the late review..)
Its fine. Sorry for the
On 10/10/2018 10:51 PM, Chris Murphy wrote:
On Wed, Oct 10, 2018 at 8:12 PM, Larkin Lowrey
wrote:
On 10/10/2018 7:55 PM, Hans van Kranenburg wrote:
On 10/10/2018 07:44 PM, Chris Murphy wrote:
I'm pretty sure you have to umount, and then clear the space_cache
with 'btrfs check
On Wed, Oct 10, 2018 at 8:12 PM, Larkin Lowrey
wrote:
> On 10/10/2018 7:55 PM, Hans van Kranenburg wrote:
>>
>> On 10/10/2018 07:44 PM, Chris Murphy wrote:
>>>
>>>
>>> I'm pretty sure you have to umount, and then clear the space_cache
>>> with 'btrfs check --clear-space-cache=v1' and then do a
On Tue, Oct 9, 2018 at 10:47 PM, Shapranov Vladimir
wrote:
> Hi,
>
> I've got a filesystem with first ~50Mb accidentally dd'ed.
>
> "btrfs check" fails with a following error (regardless of "-s"):
> checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
> checksum verify failed on
On 8/21/18 4:44 PM, Qu Wenruo wrote:
We have a complex loop design for find_free_extent(), that has different
behavior for each loop, some even includes new chunk allocation.
Instead of putting such a long code into find_free_extent() and makes it
harder to read, just extract them into
On 10/10/2018 7:55 PM, Hans van Kranenburg wrote:
On 10/10/2018 07:44 PM, Chris Murphy wrote:
I'm pretty sure you have to umount, and then clear the space_cache
with 'btrfs check --clear-space-cache=v1' and then do a one time mount
with -o space_cache=v2.
The --clear-space-cache=v1 is
On 8/21/18 4:44 PM, Qu Wenruo wrote:
This patch will extract unclsutered extent allocation code into
find_free_extent_unclustered().
And this helper function will use return value to indicate what to do
next.
This should make find_free_extent() a little easier to read.
Signed-off-by: Qu
On 8/21/18 4:44 PM, Qu Wenruo wrote:
We have two main methods to find free extents inside a block group:
1) clustered allocation
2) unclustered allocation
This patch will extract the clustered allocation into
find_free_extent_clustered() to make it a little easier to read.
Instead of
On 10/10/2018 07:44 PM, Chris Murphy wrote:
> On Wed, Oct 10, 2018 at 10:04 AM, Holger Hoffstätte
> wrote:
>> On 10/10/18 17:44, Larkin Lowrey wrote:
>> (..)
>>>
>>> About once a week, or so, I'm running into the above situation where
>>> FS seems to deadlock. All IO to the FS blocks, there is no
On 2018/10/10 下午12:47, Shapranov Vladimir wrote:
> Hi,
>
> I've got a filesystem with first ~50Mb accidentally dd'ed.
So about 49M meta/data loss.
It depends on the chunk layout. If it got one metadata chunk wiped out,
it's pretty hard to repair.
If it only wiped several data chunks, it
On 2018/10/11 上午1:25, Larkin Lowrey wrote:
> On 10/10/2018 12:04 PM, Holger Hoffstätte wrote:
>> On 10/10/18 17:44, Larkin Lowrey wrote:
>> (..)
>>> About once a week, or so, I'm running into the above situation where
>>> FS seems to deadlock. All IO to the FS blocks, there is no IO
>>> activity
On Wed, Oct 10, 2018 at 12:31 PM, Larkin Lowrey
wrote:
> Interesting, because I do not see any indications of any other errors. The
> fs is backed by an mdraid array and the raid checks always pass with no
> mismatches, edac-util doesn't report any ECC errors, smartd doesn't report
> any SMART
On 10/10/2018 2:20 PM, Holger Hoffstätte wrote:
On 10/10/18 19:25, Larkin Lowrey wrote:
On 10/10/2018 12:04 PM, Holger Hoffstätte wrote:
On 10/10/18 17:44, Larkin Lowrey wrote:
(..)
About once a week, or so, I'm running into the above situation where
FS seems to deadlock. All IO to the FS
On 10/10/18 19:44, Chris Murphy wrote:
On Wed, Oct 10, 2018 at 10:04 AM, Holger Hoffstätte
wrote:
On 10/10/18 17:44, Larkin Lowrey wrote:
(..)
About once a week, or so, I'm running into the above situation where
FS seems to deadlock. All IO to the FS blocks, there is no IO
activity at all. I
On 10/10/18 19:25, Larkin Lowrey wrote:
On 10/10/2018 12:04 PM, Holger Hoffstätte wrote:
On 10/10/18 17:44, Larkin Lowrey wrote:
(..)
About once a week, or so, I'm running into the above situation where
FS seems to deadlock. All IO to the FS blocks, there is no IO
activity at all. I have to
On Wed, Oct 10, 2018 at 10:04 AM, Holger Hoffstätte
wrote:
> On 10/10/18 17:44, Larkin Lowrey wrote:
> (..)
>>
>> About once a week, or so, I'm running into the above situation where
>> FS seems to deadlock. All IO to the FS blocks, there is no IO
>> activity at all. I have to hard reboot the
On 10/10/2018 12:04 PM, Holger Hoffstätte wrote:
On 10/10/18 17:44, Larkin Lowrey wrote:
(..)
About once a week, or so, I'm running into the above situation where
FS seems to deadlock. All IO to the FS blocks, there is no IO
activity at all. I have to hard reboot the system to recover. There
On 10/10/18 17:44, Larkin Lowrey wrote:
(..)
About once a week, or so, I'm running into the above situation where
FS seems to deadlock. All IO to the FS blocks, there is no IO
activity at all. I have to hard reboot the system to recover. There
are no error indications except for the following
On 9/11/2018 11:23 AM, Larkin Lowrey wrote:
On 8/29/2018 1:32 AM, Qu Wenruo wrote:
On 2018/8/28 下午9:56, Chris Murphy wrote:
On Tue, Aug 28, 2018 at 7:42 AM, Qu Wenruo
wrote:
On 2018/8/28 下午9:29, Larkin Lowrey wrote:
On 8/27/2018 10:12 PM, Larkin Lowrey wrote:
On 8/27/2018 12:46 AM, Qu
I've just hit this on a backup server. I suspect something would have
been trying to remove/create a snapshot at the time.
I'll ignorantly assume it's similar to the last one I posted (
https://www.spinics.net/lists/linux-btrfs/msg82636.html ) although the
trace is different.
David.
On 2018/10/10 下午4:51, Su Yue wrote:
>
>
> On 8/21/18 4:44 PM, Qu Wenruo wrote:
>> Instead of tons of different local variables in find_free_extent(),
>> extract them into find_free_extent_ctrl structure, and add better
>> explanation for them.
>>
>> Some modification may looks redundant, but
On 8/21/18 4:44 PM, Qu Wenruo wrote:
Instead of tons of different local variables in find_free_extent(),
extract them into find_free_extent_ctrl structure, and add better
explanation for them.
Some modification may looks redundant, but will later greatly simplify
function parameter list
60 matches
Mail list logo
