[systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
Kok, Auke-jan H
auke-jan.h.kok at intel.com
Sat Mar 23 16:02:27 PDT 2013
On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers <kay at vrfy.org> wrote:
> On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
>> On Sat, 23.03.13 23:42, Tom Gundersen (teg at jklm.no) wrote:
>>> On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering
>>> <lennart at poettering.net> wrote:
>>> > 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:
>>> Isn't the problem that reads by blkid and friends are not being caught
>>> by readahead-collect, and hence end up blocking until readahead-replay
>>> has finished? In that case reordering won't help (I think).
>> Hmm, if root file system is mounted the file system's superblock should
>> be cached in memory, I'd expect, so blkid shouldn't have to block...
> I guess it's more about ~30-40 tiny seek()/read() on the main block
> device, spread all over the place mainly the first 200 and the last
> few kilobyte of the disk, what blkid need to do.
> None of of that shares the cache with the mounted filesystem blocks,
> and I don't think any of that data is in any other cache at that time.
I don't see anything in udev code setting IOPRIO... perhaps elevating
the few calls doing bklid and mount might be helpful?
More information about the systemd-devel