David Sterba 於 2019-01-04 23:59 寫到:
On Thu, Dec 13, 2018 at 04:38:48PM +0800, ethanlien wrote:
Chris Mason 於 2018-12-12 22:47 寫到:
> On 28 May 2018, at 1:48, Ethan Lien wrote:
>
> It took me a while to trigger, but this actually deadlocks ;) More
> below.
>
>> [Problem d
Martin Raiber 於 2018-12-17 22:00 寫到:
I had lockups with this patch as well. If you put e.g. a loop device
on
top of a btrfs file, loop sets PF_LESS_THROTTLE to avoid a feed back
loop causing delays. The task balancing dirty pages in
btrfs_finish_ordered_io doesn't have the flag and causes slo
Martin Raiber 於 2018-12-12 23:22 寫到:
On 12.12.2018 15:47 Chris Mason wrote:
On 28 May 2018, at 1:48, Ethan Lien wrote:
It took me a while to trigger, but this actually deadlocks ;) More
below.
[Problem description and how we fix it]
We should balance dirty metadata pages at the end of
btrfs_
Chris Mason 於 2018-12-12 22:47 寫到:
On 28 May 2018, at 1:48, Ethan Lien wrote:
It took me a while to trigger, but this actually deadlocks ;) More
below.
[Problem description and how we fix it]
We should balance dirty metadata pages at the end of
btrfs_finish_ordered_io, since a small, unmergea
David Sterba 於 2018-11-02 02:02 寫到:
On Thu, Nov 01, 2018 at 02:49:03PM +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
Nikolay Borisov 於 2018-11-01 19:57 寫到:
On 1.11.18 г. 8:49 ч., 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
fl
Nikolay Borisov 於 2018-11-01 18:01 寫到:
On 1.11.18 г. 11:56 ч., ethanlien wrote:
Nikolay Borisov 於 2018-11-01 16:59 寫到:
On 1.11.18 г. 8:49 ч., 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
Nikolay Borisov 於 2018-11-01 16:59 寫到:
On 1.11.18 г. 8:49 ч., 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
fl
Omar Sandoval 於 2018-07-13 06:19 寫到:
On Wed, Jul 11, 2018 at 11:59:36PM +0800, Ethan Lien wrote:
In commit b150a4f10d878 ("Btrfs: use a percpu to keep track of
possibly
pinned bytes") we use total_bytes_pinned to track how many bytes we
are
going to free in this transaction. When we are close t
Nikolay Borisov 於 2018-07-12 15:07 寫到:
On 11.07.2018 18:59, Ethan Lien wrote:
In commit b150a4f10d878 ("Btrfs: use a percpu to keep track of
possibly
pinned bytes") we use total_bytes_pinned to track how many bytes we
are
going to free in this transaction. When we are close to ENOSPC, we
check
Nikolay Borisov 於 2018-06-29 16:43 寫到:
On 29.06.2018 11:27, Ethan Lien wrote:
We use percpu_counter to reduce lock contention of frequently updated
counter. But the default 32 batch size is suitable only for inc/dec
update, not for sector size update. The end result is we still acquire
spin lock
David Sterba 於 2018-05-23 00:28 寫到:
On Fri, Apr 27, 2018 at 03:05:24PM +0800, Ethan Lien wrote:
We should balance dirty metadata pages at the end of
btrfs_finish_ordered_io, since a small, unmergeable random write can
potentially produce dirty metadata which is multiple times larger than
the dat
Hello,
I used the command "fsstress -f punch=20 -d /volume1 -n 1 -p 50"
to repeatedly stress my btrfs volume
After a few hours stress, I got a WARN_ON at fs/btrfs/file.c:553
It seems someone gave btrfs_drop_extent_cache a range to drop
where end < start
The call flow is btrfs_punch_hole , _
13 matches
Mail list logo