Inside qgroup_rsv_add/release(), we have trace events
trace_qgroup_update_reserve() to catch reserved space update.
However we still have two manual trace_qgroup_update_reserve() calls
just outside these functions.
Remove these duplicated calls.
Fixes: 64ee4e751a1c ("btrfs: qgroup: Update trace
On 2018/11/13 下午2:09, Qu Wenruo wrote:
> Just to Make "git status" more clean.
>
> Signed-off-by: Qu Wenruo
Please discard this one patch, as now we don't build .gz man pages anymore.
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
>
For case where we exceed qgroup limits, we should also report it as an
error.
Signed-off-by: Qu Wenruo
---
qgroup-verify.c | 82 +
1 file changed, 82 insertions(+)
diff --git a/qgroup-verify.c b/qgroup-verify.c
index f5885589f02c..ab9b5f284d66
These two flags are only used to set btrfs_qgroup::rsv_rfer/excl number,
but then are never used.
Nor these flags are really used by btrfs-progs, so it's pretty safe just
to deprecate them in next kernel release.
This patch will mark these two flags deprecated and output warning
messages, but
Just to Make "git status" more clean.
Signed-off-by: Qu Wenruo
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 82620f3cf603..ae4dce545a7b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -67,6 +67,7 @@
/Documentation/Makefile
/Documentation/*.html
BTRFS_QGROUP_LIMIT_RSV_RFER/EXCL are never used by btrfs-progs.
And kernel only do the basic assignment but don't really make use of
them.
So deprecate these two flags in btrfs-progs.
Also, add some comment for all the used flags.
Signed-off-by: Qu Wenruo
---
ctree.h | 12
> On Nov 12, 2018, at 4:33 PM, David Sterba wrote:
>
> On Wed, Oct 31, 2018 at 11:11:08AM -0700, Nick Terrell wrote:
>> From: Jennifer Liu
>>
>> Adds zstd compression level support to btrfs. Zstd requires
>> different amounts of memory for each level, so the design had
>> to be modified to
On Wed, Oct 31, 2018 at 11:11:08AM -0700, Nick Terrell wrote:
> From: Jennifer Liu
>
> Adds zstd compression level support to btrfs. Zstd requires
> different amounts of memory for each level, so the design had
> to be modified to allow set_level() to allocate memory. We
> preallocate one
On Wed, Oct 31, 2018 at 11:11:08AM -0700, Nick Terrell wrote:
> From: Jennifer Liu
>
> Adds zstd compression level support to btrfs. Zstd requires
> different amounts of memory for each level, so the design had
> to be modified to allow set_level() to allocate memory. We
> preallocate one
On Fri, Nov 09, 2018 at 08:12:39PM -0800, Omar Sandoval wrote:
> On Wed, Nov 07, 2018 at 04:28:10PM +0100, David Sterba wrote:
> > On Wed, Nov 07, 2018 at 05:07:00PM +0200, Nikolay Borisov wrote:
> > >
> > >
> > > On 7.11.18 г. 16:49 ч., David Sterba wrote:
> > > > On Tue, Nov 06, 2018 at
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/qgroup_delayed_subtree_rebased
>
> Which is based on v4.20-rc1.
Thanks, I'll add it to for-next soon.
On Tue, Nov 06, 2018 at 04:40:20PM +0200, Nikolay Borisov wrote:
> When a metadata read is served the endio routine btree_readpage_end_io_hook
> is called which eventually runs the tree-checker. If tree-checker fails
> to validate the read eb then it sets EXTENT_BUFFER_CORRUPT flag. This
> leads
On Fri, Nov 02, 2018 at 05:06:07PM +0800, Ethan Lien wrote:
> Snapshot is expected to be fast. But if there are writers steadily
> create dirty pages in our subvolume, the snapshot may take a very long
> time to complete. To fix the problem, we use tagged writepage for
> snapshot flusher as we do
On Thu, Nov 08, 2018 at 10:18:08AM +0200, Nikolay Borisov wrote:
> This parameter was never used, yet was part of the interface of the
> function ever since its introduction as extent_io_ops::writepage_end_io_hook
> in e6dcd2dc9c48 ("Btrfs: New data=ordered implementation"). Now that
> NULL is
On Thu, Nov 08, 2018 at 10:18:05AM +0200, Nikolay Borisov wrote:
> Here are 3 minor patches that further clean up writepage_delalloc. The first
> one moves the extent locked check in the caller of writepage_delalloc since
> this seems more natural. This paves the way for the second patch which
On Thu, Nov 08, 2018 at 04:16:38PM +0200, Nikolay Borisov wrote:
> Before btrfs_map_bio submits all stripe bio it does a number of checks
> to ensure the device for every stripe is present. However, it doesn't
> do a DEV_STATE_MISSING check, instead this is relegated to the lower
> level
On Mon, Nov 12, 2018 at 01:05:15PM +0800, Anand Jain wrote:
> dev_replace::replace_state has been set to
> BTRFS_DEV_REPLACE_ITEM_STATE_NEVER_STARTED (0) in the same function,
> So delete the line which sets replace_state = 0;
>
> Signed-off-by: Anand Jain
Added to misc-next, thanks.
On Mon, Nov 12, 2018 at 10:24:30AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The io_err field of struct btrfs_log_ctx is no longer used after the
> recent simplification of the fast fsync path, where we now wait for
> ordered extents to complete before logging the inode. We did
On Fri, Nov 09, 2018 at 10:43:08AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We currently are in a loop finding each range (corresponding to a btree
> node/leaf) in a log root's extent io tree and then clean it up. This is a
> waste of time since we are traversing the extent io
On Fri, Nov 09, 2018 at 04:12:20PM +0200, Nikolay Borisov wrote:
>
>
> On 9.11.18 г. 16:08 ч., Nikolay Borisov wrote:
> > Here is the 2nd revision of the extent_io_ops optinal callbacks removal.
> > What
> > prompted this version was that I identified a flaw in the initial version -
> > while
On Mon, Nov 12, 2018 at 10:24:30AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The io_err field of struct btrfs_log_ctx is no longer used after the
> recent simplification of the fast fsync path, where we now wait for
> ordered extents to complete before logging the inode. We did
On Mon, Nov 12, 2018 at 10:23:58AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> After the simplification of the fast fsync patch done recently by commit
> b5e6c3e170b7 ("btrfs: always wait on ordered extents at fsync time") and
> commit e7175a692765 ("btrfs: remove the wait
On Fri, Nov 09, 2018 at 10:56:42PM +, Mel Gorman wrote:
> On Fri, Nov 09, 2018 at 09:51:48PM +, Mel Gorman wrote:
> > Unfortunately, as
> > I'm about to travel, I didn't attempt a revert and a test comparing 4.18,
> > 4.19 and 4.20-rc1 is a few hours away so this could potentially be fixed
On 11/12/18 1:50 PM, Remi Gauvin wrote:
> On 2018-11-12 07:26 AM, Marc Pignat wrote:
...
> fuser /mnt/sda3/@/dev/ptmx
Done the mount somewhere else thing, still no user of this file...
>
> Depending on how Ubuntu was installed, you might not have the @
> subvolume. I think then, root is just
I have a btrfs root partition and I use snapper to automatically take snapshots
(ubuntu 18.04 LTS).
The `/dev/ptmx` file change between each snapshots despite `/dev` is mounted as
a devtmpfs file system.
I have tried creating a file in `/dev`, and as expected it is not snapshotted.
My first
From: Timofey Titovets
Currently btrfs raid1/10 balancer bаlance requests to mirrors,
based on pid % num of mirrors.
Make logic understood:
- if one of underline devices are non rotational
- Queue length to underline devices
By default try use pid % num_mirrors guessing, but:
- If one of
пн, 12 нояб. 2018 г. в 10:28, Nikolay Borisov :
>
>
>
> On 25.09.18 г. 21:38 ч., Timofey Titovets wrote:
> > Currently btrfs raid1/10 balancer bаlance requests to mirrors,
> > based on pid % num of mirrors.
> >
> > Make logic understood:
> > - if one of underline devices are non rotational
> > -
On 12.11.18 г. 12:24 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The io_err field of struct btrfs_log_ctx is no longer used after the
> recent simplification of the fast fsync path, where we now wait for
> ordered extents to complete before logging the inode. We did this in
>
From: Filipe Manana
The io_err field of struct btrfs_log_ctx is no longer used after the
recent simplification of the fast fsync path, where we now wait for
ordered extents to complete before logging the inode. We did this in
commit b5e6c3e170b7 ("btrfs: always wait on ordered extents at fsync
From: Filipe Manana
After the simplification of the fast fsync patch done recently by commit
b5e6c3e170b7 ("btrfs: always wait on ordered extents at fsync time") and
commit e7175a692765 ("btrfs: remove the wait ordered logic in the
log_one_extent path"), we got a very short time window where we
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel
31 matches
Mail list logo
