On 2018/12/8 上午8:47, David Sterba wrote:
> On Fri, Dec 07, 2018 at 06:51:21AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018/12/7 上午3:35, David Sterba wrote:
>>> On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote:
>>>> On Thu, Nov 08,
On 2018/12/7 下午1:24, Doni Crosby wrote:
> All,
>
> I'm coming to you to see if there is a way to fix or at least recover
> most of the data I have from a btrfs filesystem. The system went down
> after both a breaker and the battery backup failed. I cannot currently
> mount the system, with the
8 at 12:43, Michael Wade wrote:
>>
>> I have let the find root command run for 14+ days, its produced a
>> pretty huge log file 1.6 GB but still hasn't completed. I think I will
>> start the process of reformatting my drives and starting over.
>>
>> Thanks for yo
On 2018/12/7 上午3:35, David Sterba wrote:
> On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote:
>> On Thu, Nov 08, 2018 at 01:49:12PM +0800, Qu Wenruo wrote:
>>> This patchset can be fetched from github:
>>> https://github.com/adam900710/linux/tree/qgr
Just like btrfs_add_delayed_tree_ref(), use btrfs_ref to refactor
btrfs_add_delayed_data_ref().
Signed-off-by: Qu Wenruo
---
fs/btrfs/delayed-ref.c | 19 +--
fs/btrfs/delayed-ref.h | 8 +++-
fs/btrfs/extent-tree.c | 24 +++-
3 files changed, 27
Similar to btrfs_inc_extent_ref(), just use btrfs_ref to replace the
long parameter list and the confusing @owner parameter.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 5 +---
fs/btrfs/extent-tree.c | 53 ++
fs/btrfs/file.c| 23
The process_func is never a function hook used anywhere else.
Open code it to make later delayed ref refactor easier, so we can
refactor btrfs_inc_extent_ref() and btrfs_free_extent() in different
patches.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 33
Now we don't need to play the dirty game of reusing @owner for tree block
level.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 6 ++---
fs/btrfs/extent-tree.c | 58 ++
fs/btrfs/file.c| 20 ++-
fs/btrfs/inode.c | 10
It's a perfect match for btrfs_ref_tree_mod() to use btrfs_ref, as
btrfs_ref describes a metadata/data reference update comprehensively.
Now we have one less function use confusing owner/level trick.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 27 +++--
fs/btrfs/ref
-explaining
without dirty level/owner trick, and provides the basis for later refactor.
Signed-off-by: Qu Wenruo
---
fs/btrfs/delayed-ref.c | 24 ++---
fs/btrfs/delayed-ref.h | 4 +---
fs/btrfs/extent-tree.c | 48 --
3 files changed, 44 insertions
qgroup code, to record which tree is triggered this extent modification.
This patch doesn't touch any code, but provides the basis for incoming
refactors.
Signed-off-by: Qu Wenruo
---
fs/btrfs/delayed-ref.h | 109 +
1 file changed, 109 insertions(+)
diff
Since add_pinned_bytes() only needs to know if the extent is metadata
and if it's a chunk tree extent, btrfs_ref is a perfect match for it, as
we don't need various owner/level trick to determine extent type.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 26 ++
1
c_extent_ref(trans, );
This should improve the code readability and make later code easier to
write.
Qu Wenruo (8):
btrfs: delayed-ref: Introduce better documented delayed ref structures
btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref
btrfs: delayed-ref: Use btr
On 2018/12/5 下午9:40, David Sterba wrote:
> On Wed, Dec 05, 2018 at 02:40:12PM +0800, Qu Wenruo wrote:
>> GCC 8.2.1 will report the following warning with "make W=1":
>>
>> ctree.c: In function 'btrfs_next_sibling_tree_block':
>> ctree.c:2990:21: warn
On 2018/12/5 下午8:28, Goldwyn Rodrigues wrote:
> This is a support for DAX in btrfs. I understand there have been
> previous attempts at it. However, I wanted to make sure copy-on-write
> (COW) works on dax as well.
>
> Before I present this to the FS folks I wanted to run this through the
>
We don't have any header declaring btrfs_recover_chunk_tree() nor
btrfs_recover_superblocks(), thus W=1 gives missing-prototypes warning
on them.
Fix it by introducing a new header, rescue.h for these two functions, so
make W=1 could be much happier.
Signed-off-by: Qu Wenruo
Reviewed
Under most case, we are just using 'int' for 'unsigned int', and doesn't
care about the sign.
The Wsign-compare is causing tons of false alerts.
Suppressing it would make W=1 less noisy so we can focus on real
problem, while still allow it in W=3 build.
Signed-off-by: Qu Wenruo
::convert_free_space_to_extents()
- free-space-tree.c::__remove_from_free_space_tree()
- free-space-tree.c::__add_to_free_space_tree()
- free-space-tree.c::btrfs_create_tree()
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
btrfs.c | 2 +-
check/mode-lowmem.c | 6 +++---
extent-tree.c
Prototypes for arg_strtou64() and lookup_path_rootid() are included in
utils.c, resulting make W=1 warning for them.
Just include that header to make W=1 happier.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
utils-lib.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utils
messages.h:49:24: warning: suggest braces around empty body in an 'if'
statement [-Wempty-body]
PRINT_TRACE_ON_ERROR;\
Just extra braces would solve the problem.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
messages.h | 15 ++-
1 file changed, 10 insertions
And fsfeatures.c is indeed a better location for that function.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
fsfeatures.c | 23 +++
utils.c | 23 ---
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/fsfeatures.c b
tlv_len =
%hu",
tlv_type, tlv_len);
@tlv_len is u16, while BTRFS_SEND_BUF_SIZE is 64K.
u16 MAX is 64K - 1, so the final check is always false.
Just remove it.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
send-stream.c | 3 +--
1 file c
set_free_space_tree_thresholds() is never used, just remove it to solve
the missing-prototypes warning from make W=1.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
free-space-tree.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/free-space-tree.c
{} loop, to
ensure we will run the loop for at least once.
Signed-off-by: Qu Wenruo
---
ctree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ctree.c b/ctree.c
index 46e2ccedc0bf..867e8b60b199 100644
--- a/ctree.c
+++ b/ctree.c
@@ -2966,7 +2966,7 @@ int btrfs_next_sibling_t
Although most fallthrough case is pretty obvious, we still need to teach
the dumb compiler that it's an explicit fallthrough.
Also reformat the code to use common indent.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
utils.c | 30 ++
1 file changed, 22
Add __attribute__ ((format (printf, 4, 0))) to fix the vprintf calling
function.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
string-table.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/string-table.c b/string-table.c
index 95833768960d..455285702d51 100644
--- a/string
er
doesn't have enough hint for BUG_ON(), it won't report uninitialized
variable warning.
Qu Wenruo (12):
btrfs-progs: Makefile.extrawarn: Import cc-disable-warning
btrfs-progs: Makefile.extrawarn: Don't warn on sign compare
btrfs-progs: Fix Wempty-body warning
btrfs-progs: Fix Wimplici
We imported cc-option but forgot to import cc-disable-warning.
Fixes: b556a992c3ad ("btrfs-progs: build: allow to build with various compiler
warnings")
Signed-off-by: Qu Wenruo
---
Makefile.extrawarn | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Makefile.e
in W=2/W=3 build]
Signed-off-by: Qu Wenruo
---
Makefile | 5 +
Makefile.extrawarn | 2 ++
2 files changed, 7 insertions(+)
diff --git a/Makefile b/Makefile
index f4ab14ea74c8..a9e57fecb6e6 100644
--- a/Makefile
+++ b/Makefile
@@ -62,6 +62,10 @@ DEBUG_LDFLAGS :=
ABSTOPDIR = $(shell pw
On 2018/12/4 下午8:17, David Sterba wrote:
> On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote:
>> The only location is the following code:
>>
>> int level = path->lowest_level + 1;
>> BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL);
&
On 2018/12/5 上午6:33, Mike Javorski wrote:
> On Tue, Dec 4, 2018 at 2:18 AM Qu Wenruo wrote:
>>
>>
>>
>> On 2018/12/4 上午11:32, Mike Javorski wrote:
>>> Need a bit of advice here ladies / gents. I am running into an issue
>>> which Qu Wenruo seems
On 2018/12/4 下午9:52, David Sterba wrote:
> On Tue, Dec 04, 2018 at 06:15:13PM +0800, Qu Wenruo wrote:
>> Gentle ping.
>>
>> Please put this patch into current release as the new block group size
>> limit check introduced in v4.19 is causing at least 2 reports in mail
On 2018/12/4 下午9:07, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 20:20 ч., Wilson, Ellis wrote:
>> Hi all,
>>
>> Many months ago I promised to graph how long it took to mount a BTRFS
>> filesystem as it grows. I finally had (made) time for this, and the
>> attached is the result of my
On 2018/12/4 下午8:22, David Sterba wrote:
> On Fri, Nov 16, 2018 at 04:04:51PM +0800, Qu Wenruo wrote:
>> The following missing prototypes will be fixed:
>> 1) btrfs.c::handle_special_globals()
>> 2) check/mode-lowmem.c::repair_ternary_lowmem()
>> 3) extent-tree.c::
On 2018/12/4 下午7:10, David Sterba wrote:
> On Fri, Nov 16, 2018 at 03:54:19PM +0800, Qu Wenruo wrote:
>> From: Su Yanjun
>>
>> When using gcc8 compiles utils.c, it complains as below:
>>
>> utils.c:852:45: warning: '%s' directive output may be truncated writing
On 2018/12/4 下午6:20, David Sterba wrote:
> On Tue, Nov 27, 2018 at 04:38:24PM +0800, Qu Wenruo wrote:
>> +error:
>> +error(
>> +"failed to fix chunks and devices mapping, the fs may not be mountable: %s",
>> +strerror(-ret));
>
>
On 2018/12/4 下午6:18, David Sterba wrote:
> On Tue, Nov 27, 2018 at 04:50:57PM +0800, Qu Wenruo wrote:
>>>> -static int fixup_devices(struct btrfs_fs_info *fs_info,
>>>> - struct mdrestore_struct *mdres, off_t dev_size)
>>>&g
On 2018/12/4 上午11:32, Mike Javorski wrote:
> Need a bit of advice here ladies / gents. I am running into an issue
> which Qu Wenruo seems to have posted a patch for several weeks ago
> (see https://patchwork.kernel.org/patch/10694997/).
>
> Here is the relevant dmesg output which
Gentle ping.
Please put this patch into current release as the new block group size
limit check introduced in v4.19 is causing at least 2 reports in mail list.
Thanks,
Qu
On 2018/11/23 上午9:06, Qu Wenruo wrote:
> [BUG]
> A completely valid btrfs will refuse to mount, with error messag
On 2018/12/4 上午2:20, Wilson, Ellis wrote:
> Hi all,
>
> Many months ago I promised to graph how long it took to mount a BTRFS
> filesystem as it grows. I finally had (made) time for this, and the
> attached is the result of my testing. The image is a fairly
> self-explanatory graph, and
On 2018/12/3 下午5:31, Stefan Malte Schumacher wrote:
> Hello,
>
> I have noticed an unusual amount of crc-errors in downloaded rars,
> beginning about a week ago. But lets start with the preliminaries. I
> am using Debian Stretch.
> Kernel: Linux mars 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4
On 2018/12/3 上午4:30, Andrei Borzenkov wrote:
> 02.12.2018 23:14, Patrick Dijkgraaf пишет:
>> I have some additional info.
>>
>> I found the reason the FS got corrupted. It was a single failing drive,
>> which caused the entire cabinet (containing 7 drives) to reset. So the
>> FS suddenly lost 7
For reloc tree, despite of its short lifespan, it's still the backref,
where reloc tree root backref points back to itself, makes it special.
So it's more approriate to put them into 020-extent-ref-cases.
Signed-off-by: Qu Wenruo
---
tests/fsck-tests/015-tree-reloc-tree/test.sh| 16
On 2018/12/3 上午8:35, Qu Wenruo wrote:
>
>
> On 2018/12/2 下午5:03, Patrick Dijkgraaf wrote:
>> Hi Qu,
>>
>> Thanks for helping me!
>>
>> Please see the reponses in-line.
>> Any suggestions based on this?
>>
>> Thanks!
>>
>>
>
On 2018/12/2 下午5:03, Patrick Dijkgraaf wrote:
> Hi Qu,
>
> Thanks for helping me!
>
> Please see the reponses in-line.
> Any suggestions based on this?
>
> Thanks!
>
>
> On Sat, 2018-12-01 at 07:57 +0800, Qu Wenruo wrote:
>> On 2018/11/30 下午9:
On 2018/12/1 上午12:52, Josef Bacik wrote:
> From: Josef Bacik
>
> When debugging some weird extent reference bug I suspected that we were
> changing a snapshot while we were deleting it, which could explain my
> bug.
May I ask under which case we're going to modify an unlinked snapshot?
Maybe
On 2018/11/30 下午9:53, Patrick Dijkgraaf wrote:
> Hi all,
>
> I have been a happy BTRFS user for quite some time. But now I'm facing
> a potential ~45TB dataloss... :-(
> I hope someone can help!
>
> I have Server A and Server B. Both having a 20-devices BTRFS RAID6
> filesystem. Because of
On 2018/11/29 上午4:08, Filipe Manana wrote:
> On Wed, Nov 28, 2018 at 7:09 PM David Sterba wrote:
>>
>> On Tue, Nov 27, 2018 at 03:08:08PM -0500, Josef Bacik wrote:
>>> On Tue, Nov 27, 2018 at 07:59:42PM +, Chris Mason wrote:
On 27 Nov 2018, at 14:54, Josef Bacik wrote:
> On
fs(8).
It has a pretty good datasheet for all supported profiles under PROFILES
section, and it mentions min/max devices.
Thanks,
Qu
> ke 28. marrask. 2018 klo 3.14 Qu Wenruo (quwenruo.bt...@gmx.com) kirjoitti:
>>
>>
>>
>> On 2018/11/28 上午5:16, Mikko Merikivi wrote:
On 2018/11/28 下午9:25, David Sterba wrote:
> On Wed, Nov 28, 2018 at 09:33:50AM +0800, Qu Wenruo wrote:
>> On 2018/11/28 上午3:53, David Sterba wrote:
>>> This is motivated by a merging mistake that happened a few releases ago.
>>> Two patches updated BTRFS_FS_* flag
ents | 74938| 69292 | -7.5%
time (real) | 24.567s | 23.546 | -4.1%
*: With delayed subtree scan and "btrfs: qgroup: Skip delayed data ref
for reloc trees"
Signed-off-by: Qu Wenruo
---
For the delayed ref API paramaters mess, it need an inte
On 2018/11/28 上午11:11, Su Yue wrote:
> This patchset can be fetched from repo:
> https://github.com/Damenly/btrfs-devel/commits/priority_aware_allocator.
> Since patchset 'btrfs: Refactor find_free_extent()' does a nice work
> to simplify find_free_extent(). This patchset dependents on the
On 2018/11/28 上午3:53, David Sterba wrote:
> The first auto-assigned value to enum is 0, we can use that and not
> initialize all members where the auto-increment does the same. This is
> used for values that are not part of on-disk format.
>
> Signed-off-by: David Sterba
On 2018/11/28 上午3:53, David Sterba wrote:
> This is motivated by a merging mistake that happened a few releases ago.
> Two patches updated BTRFS_FS_* flags independently to the same value,
> git did not see any direct merge conflict. The two values got mixed at
> runtime and caused crash.
>
>
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> ordered extent flags.
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/ordered-data.h | 45 +++-
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> tree lock types.
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/locking.h | 10 ++
> 1 file change
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> extent map flags.
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/extent_map.h | 21 ++---
>
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> extent buffer flags;
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/extent_io.h | 28
>
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> root tree flags.
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/ctree.h | 33 +
>
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> internal filesystem states.
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> block reserve types.
>
> Signed-off-by: David Sterba
Reviewed-by: Qu Wenruo
However more comment will always be a good thing.
Thanks,
Qu
> ---
> fs/
On 2018/11/28 上午3:53, David Sterba wrote:
> We can use simple enum for values that are not part of on-disk format:
> global filesystem states.
>
> Signed-off-by: David Sterba
Good comment.
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/ctree.h | 25 +
On 2018/11/28 上午5:16, Mikko Merikivi wrote:
> I seem unable to convert an existing btrfs device array to RAID 10.
> Since it's pretty much RAID 0 and 1 combined, and 5 and 6 are
> unstable, it's what I would like to use.
>
> After I did tried this with 4.19.2-arch1-1-ARCH and btrfs-progs v4.19,
On 2018/11/27 下午10:11, Andrea Gelmini wrote:
> On Tue, Nov 27, 2018 at 09:13:02AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018/11/26 下午11:01, Andrea Gelmini wrote:
>>> One question: I can completely trust the ok return status of scrub? I
>>>
On 2018/11/27 下午4:46, Nikolay Borisov wrote:
>
>
> On 27.11.18 г. 10:38 ч., Qu Wenruo wrote:
>> Current fixup_devices() will only remove DEV_ITEMs and reset DEV_ITEM
>> size.
>> Later we need to do more fixup works, so change the name to
>> fixup_chunks_and_de
mount, this will also help us to locate
the problem in btrfs-image easier.
Signed-off-by: Qu Wenruo
---
tests/misc-tests/021-image-multi-devices/test.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/misc-tests/021-image-multi-devices/test.sh
b/tests/misc-tests/021-image-multi
the straight-forward way to fix it, causing
the final dev extents layout to match with chunk tree, and make btrfs
check happy.
Signed-off-by: Qu Wenruo
---
image/main.c | 102 +++
1 file changed, 102 insertions(+)
diff --git a/image/main.c b/image/main.c
trans parameter for function who doesn't need
- Merge dev extents removal code with rebuild code
- Refactor btrfs_alloc_dev_extent() into 2 functions
* btrfs_insert_dev_extent() for convert and dev extent rebuild
* btrfs_alloc_dev_extent() for old use case
Qu Wenruo (5):
btrfs-progs:
parameter, and make
btrfs_insert_dev_extent() public for later usage.
Signed-off-by: Qu Wenruo
---
volumes.c | 48 ++--
volumes.h | 3 +++
2 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/volumes.c b/volumes.c
index 30090ce5f8e8..0dd082cd1718
,
wanted: 4, have: 20
ERROR: chunk[1104150528 2177892352) related block group item flags mismatch,
wanted: 1, have: 9
This patch will do an extra repair for block group items to fix the
profile of them.
Signed-off-by: Qu Wenruo
---
image/main.c | 46
Current fixup_devices() will only remove DEV_ITEMs and reset DEV_ITEM
size.
Later we need to do more fixup works, so change the name to
fixup_chunks_and_devices() and refactor the original device size fixup
to fixup_device_size().
Signed-off-by: Qu Wenruo
---
image/main.c | 52
On 2018/11/27 下午3:29, Nikolay Borisov wrote:
>
>
> On 27.11.18 г. 4:33 ч., Qu Wenruo wrote:
>> Test case misc/021 is testing if we could mount a single disk btrfs
>> image recovered from multi disk fs.
>>
>> The problem is, current kernel has extra check
On 2018/11/27 下午3:28, Nikolay Borisov wrote:
>
>
> On 27.11.18 г. 4:33 ч., Qu Wenruo wrote:
>> With existing dev extents cleaned up, now we can rebuild dev extents
>> using the correct chunk tree.
>>
>> Since new dev extents are all rebuild from scratch, e
On 2018/11/27 下午3:15, Nikolay Borisov wrote:
>
>
> On 27.11.18 г. 4:33 ч., Qu Wenruo wrote:
>> Since btrfs-image is just restoring tree blocks without really check if
>> that tree block contents makes sense, for multi-device image, block
>> group items will keep
On 2018/11/27 下午3:13, Nikolay Borisov wrote:
>
>
> On 27.11.18 г. 4:33 ч., Qu Wenruo wrote:
>> Current fixup_devices() will only remove DEV_ITEMs and reset DEV_ITEM
>> size.
>> Later we need to do more fixup works, so change the name to
>> fixup_chunks_and_de
mount, this will also help us to locate
the problem in btrfs-image easier.
Signed-off-by: Qu Wenruo
---
tests/misc-tests/021-image-multi-devices/test.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/misc-tests/021-image-multi-devices/test.sh
b/tests/misc-tests/021-image-multi
This patch will remove all existing dev extents for later rebuild.
Signed-off-by: Qu Wenruo
---
image/main.c | 68
1 file changed, 68 insertions(+)
diff --git a/image/main.c b/image/main.c
index 9060f6b1b665..707568f22e01 100644
--- a/image
,
wanted: 4, have: 20
ERROR: chunk[1104150528 2177892352) related block group item flags mismatch,
wanted: 1, have: 9
This patch will do an extra repair for block group items to fix the
profile of them.
Signed-off-by: Qu Wenruo
---
image/main.c | 47
With existing dev extents cleaned up, now we can rebuild dev extents
using the correct chunk tree.
Since new dev extents are all rebuild from scratch, even we're restoring
image from multi-device fs to single disk, we won't have any problem
reported by btrfs check.
Signed-off-by: Qu Wenruo
Current fixup_devices() will only remove DEV_ITEMs and reset DEV_ITEM
size.
Later we need to do more fixup works, so change the name to
fixup_chunks_and_devices() and refactor the original device size fixup
to fixup_device_size().
Signed-off-by: Qu Wenruo
---
image/main.c | 52
group flags, then rebuild the whole
dev extents by removing existing ones first, then re-add the correct
dev extents calculated from chunk map.
Now it could pass all misc tests and fsck tests.
Qu Wenruo (5):
btrfs-progs: image: Refactor fixup_devices() to
fixup_chunks_and_devices()
btrfs-progs
On 2018/11/26 下午11:01, Andrea Gelmini wrote:
> Hi everybody,
>and thanks a lot for your work.
>
>I'm using BTRFS over LVM over cryptsetup, over Samsung SSD 860 EVO (latest
> git of btrfs-progs).
>Usually I run kernel in development, because I know BTRFS is young and
> there are
On 2018/11/26 下午3:19, Alexander Fieroch wrote:
> Hi,
>
> My data partition with btrfs RAID 0 (/dev/sdc0 and /dev/sdd0) shows
> errors in syslog:
>
> BTRFS error (device sdc): cleaner transaction attach returned -30
> BTRFS info (device sdc): disk space caching is enabled
> BTRFS info (device
I'll push them in next update.
Thanks,
Qu
Qu Wenruo (5):
btrfs-progs: lowmem check: Add ability to repair dir item with
mismatch hash
btrfs-progs: original check: Use mismatch_dir_hash_record to record
bad dir items
btrfs-progs: original check: Add ability to repair dir item with
On 2018/11/23 下午2:41, Andy Leadbetter wrote:
> I have a failing 2TB disk that is part of a 4 disk RAID 6 system. I
> have added a new 2TB disk to the computer, and started a BTRFS replace
> for the old and new disk. The process starts correctly however some
> hours into the job, there is an
ead time, and rely on bg <-> chunk mapping to do the check.
We could just skip the length check for now.
Fixes: fce466eab7ac ("btrfs: tree-checker: Verify block_group_item")
Cc: sta...@vger.kernel.org # v4.19+
Reported-by: Wang Yugui
Signed-off-by: Qu Wenruo
---
fs/btrfs/tree-checke
On 2018/11/22 下午10:03, Roman Mamedov wrote:
> On Thu, 22 Nov 2018 22:07:25 +0900
> Tomasz Chmielewski wrote:
>
>> Spot on!
>>
>> Removed "discard" from fstab and added "ssd", rebooted - no more
>> btrfs-cleaner running.
>
> Recently there has been a bugfix for TRIM in Btrfs:
>
> btrfs:
On 2018/11/22 下午9:12, David Sterba wrote:
> On Tue, Nov 20, 2018 at 08:32:42AM +0800, Qu Wenruo wrote:
>>>>> @@ -1013,16 +1013,22 @@ int btrfs_quota_enable(struct btrfs_fs_info
>>>>> *fs_info)
>>>>> btrfs_abort_transaction(tra
On 2018/11/22 上午2:59, Josef Bacik wrote:
> From: Josef Bacik
>
> We were missing some quota cleanups in check_ref_cleanup, so break the
> ref head accounting cleanup into a helper and call that from both
> check_ref_cleanup and cleanup_ref_head. This will hopefully ensure that
> we don't
On 2018/11/20 下午5:11, Nikolay Borisov wrote:
>
>
> On 20.11.18 г. 11:07 ч., Qu Wenruo wrote:
>>
>>
>> On 2018/11/20 下午4:51, Nikolay Borisov wrote:
>
>>> I'm beginning to wonder, should we document
>>> btrfs_add_delayed_data_ref/btrfs_add_t
On 2018/11/20 下午4:51, Nikolay Borisov wrote:
>
>
> On 20.11.18 г. 10:46 ч., Qu Wenruo wrote:
>> Currently we only check @ref_root in btrfs_add_delayed_data_ref() to
>> determine whether a data delayed ref is for reloc tree.
>>
>> Such check is insufficien
---
relocated extents| 22773| 22656 | -0.1%
qgroup dirty extents | 122879 | 74316 | -39.5%
time (real) | 23.073s | 14.971 | -35.1%
*: v4.20-rc1 + delayed subtree scan patchset
Signed-off-by: Qu Wenruo
---
relocated extents| 22773| 22656 | -0.1%
qgroup dirty extents | 122879 | 74316 | -39.5%
time (real) | 23.073s | 14.971 | -35.1%
*: v4.20-rc1 + delayed subtree scan patchset
Signed-off-by: Qu Wenruo
ck
>-> ioctl returns -EINVAL
>
> Returning -EINVAL to user space will be confusing if all the arguments
> passed to the subvolume creation ioctl were valid.
>
> Fix it by grabbing the value from fs_info->quota_root after a
On 2018/11/19 下午11:24, Filipe Manana wrote:
> On Mon, Nov 19, 2018 at 2:48 PM Qu Wenruo wrote:
>>
>>
>>
>> On 2018/11/19 下午10:15, fdman...@kernel.org wrote:
>>> From: Filipe Manana
>>>
>>> If the quota enable and snapshot creation ioctls
On 2018/11/19 下午11:36, Nikolay Borisov wrote:
>
>
> On 19.11.18 г. 16:48 ч., Qu Wenruo wrote:
>> There may be some qgroup reserved space related problem in such case,
>> but I'm not 100% sure to foresee such problem.
>
> But why is this a problem - we always q
On 2018/11/19 下午10:15, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If the quota enable and snapshot creation ioctls are called concurrently
> we can get into a deadlock where the task enabling quotas will deadlock
> on the fs_info->qgroup_ioctl_lock mutex because it attempts to lock
On 2018/11/19 下午7:52, Filipe Manana wrote:
> On Mon, Nov 19, 2018 at 11:35 AM Qu Wenruo wrote:
>>
>>
>>
>> On 2018/11/19 下午7:13, Filipe Manana wrote:
>>> On Mon, Nov 19, 2018 at 11:09 AM Qu Wenruo wrote:
>>>>
>>>>
>>>>
On 2018/11/19 下午7:13, Filipe Manana wrote:
> On Mon, Nov 19, 2018 at 11:09 AM Qu Wenruo wrote:
>>
>>
>>
>> On 2018/11/19 下午5:48, fdman...@kernel.org wrote:
>>> From: Filipe Manana
>>>
>>> If the quota enable and snapshot creation ioctls
On 2018/11/19 下午5:48, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If the quota enable and snapshot creation ioctls are called concurrently
> we can get into a deadlock where the task enabling quotas will deadlock
> on the fs_info->qgroup_ioctl_lock mutex because it attempts to lock it
1 - 100 of 5771 matches
Mail list logo
