On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers <k...@vrfy.org> wrote: > On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering > <lenn...@poettering.net> wrote: >> On Sat, 23.03.13 23:42, Tom Gundersen (t...@jklm.no) wrote: >> >>> >>> On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering >>> <lenn...@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? Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel