Corrado Zoccolo wrote:
> Hi
> I have few suggestions for sreadahead, I hope this list is the proper
> place for them.
> 
> * earlied versions of sreadahead used to put files under /etc, while
> version 1.0 uses /var. I find /etc to be more convenient, since I use
> a separate /var partition, and it is not yet mounted when
> rc.early.local is invoked (i.e. where I would like to start
> sreadahead)

sreadahead uses /var to mount debugfs at the early stage, hence my choice to 
move
this location to /var (I think /etc should be clear of mounts).

I also think that the sreadahead pack file is not a configuration file, and as
such doesn't belong in /etc either.

IMHO /var is the right location, if you want to have a specific /var partition,
then I suggest that you delay starting up sreadahead until /var is mounted.

> * use posix_fadvise(fd,off,len,POSIX_FADV_WILLNEED) instead of
> readahead(fs,off,len): posix_fadvise is non-blocking until there is
> room in the queue, so you can get rid of multithreading, and it will
> better interact with the block layer, allowing it to reorder more
> requests according to disk placement.

I'm currently contemplating removing all the threading support, because I'm not
seeing an improvement - even on SSD's.

> * export a plain file list of the files that are opened during boot.
> this list can be used by external script to optimize on-disk file
> placement for rotational disks.

would a simple `dump` utility do?

> * give an option to skip readahead of large contiguous blocks. This
> improves rotational disk performance when the disk is the bottleneck,
> since we prefetch all random accesses, that normally incur in high
> latency, and let the processes complete their sequential reads, that
> are faster, only when needed, with less contention.

obviously for spinning discs only. I haven't really optimized sreadahead yet for
this case, but this sounds like an ok idea. Have you tried it out?

Auke

_______________________________________________
Power mailing list
[email protected]
http://www.bughost.org/mailman/listinfo/power

Reply via email to