On 10/14/19 11:24 PM, David Sterba wrote:
On Tue, Oct 08, 2019 at 10:53:37AM +0800, Anand Jain wrote:
On 10/8/19 1:41 AM, David Sterba wrote:
On Wed, Oct 02, 2019 at 12:11:52PM +0800, Anand Jain wrote:
To help debug device scan issues, add verbose option to btrfs device scan.
The common opti
On Mon, Oct 14, 2019 at 7:05 PM James Harvey wrote:
>
> On Sun, Oct 13, 2019 at 9:46 PM Chris Murphy wrote:
> >
> > On Sat, Oct 12, 2019 at 5:29 PM James Harvey
> > wrote:
> > >
> > > Was using a temporary BTRFS volume to compile mongodb, which is quite
> > > intensive and takes quite a bit of
On Sun, Oct 13, 2019 at 9:46 PM Chris Murphy wrote:
>
> On Sat, Oct 12, 2019 at 5:29 PM James Harvey wrote:
> >
> > Was using a temporary BTRFS volume to compile mongodb, which is quite
> > intensive and takes quite a bit of time. The volume has been
> > deadlocked for about 12 hours.
> >
> > Be
On 2019/10/14 下午11:17, David Sterba wrote:
> On Tue, Oct 08, 2019 at 12:49:29PM +0800, Qu Wenruo wrote:
>> This patchset can be fetched from github:
>> https://github.com/adam900710/btrfs-progs/tree/bg_tree
>> Which is based on v5.2.2 tag.
>>
>> This patchset provides the needed user space infras
On Mon, Oct 14, 2019 at 04:17:46PM -0400, Dennis Zhou wrote:
> On Thu, Oct 10, 2019 at 01:11:38PM -0400, Josef Bacik wrote:
> > On Mon, Oct 07, 2019 at 04:17:46PM -0400, Dennis Zhou wrote:
> > > Async discard doesn't remember the discard state of a block_group when
> > > unmounting or when we crash
On Fri, Oct 11, 2019 at 10:49:20AM +0300, Nikolay Borisov wrote:
>
>
> On 7.10.19 г. 23:17 ч., Dennis Zhou wrote:
> > Hello,
> >
>
>
>
> >
> > With async discard, we try to emphasize discarding larger regions
> > and reusing the lba (implicit discard). The first is done by using the
> > free
On Thu, Oct 10, 2019 at 01:11:38PM -0400, Josef Bacik wrote:
> On Mon, Oct 07, 2019 at 04:17:46PM -0400, Dennis Zhou wrote:
> > Async discard doesn't remember the discard state of a block_group when
> > unmounting or when we crash. So, any block_group that is not fully used
> > may have undiscarded
On Thu, Oct 10, 2019 at 12:51:01PM -0400, Josef Bacik wrote:
> On Mon, Oct 07, 2019 at 04:17:44PM -0400, Dennis Zhou wrote:
> > Non-block group destruction discarding currently only had a single list
> > with no minimum discard length. This can lead to caravaning more
> > meaningful discards behind
On Thu, Oct 10, 2019 at 12:16:38PM -0400, Josef Bacik wrote:
> On Mon, Oct 07, 2019 at 04:17:43PM -0400, Dennis Zhou wrote:
> > Throttle the maximum size of a discard so that we can provide an upper
> > bound for the rate of async discard. While the block layer is able to
> > split discards into th
On Thu, Oct 10, 2019 at 11:47:19AM -0400, Josef Bacik wrote:
> On Mon, Oct 07, 2019 at 04:17:42PM -0400, Dennis Zhou wrote:
> > Provide an ability to rate limit based on mbps in addition to the iops
> > delay calculated from number of discardable extents.
> >
> > Signed-off-by: Dennis Zhou
> > --
On Thu, Oct 10, 2019 at 11:36:54AM -0400, Josef Bacik wrote:
> On Mon, Oct 07, 2019 at 04:17:39PM -0400, Dennis Zhou wrote:
> > The number of discardable extents will serve as the rate limiting metric
> > for how often we should discard. This keeps track of discardable extents
> > in the free space
On Thu, Oct 10, 2019 at 11:22:44AM -0400, Josef Bacik wrote:
> On Mon, Oct 07, 2019 at 04:17:38PM -0400, Dennis Zhou wrote:
> > The prior two patches added discarding via a background workqueue. This
> > just piggybacked off of the fstrim code to trim the whole block at once.
> > Well inevitably th
On Mon, Oct 07, 2019 at 07:52:35PM +0200, David Sterba wrote:
>
> Is it possible to move the files to ci/gitlab? .gitlab-ci.yml must be
> probably in the top-level dir but that's acceptable.
>
Ok added these changes to Patch V2.
>
> The scripts look good to me but I have limited knowledge of th
On Sun, Oct 13, 2019 at 8:07 PM Adam Bahe wrote:
>
> > Until the fix gets merged to 5.2 kernels (and 5.3), I don't really
> > recommend running 5.2 or 5.3.
>
> I know fixes went in to distro specific kernels. But wanted to verify
> if the fix went into the vanilla kernel.org kernel? If so, what
>
Make use of GitLab-CI nested virutal environment to start QEMU instance inside
containers
and perform btrfs-progs build, execute unit test cases and save the logs.
More details can be found at https://github.com/kdave/btrfs-progs/issues/171
Signed-off-by: Lakshmipathi.G
---
.gitlab-ci.yml
On Tue, Oct 08, 2019 at 10:53:37AM +0800, Anand Jain wrote:
> On 10/8/19 1:41 AM, David Sterba wrote:
> > On Wed, Oct 02, 2019 at 12:11:52PM +0800, Anand Jain wrote:
> >> To help debug device scan issues, add verbose option to btrfs device scan.
> >
> > The common options like --verbose are going
On Tue, Oct 08, 2019 at 12:49:29PM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/bg_tree
> Which is based on v5.2.2 tag.
>
> This patchset provides the needed user space infrastructure for BG_TREE
> feature.
>
> Since it's an
We can infer the ops from the type that is now passed to all functions
that would need it, this makes workspace_manager::ops redundant and can
be removed.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 6 ++
fs/btrfs/compression.h | 1 -
2 files changed, 2 insertions(+), 5 deletion
We can infer the workspace_manager from type and the type will be used
in the following patch to call a common helper for free_workspace.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 13 ++---
fs/btrfs/compression.h | 2 +-
2 files changed, 7 insertions(+), 8 deletions(-)
d
We can infer the workspace_manager from type and the type will be used
in the following patch to call a common helper for alloc_workspace.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 12 +---
fs/btrfs/compression.h | 3 +--
fs/btrfs/zlib.c| 2 +-
3 files changed, 7
Replace indirect calls to alloc_workspace by switch and calls to the
specific callbacks. This is mainly to get rid of the indirection due to
spectre vulnerability mitigations.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 21 ++---
fs/btrfs/compression.h | 2 --
fs/bt
Replace indirect calls to free_workspace by switch and calls to the
specific callbacks. This is mainly to get rid of the indirection due to
spectre vulnerability mitigations.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 21 ++---
fs/btrfs/compression.h | 2 --
fs/btr
Majority of the callbacks is trivial, we don't gain anything by the
indirection, so replace them by a switch function.
ZLIB needs to adjust level in the callback and ZSTD workspace management
is complex, the rest is call to the helper.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 23
Similar to get_workspace, majority of the callbacks is trivial, we don't
gain anything by the indirection, so replace them by a switch function.
Trivial callback implementations use the helper.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 24 +++-
fs/btrfs/compres
The indirect calls will be replaced by a switch in compression.c.
(Switch is faster than indirect calls with when Spectre mitigations are
enabled).
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 12
fs/btrfs/lzo.c | 8
fs/btrfs/zlib.c| 8
Export compress_pages, decompress_bio and decompress callbacks for all
compression algos. The indirect calls will be replaced by a switch.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 24
fs/btrfs/lzo.c | 19 +++
fs/btrfs/zlib.c
With the access to the workspace structures, we can look it up together
with the compression ops inside the workspace manager init helper.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 7 ---
fs/btrfs/compression.h | 3 +--
fs/btrfs/lzo.c | 2 +-
fs/btrfs/zlib.c| 2
With the access to the workspace structures, we can look it up together
with the compression ops inside the workspace manager cleanup helper.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 6 --
fs/btrfs/compression.h | 2 +-
fs/btrfs/lzo.c | 2 +-
fs/btrfs/zlib.c|
Replace loop calling to all algos with a list of direct calls to the
cleanup manager callback. When that becomes trivial it is replaced by
direct call to the helper.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 17 ++---
fs/btrfs/compression.h | 3 ---
fs/btrfs/lzo.c
The indirect calls bring some overhead due to spectre vulnerability
mitigations. The number of cases is small and below the threshold
(10-20) where indirect call would be better.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 77 +-
fs/btrfs/comp
Replace loop calling to all algos with a list of direct calls to the
init manager callback. When that becomes trivial it is replaced by
direct call to the helper.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 17 ++---
fs/btrfs/compression.h | 3 ---
fs/btrfs/lzo.c
There's a lot of indirection when the generic code calls into
algo-specific callbacks to reach the private workspace manager structure
and back to the generic code.
To simplify that, export the workspace manager for heuristic, LZO and
ZLIB, while ZSTD is going to use it's own manager.
Signed-off-
The series removes all per-compression algorithm callbacks and replaces
them with a switches. Lots of indirections are simplified and while it
looks nice from design POV, we don't need to over-engineer it as we have
only fixed known number of the users and not public API.
The cost of indirect func
On Fri, Oct 11, 2019 at 04:20:50PM -0400, Josef Bacik wrote:
> I spent the last few weeks running down a weird regression in btrfs we
> were seeing in production. It turned out to be introduced by
> 62b37622718c, which took the following
>
> loff_t isize = i_size_read(inode);
>
> actual_end = mi
On Fri, Oct 11, 2019 at 09:03:54AM -0400, Josef Bacik wrote:
> this is happening because the page is not locked when doing
> clear_page_dirty_for_io. Looking at the core dump it was because our
> async_extent had a ram_size of 24576 but our async_chunk range only
> spanned 20480, so we had a whole
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 044981cf6df9..1c5728e6a660 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1570,6 +1570,8 @@ struct btrfs_root *btrfs_get_fs_root(struct btrfs_fs_info
*fs_info,
if (location->objectid == BTRFS_FREE_SPACE_TREE_OB
On Fri 11-10-19 16:20:50, Josef Bacik wrote:
> I spent the last few weeks running down a weird regression in btrfs we
> were seeing in production. It turned out to be introduced by
> 62b37622718c, which took the following
>
> loff_t isize = i_size_read(inode);
>
> actual_end = min_t(u64, isize,
37 matches
Mail list logo
