[PROBLEM]
When allocating a 4G file, falloc() call is slower and slower if the fs
is more and more filled.
This is going to be super obvious when doing some crazy test.
E.g. fallocating a 1PiB file TiB by TiB.
The first 16T only takes 10 seconds to finish while the last 16TiB can
take over 15min t
verify_one_dev_extent() will call btrfs_find_device() for each dev
extent, this waste some CPU time just searching the devices list.
Move the search one level up, into the btrfs_verify_dev_extents(), so
for each device we only call btrfs_find_device() once.
Signed-off-by: Qu Wenruo
Reviewed-by:
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/falloc_speedup
Which is based on misc-next branch, with the following commit as base:
commit eb3e579e28f1c58e79176fbf5afe1cf3ee227190
Author: Anand Jain
Date: Fri Feb 8 15:39:37 2019 +0800
btrfs: fix comment
On Wed, Jan 30, 2019 at 03:39:58PM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/falloc_speedup
>
> Which is based on v5.0-rc1 tag, with another enospc debug patch.
>
> Btrfs falloc can be slower and slower when there are more and m
On Fri, Feb 8, 2019 at 11:10 AM waxhead wrote:
> So what you are saying here is that distro's that use btrfs by default
> should be responsible enough to make some monitoring solution if they
> allow non-technical users to create a "raid"1 like btrfs filesystem in
> the first place.
None do this
On 2019-02-08 13:10, waxhead wrote:
Austin S. Hemmelgarn wrote:
On 2019-02-07 13:53, waxhead wrote:
Austin S. Hemmelgarn wrote:
On 2019-02-07 06:04, Stefan K wrote:
Thanks, with degraded as kernel parameter and also ind the fstab
it works like expected
That should be the normal behaviour
Austin S. Hemmelgarn wrote:
On 2019-02-07 13:53, waxhead wrote:
Austin S. Hemmelgarn wrote:
On 2019-02-07 06:04, Stefan K wrote:
Thanks, with degraded as kernel parameter and also ind the fstab it
works like expected
That should be the normal behaviour, cause a server must be up and
runn
On Fri, Feb 8, 2019 at 12:33 AM Stefan K wrote:
>
> > However the raid1 term only describes replication. It doesn't describe
> > any policy.
> yep you're right, but the most sysadmin expect some 'policies'.
A sysadmin expecting policies is fine, but assuming they exist makes
them a questionable s
On Wed, Jan 30, 2019 at 02:44:59PM +0800, Anand Jain wrote:
> Fixes the circular locking dependency warning as in patch 1/3,
> and patch 2/3 adds lockdep_assert_held() to scrub_workers_get().
> Patch 3/3 converts scrub_workers_refcnt into refcount_t.
>
> Anand Jain (3):
> btrfs: scrub: fix circu
On Fri, Feb 8, 2019 at 12:15 AM Stefan K wrote:
>
> > * Normal desktop users _never_ look at the log files or boot info, and
> > rarely run monitoring programs, so they as a general rule won't notice
> > until it's already too late. BTRFS isn't just a server filesystem, so
> > it needs to be safe
On Mon, Dec 03, 2018 at 10:24:51AM -0500, Josef Bacik wrote:
> v1->v2:
> - addressed comments from reviewers.
> - fixed a bug in patch 6 that was introduced because of changes to upstream.
>
> -- Original message --
>
> The delayed refs rsv patches exposed a bunch of issues in our enospc
> infras
On Wed, Jan 23, 2019 at 03:15:12PM +0800, Qu Wenruo wrote:
> Fixes: f64d5ca86821 ("btrfs: delayed_ref: Add new function to record reserved
> space into delayed ref")
> Signed-off-by: Qu Wenruo
This patch was not part of the other qgroup changes, but I'll queue it
for 5.1 after it passes tests. P
On Thu, Feb 07, 2019 at 12:36:54PM -0500, Dennis Zhou wrote:
> On Thu, Feb 07, 2019 at 05:59:26PM +0100, David Sterba wrote:
> > On Mon, Feb 04, 2019 at 03:19:56PM -0500, Dennis Zhou wrote:
> > > Dennis Zhou (12):
> > > btrfs: add helpers for compression type and level
> > > btrfs: rename works
On 2019-02-08 02:15, Stefan K wrote:
* Normal desktop users _never_ look at the log files or boot info, and
rarely run monitoring programs, so they as a general rule won't notice
until it's already too late. BTRFS isn't just a server filesystem, so
it needs to be safe for regular users too.
I g
On 2019-02-07 23:51, Andrei Borzenkov wrote:
07.02.2019 22:39, Austin S. Hemmelgarn пишет:
The issue with systemd is that if you pass 'degraded' on most systemd
systems, and devices are missing when the system tries to mount the
volume, systemd won't mount it because it doesn't see all the devi
Add support for btrfs in shared/298. Achieve this by introducing 2
new awk scripts that parse relevant btrfs structures and print holes.
Additionally modify the test to create larger - 3gb filesystem in the
case of btrfs. This is needed so that distinct block groups are used
for data and metadata.
16 matches
Mail list logo
