[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <531cddb2.430d.1921551ada4.Coremail.00107082@163.com>
Date: Sun, 22 Sep 2024 00:02:07 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Kent Overstreet" <kent.overstreet@...ux.dev>
Cc: linux-bcachefs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG?] bcachefs performance: read is way too slow when a file
has no overwrite.
Hi,
At 2024-09-09 21:37:35, "Kent Overstreet" <kent.overstreet@...ux.dev> wrote:
>On Sat, Sep 07, 2024 at 06:34:37PM GMT, David Wang wrote:
>
>Big standard deviation (high tail latency?) is something we'd want to
>track down. There's a bunch of time_stats in sysfs, but they're mostly
>for the write paths. If you're trying to identify where the latencies
>are coming from, we can look at adding some new time stats to isolate.
About performance, I have a theory based on some observation I made recently:
When user space app make a 4k(8 sectors) direct write,
bcachefs would initiate a write request of ~11 sectors, including the checksum data, right?
This may not be a good offset+size pattern of block layer for performance.
(I did get a very-very bad performance on ext4 if write with 5K size.)
So I think, would it be feasible to make checksum sectors on a 4/8 sector boundary?
This will waste more diskspace, but may make block layer happy?
Thanks
David
Powered by blists - more mailing lists