I just have a couple of thoughts on this bug. * The earlier comment that ureadahead could just buffer this in memory and write later wouldn't be all that difficult to implement. The potential for a lot of data is unknown to me (on my two systems I checked, the file is around 700kb), so that may be a limiting factor. However, in reading the code, it seams ureadahead pretty much already just builds all of this up in memory and then flushes it out at one time anyway.
The real issue is that there won't be a pack file to read from until the real /var from the last profiling attempt is mounted anyway. So I was thinking we should just install a SIGUSR1 handler, then try to access /var/lib/ureadahead .. if that works.. ignore SIGUSR1, then plow on as we do now. If not, go to sleep. Every time we get woken up, repeat the logic above. Then we can add this upstart job: # ureadahead-filesystem start on mounted env MOUNTPOINT="" instance $MOUNTPOINT task exec killall -SIGUSR1 ureadahead # EOF This will send ureadahead a SIGUSR1 to try and open /var/lib/ureadahead every time a filesystem is mounted. I suppose we could use SIGSTOP and SIGCONT too, but this feels a little less prone to stepping on ptrace's toes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/523484 Title: ureadahead requires /var on root filesystem -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
