[systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media

[Kok, Auke-jan H]

On Fri, Mar 22, 2013 at 6:16 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> Hmm, it would be interesting to know how much data we actually read at
> boot. This information should actually be easy to determine, since we
> run mincore() anyway... With that information, and a rough idea how fast
> harddisks are when reading linearly (mine does 200MB/s, so let's say
> conservatively 50MB/s), we have a rough idea how fast we ever could be.
>
> Then, I generally believe better than trying to be smart when reading
> things we should much rather try to place things properly on disk. We
> already defrag things based on the read order for btrfs, we should do
> the same for ext4. The API for that unfortunately awful, but e4rat has
> shown that this does work. Basically, this is what you do:
>
> https://lwn.net/Articles/334531/
>
> And I am pretty sure that should be the focus here really.

I don't disagree, since we are already doing this for btrfs, but I
think this is needed additionally to defrag - defrag will only make
each file linear, and so you're still stuck potentially waiting costly
seconds early on.

On f18 with my test system I easily get 160MB in the pack file, and
maybe 15MB/sec throughput top. Defrag will surely reduce the amount of
seeks, but we still choke up the system, and may actually make that
worse.

The algorithm in my patch is based on something we cooked for
sreadahead originally, and Arjan spent quite some time tuning it
originally - it did provide a major boost for spinning media.

I'd love to do e4rat or similar here, but I don't think this
improvement and defrag are counteractive.


Auke