On 3.12.18 г. 12:25 ч., Nikolay Borisov wrote:
> When extent_readpages is called from the generic readahead code it first
> builds a batch of 16 pages (which might or might not be consecutive,
> depending on whether add_to_page_cache_lru failed) and submits them to
> __extent_readpages. The latt
- Original Message -
> From: "Qu Wenruo"
> On 2019/2/10 下午2:56, STEVE LEUNG wrote:
>> Hi all,
>>
>> I decided to try something a bit crazy, and try multi-device raid1 btrfs on
>> top of dm-crypt and bcache. That is:
>>
>> btrfs -> dm-crypt -> bcache -> physical disks
>>
>> I have
- Original Message -
> From: "Thiago Ramon"
> On Sun, Feb 10, 2019 at 5:07 AM STEVE LEUNG wrote:
>>
>> Hi all,
>>
>> I decided to try something a bit crazy, and try multi-device raid1 btrfs on
>> top of dm-crypt and bcache. That is:
>>
>> btrfs -> dm-crypt -> bcache -> physical disk
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
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 | 20 ++--
fs/btrfs/delayed-ref.h | 7 +++
fs/btrfs/extent-tree.c | 23 ++-
3 files changed, 27 insertions(
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
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
---
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 eb3e579e28f1c58e79176fbf5afe1cf3ee227190 (david/misc-next,
david/misc-5.1)
Author: Anand Jain
Date: Fri Feb 8
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
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
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
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
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 +---
On 2019/2/11 上午2:44, Chris Murphy wrote:
> On Sat, Feb 9, 2019 at 3:36 AM Jakob Schöttl wrote:
>>
>> Replace device 2 with device 3:
>>
>>mount -o degraded /dev/loop1 /mnt
>>btrfs filesystem show # to get devid of device 2
>>btrfs replace start -Br 2 /dev/loop3 /mnt
>>btrfs rep
On Sat, Feb 9, 2019 at 3:36 AM Jakob Schöttl wrote:
>
> Replace device 2 with device 3:
>
>mount -o degraded /dev/loop1 /mnt
>btrfs filesystem show # to get devid of device 2
>btrfs replace start -Br 2 /dev/loop3 /mnt
>btrfs replace status /mnt # check success
>umount /mnt
On Sat, Feb 9, 2019 at 5:13 AM waxhead wrote:
> Understood, but that is not quite what I meant - let me rephrase...
> If BTRFS still can't mount, why would it blindly accept a previously
> non-existing disk to take part of the pool?!
It doesn't do it blindly. It only ever mounts when the user sp
On 2019/2/10 下午2:56, STEVE LEUNG wrote:
> Hi all,
>
> I decided to try something a bit crazy, and try multi-device raid1 btrfs on
> top of dm-crypt and bcache. That is:
>
> btrfs -> dm-crypt -> bcache -> physical disks
>
> I have a single cache device in front of 4 disks. Maybe this wasn't
On Sun, Feb 10, 2019 at 5:07 AM STEVE LEUNG wrote:
>
> Hi all,
>
> I decided to try something a bit crazy, and try multi-device raid1 btrfs on
> top of dm-crypt and bcache. That is:
>
> btrfs -> dm-crypt -> bcache -> physical disks
>
> I have a single cache device in front of 4 disks. Maybe th
18 matches
Mail list logo
