On Oct 1, 2018, at 9:49 AM, Eric Sandeen wrote:
>
>
> On 10/1/18 9:48 AM, Qu Wenruo wrote:
>>
>>
>> On 2018/10/1 下午10:32, Joshi wrote:
>>> I was wondering about the cross-fs copy through copy_file_range.
>>
>> The term "cross-fs" looks pretty confusing.
>>
>> If you mean
On Fri, Sep 28, 2018 at 07:17:47AM -0400, Josef Bacik wrote:
> For enospc_debug having the block rsvs is super helpful to see if we've
> done something wrong.
>
> Signed-off-by: Josef Bacik
> Reviewed-by: Omar Sandoval
Reviewed-by: David Sterba
On 10/1/18 9:48 AM, Qu Wenruo wrote:
>
>
> On 2018/10/1 下午10:32, Joshi wrote:
>> I was wondering about the cross-fs copy through copy_file_range.
>
> The term "cross-fs" looks pretty confusing.
>
> If you mean "cross-subvolume", then it should work without problem in btrfs.
>
> If you mean
Sorry if my post was not clear enough. I picked the term "cross-fs"
from the implementation of vfs_copy_file_range.
Below snippet, inside vfs_copy_file_range -
1578 /* this could be relaxed once a method supports cross-fs copies */
1579 if (inode_in->i_sb != inode_out->i_sb)
1580
On 2018/10/1 下午10:32, Joshi wrote:
> I was wondering about the cross-fs copy through copy_file_range.
The term "cross-fs" looks pretty confusing.
If you mean "cross-subvolume", then it should work without problem in btrfs.
If you mean reflink across two different file systems (not matter the
Hello,
Here is the v2 of the freespace tree repair support patches. Version 1 can be
found at [0]. For background on the series please refer to the initial cover
letter. This time round a number of changes have been incorporated based on
feedback from Omar. Namely:
1. Added 2 new patches,
This commit introduces explicit little endian bit operations. The only
difference with the existing bitops implementation is that bswap(32|64)
is called when the _le versions are invoked on a big-endian machine.
This is in preparation for adding free space tree conversion support.
Signed-off-by:
The RO_FREE_SPACE_TREE(_VALID) flags are required in order to be able
to open an FST filesystem in repair mode. Add them to
BTRFS_FEATURE_COMPAT_RO_SUPP.
Signed-off-by: Nikolay Borisov
---
ctree.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ctree.h b/ctree.h
index
Now that all the prerequisite code for proper support of free space
tree repair is in, it's time to wire it in. This is achieved by first
hooking the freespace tree to the __free_extent/alloc_reserved_tree_block
functions. And then introducing a wrapper function to contains the
existing
Similarly to the fix in e444c7bfa65f ("btrfs-progs: check: Fix wrong
error message in case of corrupted extent") this commits addresses the
same problem but for corrupted bitmap objects.
Signed-off-by: Nikolay Borisov
---
free-space-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
To help implement free space tree checker in user space some kernel
function are necessary, namely iterating/deleting/adding freespace
items, some internal search functions. Functions to populate a block
group based on the extent tree. The code is largely copy/paste from
the kernel with locking
Replace existing find_*_bit functions with kernel equivalent. This
reduces duplication, simplifies the code (we really have one worker
function _find_next_bit) and is quite likely faster. No functional
changes.
Signed-off-by: Nikolay Borisov
---
kernel-lib/bitops.h | 142
Simple test case which preps a filesystem, then corrupts the FST and
finally repairs it. Tests both extent based and bitmap based FSTs.
Signed-off-by: Nikolay Borisov
---
tests/fsck-tests/036-freespacetree-repair/test.sh | 76 +++
1 file changed, 76 insertions(+)
create
Those functions are in preparation for adding the freespace tree
repair code since it needs to be able to deal with bitmap based fsts.
This patch adds extent_buffer_bitmap_set and extent_buffer_bitmap_clear
functions. Since in userspace we don't have to deal with page mappings
their implementation
For completeness sake add code to btrfs_read_fs_root so that it can
handle the freespace tree.
Signed-off-by: Nikolay Borisov
---
disk-io.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/disk-io.c b/disk-io.c
index 2e6d56a36af9..14f0fd5c2f0c 100644
--- a/disk-io.c
+++ b/disk-io.c
@@
I was wondering about the cross-fs copy through copy_file_range.
It seems current implement has below check, that disables such copy.
1577 /* this could be relaxed once a method supports cross-fs copies */
1578 if (inode_in->i_sb != inode_out->i_sb)
1579 return
On 10/01/2018 07:17 PM, Austin S. Hemmelgarn wrote:
On 2018-10-01 04:56, Anand Jain wrote:
Its not that impossible to imagine that a device OR a btrfs image is
been copied just by using the dd or the cp command. Which in case both
the copies of the btrfs will have the same fsid. If on the
On 2018-10-01 04:56, Anand Jain wrote:
Its not that impossible to imagine that a device OR a btrfs image is
been copied just by using the dd or the cp command. Which in case both
the copies of the btrfs will have the same fsid. If on the system with
automount enabled, the copied FS gets scanned.
Please ignore this patch. Instead help review/integrate [1] which is
the same patch with subject and change log updated.
[1]
[PATCH] fstests: btrfs verify hardening agaist duplicate fsid
Thanks, Anand
Its not that impossible to imagine that a device OR a btrfs image is
been copied just by using the dd or the cp command. Which in case both
the copies of the btrfs will have the same fsid. If on the system with
automount enabled, the copied FS gets scanned.
We have a known bug in btrfs, that we
We have a known bug in btrfs, that we let the device path be changed
after the device has been mounted. So using this loop hole the new
copied device would appears as if its mounted immediately after its
been copied. So this test case reproduces this issue.
For example:
Initially..
Its not that impossible to imagine that a device OR a btrfs image is
been copied just by using the dd or the cp command. Which in case both
the copies of the btrfs will have the same fsid. If on the system with
automount enabled, the copied FS gets scanned.
We have a known bug in btrfs, that we
22 matches
Mail list logo
