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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6aecd8b7.bb5e.192240a5533.Coremail.00107082@163.com>
Date: Tue, 24 Sep 2024 20:38:29 +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.



At 2024-09-24 19:30:44, "Kent Overstreet" <kent.overstreet@...ux.dev> wrote:
>On Tue, Sep 24, 2024 at 07:08:07PM GMT, David Wang wrote:
>> Hi, 
>> 
>> At 2024-09-07 18:34:37, "David Wang" <00107082@....com> wrote:
>> >At 2024-09-07 01:38:11, "Kent Overstreet" <kent.overstreet@...ux.dev> wrote:
>> >>That's because checksums are at extent granularity, not block: if you're
>> >>doing O_DIRECT reads that are smaller than the writes the data was
>> >>written with, performance will be bad because we have to read the entire
>> >>extent to verify the checksum.
>> >
>> >
>> 
>> >Based on the result:
>> >1. The row with prepare-write size 4K stands out, here.
>> >When files were prepaired with write size 4K, the afterwards
>> > read performance is worse.  (I did double check the result,
>> >but it is possible that I miss some affecting factors.);
>> >2. Without O_DIRECT, read performance seems correlated with the difference
>> > between read size and prepare write size, but with O_DIRECT, correlation is not obvious.
>> >
>> >And, to mention it again, if I overwrite the files **thoroughly** with fio write test
>> >(using same size), the read performance afterwards would be very good:
>> >
>> 
>> Update some IO pattern (bio start address and size, in sectors, address&=-address),
>> between bcachefs and block layer:
>> 
>> 4K-Direct-Read a file created by loop of `write(fd, buf, 1024*4)`:
>
>You're still testing small reads to big extents. Flip off data
>checksumming if you want to test that, or wait for block granular
>checksums to land.
>
>I already explained what's going on, so this isn't very helpful.

Hi, 

I do understand it now, sorry for bothering.
Mostly I wanted to explain to myself why the difference.... 

Beside that, just want to mention there is some io size of '1 sector', feel strange about it...


David