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
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
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
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
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
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
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 ,
