On Mon, 02 Jun 2008 10:53:33 +0100, Scott James Remnant wrote: > Running it in the background would mean you were seeking the disk all > over the shop,
On a solid state disk (CompactFlash, USB stick or otherwise), there is no
overhead due to seeking. For rotating disks the kernel uses an elevator
algorithm that minimises the amount of seeking necessary. This elevator
algorithm works best if there is multiple concurrent IO, because if there is
only one thread doing IO, there is not much to schedule. For example, the
readahead() call blocks according to its manpage, so if you just run
readahead-list, you might actually see more disk seeks if the list itself is
not optimised for the layout of the blocks on disk than if it runs in the
background.
> and attempting to readahead pages that were already read
> by an application running in parallel.
That is not a problem at all, the pages won't be read twice, the readahead will
just be a no-op since the pages are already in memory, and readahead-list will
then just continue with the next file.
> Likewise ioniceing readahead is basically moronic.
If you run it in the foreground, it doesn't make a difference. If you run
readahead-list in the background it will. Unless readahead-list really
accurately predicts what files to read in what order, it could be that some
boot scripts might start earlier or behave different than when the boot was
profiled, and then they might want to read in some file that was not readahead
yet. In that case you want to give that script precedence over readahead-list.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
