Re: [BUG?] bcachefs performance: read is way too slow when a file has no overwrite.

["David Wang" <00107082@163.com>]

Hi, 

At 2024-09-09 21:37:35, "Kent Overstreet" <kent.overstreet@linux.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