On 2019/4/3 上午11:58, Chris Murphy wrote:
> I'm sometimes seeing the same backup_tree_root used more than once.
> Below you'll see backup 0 and backup 2 have the same address,
> different generation. The concern is if this suggests backup 2 is
> actually stale and not useful?
Currently, backup ro
On 3.04.19 г. 10:05 ч., Qu Wenruo wrote:
>
>
> On 2019/4/3 上午11:58, Chris Murphy wrote:
>> I'm sometimes seeing the same backup_tree_root used more than once.
>> Below you'll see backup 0 and backup 2 have the same address,
>> different generation. The concern is if this suggests backup 2 is
>
Hi,
Recently Intel LKP performance test is reporting regression of btrfs
performance.
It points to tree-checker code, and since I'm poking around the
bcc/ebpf, I spend some time to do an interesting look into the
performance penalty about both btrfs csum and tree-checker.
The code base is David'
On 2019/3/20 下午2:27, Qu Wenruo wrote:
> +int btrfs_check_leaf_write(struct btrfs_fs_info *fs_info,
> +struct extent_buffer *leaf)
> +{
> + return check_leaf(fs_info, leaf, false, false);
> }
Well, I got confused by those two bool paramters.
The first bool is whethe
On 3.04.19 г. 11:54 ч., Qu Wenruo wrote:
> Hi,
>
> Recently Intel LKP performance test is reporting regression of btrfs
> performance.
>
> It points to tree-checker code, and since I'm poking around the
> bcc/ebpf, I spend some time to do an interesting look into the
> performance penalty abou
On 2019/4/3 下午5:09, Nikolay Borisov wrote:
>
>
> On 3.04.19 г. 11:54 ч., Qu Wenruo wrote:
>> Hi,
>>
>> Recently Intel LKP performance test is reporting regression of btrfs
>> performance.
>>
>> It points to tree-checker code, and since I'm poking around the
>> bcc/ebpf, I spend some time to do a
Commit "btrfs: Do mandatory tree block check before submitting bio" is
designed to check leaves contents, just as read time check.
However due to the confusing parameter list, "false" is passed to where
it is supposed to be "true".
Signed-off-by: Qu Wenruo
---
fs/btrfs/tree-checker.c | 2 +-
1
Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
zero item") introduced comprehensive root owner checker.
However it's pretty expensive tree search to locate the owner root,
especially when it get reused by mandatory read and write time
tree-checker.
This patch will remove th
On Wed, Mar 27, 2019 at 02:24:03PM +0200, Nikolay Borisov wrote:
> Here is the (hopefully final) v4 of the fitrim patches. Main changes since v3:
>
> * Fixed leaked btrfs_path in patch 3.
>
> * Fixed multiple assignemnt on single line in patch 3.
>
> * New patch 9 transposing btrfs_close_devices
On Wed, Apr 03, 2019 at 07:59:18PM +0800, Qu Wenruo wrote:
> Commit "btrfs: Do mandatory tree block check before submitting bio" is
> designed to check leaves contents, just as read time check.
>
> However due to the confusing parameter list, "false" is passed to where
> it is supposed to be "true
On 3.04.19 г. 14:59 ч., Qu Wenruo wrote:
> Commit "btrfs: Do mandatory tree block check before submitting bio" is
> designed to check leaves contents, just as read time check.
>
> However due to the confusing parameter list, "false" is passed to where
> it is supposed to be "true".
>
> Signed-
On 2019/4/3 下午10:13, David Sterba wrote:
> On Wed, Apr 03, 2019 at 07:59:18PM +0800, Qu Wenruo wrote:
>> Commit "btrfs: Do mandatory tree block check before submitting bio" is
>> designed to check leaves contents, just as read time check.
>>
>> However due to the confusing parameter list, "false"
On Wed, Apr 03, 2019 at 07:59:19PM +0800, Qu Wenruo wrote:
> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
> zero item") introduced comprehensive root owner checker.
That's 4.7, so we might want to do stable backport to 4.9+.
>
> However it's pretty expensive tree search t
On 2019/4/3 下午10:12, Nikolay Borisov wrote:
>
>
> On 3.04.19 г. 14:59 ч., Qu Wenruo wrote:
>> Commit "btrfs: Do mandatory tree block check before submitting bio" is
>> designed to check leaves contents, just as read time check.
>>
>> However due to the confusing parameter list, "false" is pass
On 3.04.19 г. 14:59 ч., Qu Wenruo wrote:
> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
> zero item") introduced comprehensive root owner checker.
>
> However it's pretty expensive tree search to locate the owner root,
> especially when it get reused by mandatory read a
On Wed, Apr 03, 2019 at 10:15:27PM +0800, Qu Wenruo wrote:
>
>
> On 2019/4/3 下午10:13, David Sterba wrote:
> > On Wed, Apr 03, 2019 at 07:59:18PM +0800, Qu Wenruo wrote:
> >> Commit "btrfs: Do mandatory tree block check before submitting bio" is
> >> designed to check leaves contents, just as read
On 2019/4/3 下午10:21, David Sterba wrote:
> On Wed, Apr 03, 2019 at 07:59:19PM +0800, Qu Wenruo wrote:
>> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
>> zero item") introduced comprehensive root owner checker.
>
> That's 4.7, so we might want to do stable backport to 4.9
On Tue, Mar 12, 2019 at 12:00:25AM -0400, Zygo Blaxell wrote:
> On 4.14.x and 4.20.14 kernels (probably all the ones in between too,
> but I haven't tested those), I get what I call "ghost parent transid
> verify failed" errors. Here's an unedited recent example from dmesg:
>
> [16180.64928
On Wed, Apr 03, 2019 at 10:26:05PM +0800, Qu Wenruo wrote:
> On 2019/4/3 下午10:21, David Sterba wrote:
> > On Wed, Apr 03, 2019 at 07:59:19PM +0800, Qu Wenruo wrote:
> >> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
> >> zero item") introduced comprehensive root owner checke
On Tue, Apr 02, 2019 at 05:45:54PM +0800, Qu Wenruo wrote:
> There are two tree lock events which can sleep:
> - btrfs_tree_read_lock()
> - btrfs_tree_lock()
>
> Sometimes we may need to look into the concurrency picture of the fs.
> For that case, we need the execution time of above two functions
Hmmm btrfs send is _also_ prone to use-after-free issues when running with
balance (or anything that modifies readonly snapshots). That and the
lockdep warning on 5.0.x points to...well, maybe not the same bug as
the snapshot delete case, but either a single bug in common code,
or two similar bugs
On Mon, Feb 11, 2019 at 01:16:44PM +0800, Qu Wenruo wrote:
> Qu Wenruo (9):
> btrfs: delayed-ref: Introduce better documented delayed ref structures
> btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref
> btrfs: delayed-ref: Use btrfs_ref to refactor
> btrfs_add_delayed_tree_ref
We let to pass zstd compression parameter even if its not fully written.
For example:
btrfs prop set /btrfs compression zst
btrfs prop get /btrfs compression
compression=zst
zlib and lzo are fine.
Fix it by using the expected number of char in strncmp().
Signed-off-by: Anand Jain
Revie
__btrfs_set_acl() is helper function of btrfs_set_acl(), rename it to
do_set_acl(). No functional changes.
Signed-off-by: Anand Jain
---
fs/btrfs/acl.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/acl.c b/fs/btrfs/acl.c
index 5810463dc6d2..a22ebb04d9c
__btrfs_set_prop() accepts trans an argument, which when NULL,
the trans is created further down at btrfs_setxattr().
So btrfs_set_prop() is a redirect to __btrfs_set_prop() with the
transaction handle equal to NULL. No functional changes.
Signed-off-by: Anand Jain
---
fs/btrfs/props.c | 15
Both mainline and misc-5.2 fails the test case that transaction
generation number must be unaltered if the property validation fails.
For example:
btrfs in dump-super /dev/sdb | grep ^generation; \
btrfs prop set /btrfs compression lz; sync; \
btrfs in dump-super /dev/sdb | grep ^generation
gener
The compression property resets to NULL, instead of the old value if we
fail to set the new compression parameter.
btrfs prop get /btrfs compression
compression=lzo
btrfs prop set /btrfs compression zli
ERROR: failed to set compression for /btrfs: Invalid argument
btrfs prop get /btrfs compres
Add more property validation cases which are fixed by the patches [1]
[1]
btrfs: fix vanished compression property after failed set
btrfs: fix zstd compression parameter
Signed-off-by: Anand Jain
---
tests/btrfs/048 | 25 +
tests/btrfs/048.out | 16 ++
Add more property validation cases which are fixed by the patches [1]
[1]
btrfs: fix vanished compression property after failed set
btrfs: fix zstd compression parameter
Signed-off-by: Anand Jain
---
v2: correct kernel patch titles in the test header and change log
tests/btrfs/048 | 23
On Wed, Apr 3, 2019 at 3:18 AM Dave Chinner wrote:
>
> On Mon, Apr 01, 2019 at 01:50:18PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Currently the fsync function can only be performed against regular files.
> > Allow it to operate on directories too, to increase test covera
On Fri, Mar 29, 2019 at 11:26:43PM +0300, Andy Shevchenko wrote:
> When the ID comes from or we would like to pass it to a raw buffer,
> the casting is needed.
Something is missing in this sentence.
On 2019-04-03 14:17, Hendrik Friedel wrote:
Hello,
thanks for your reply.
3) Even more, it would be good, if btrfs would disable the write cache
in that case, so that one does not need to rely on the user
Personally speaking, if user really believes it's write cache causing
the problem or wan
Hello,
thanks for your reply.
>>3) Even more, it would be good, if btrfs would disable the write cache
>> in that case, so that one does not need to rely on the user
>
>Personally speaking, if user really believes it's write cache causing
>the problem or want to be extra safe, then they should di
On Wed, Apr 03, 2019 at 05:35:20PM +, Filipe Manana wrote:
> On Wed, Apr 3, 2019 at 3:18 AM Dave Chinner wrote:
> >
> > On Mon, Apr 01, 2019 at 01:50:18PM +0100, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Currently the fsync function can only be performed against regular
On 2019/4/3 下午11:43, David Sterba wrote:
> On Tue, Apr 02, 2019 at 05:45:54PM +0800, Qu Wenruo wrote:
>> There are two tree lock events which can sleep:
>> - btrfs_tree_read_lock()
>> - btrfs_tree_lock()
>>
>> Sometimes we may need to look into the concurrency picture of the fs.
>> For that case,
On 2019/4/4 上午2:17, Hendrik Friedel wrote:
> Hello,
>
> thanks for your reply.
>
>>> 3) Even more, it would be good, if btrfs would disable the write cache
>>> in that case, so that one does not need to rely on the user
>>
>> Personally speaking, if user really believes it's write cache causi
On 2019/4/4 上午12:29, David Sterba wrote:
> On Mon, Feb 11, 2019 at 01:16:44PM +0800, Qu Wenruo wrote:
>> Qu Wenruo (9):
>> btrfs: delayed-ref: Introduce better documented delayed ref structures
>> btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref
>> btrfs: delayed-ref: Use btrfs
On 4/2/19 3:19 PM, Filipe Manana wrote:
> On Tue, Apr 2, 2019 at 7:29 PM wrote:
>>
>> From: Jeff Mahoney
>>
>> When repairing the extent tree, it's possible for delayed extents to
>> be created when running btrfs_write_dirty_block_groups. We run
>> delayed refs one last time in the kernel but th
On 3/31/19 2:44 PM, bt...@avgustinov.eu wrote:
> Dear all,
>
>
> I am a big fan of btrfs, and I am using it since 2013 - in the meantime
> on at least four different computers. During this time, I suffered at
> least four bad btrfs-failures leading to unmountable, unreadable and
> unrecoverable f
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/tree_checker_testing
Which is based on misc-next, with the following commit as HEAD:
commit 56d46f96de92ec69963acb7b1d9aed83d2a56a7b
(david/misc-next-with-write-checks, david/misc-next)
Author: Nikolay Borisov
Dat
Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
zero item") introduced comprehensive root owner checker.
However it's pretty expensive tree search to locate the owner root,
especially when it get reused by mandatory read and write time
tree-checker.
This patch will remove th
There are at least 2 reports about a memory bit flip sneaking into
on-disk data.
Currently we only have a relaxed check triggered at
btrfs_mark_buffer_dirty() time, as it's not mandatory and only for
CONFIG_BTRFS_FS_CHECK_INTEGRITY enabled build, it doesn't help users to
detect such problem.
This
On 4.04.19 г. 6:47 ч., Qu Wenruo wrote:
> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
> zero item") introduced comprehensive root owner checker.
>
> However it's pretty expensive tree search to locate the owner root,
> especially when it get reused by mandatory read an
On 2019/4/4 下午2:23, Nikolay Borisov wrote:
>
>
> On 4.04.19 г. 6:47 ч., Qu Wenruo wrote:
>> Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
>> zero item") introduced comprehensive root owner checker.
>>
>> However it's pretty expensive tree search to locate the owner root,
On 2019/4/4 上午12:29, David Sterba wrote:
> On Mon, Feb 11, 2019 at 01:16:44PM +0800, Qu Wenruo wrote:
>> Qu Wenruo (9):
>> btrfs: delayed-ref: Introduce better documented delayed ref structures
>> btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref
>> btrfs: delayed-ref: Use btrfs
Current delayed ref interface has several problems:
- Longer and longer parameter lists
bytenr
num_bytes
parent
-- so far so good
ref_root
owner
offset
-- I don't feel good now
- Different interpretation for the same parameter
Above @owner for data ref is inode nu
The process_func function pointer is local to __btrfs_mod_ref() and
points to either btrfs_inc_extent_ref() or btrfs_free_extent().
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 Wen
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 | 5 ++--
fs/btrfs/extent-tree.c | 57 --
fs/btrfs/file.c| 17 +
fs/btrfs/inode.c | 10 +---
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 | 18 +-
fs/btrfs/delayed-ref.h | 7 +++
fs/btrfs/extent-tree.c | 23 ++-
3 files changed, 26 insertions(+)
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/refactor_delayed_ref_parameter
Which is based on David's misc-next branch, the base commit is:
commit 56d46f96de92ec69963acb7b1d9aed83d2a56a7b
(david/misc-next-with-write-checks, david/misc-next)
Author: Nikolay Bo
Since reloc tree doesn't contribute to qgroup numbers, just skip them.
This should catch the final cause of unnecessary data refs for qgroup +
metadata balance.
The 4G data 16 snapshots test (*) should explain it pretty well:
| delayed subtree | refactor delayed ref | this patch
---
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 | 52 +++---
fs/btrfs/file.c| 22
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-ve
btrfs_add_delayed_tree_ref() has a longer and longer parameter list, and
some caller like btrfs_inc_extent_ref() are using @owner as level for
delayed tree ref.
Instead of making the parameter list longer and longer, use btrfs_ref to
refactor it, so each parameter assignment should be self-explain
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
Reviewed-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 26
55 matches
Mail list logo
