On Thursday 14 September 2006 13:55, David Masover wrote: > Quinn Harris wrote: > > The boot optimization was over 3885 files. Ideally those files would be > > ordered head to tail in a sequence that perfectly matches the order they > > will be read. > > > > I bring this up here because I expect with reiser4, a repacker, and this > > Now that you mention it, do you have a control of some sort to prove > this isn't just fragmentation? That is, copy the files you're messing > with in some random order (that should make booting slower), and > benchmark that?
That is a good point. Recording the disk layout before and after to compare relative fragmentation would be a good idea. As well as randomizing the sequence as a sanity check. Also note that during boot I was using readahead on all 3885 files. So the kernel has a good opportunity to rearrange the reads. And the read sequence doesn't necessary match the order its needed (though I tried to get that). From what I have done, it would be unreasonable to say anything other than, this has a good change of working. I really think this should work in theory. That's why I tried it in the first place and required relatively little data to convince myself I am not smoking crack. A simple test with reiser4 suggests that it will pack the files right up next to each other in the specified sequence. Take a look at the section "If It Is In RAM, Dirty, and Contiguous, Then Squeeze It ALL Together Just Before Writing" on www.namesys.com. I will redo this on a fresh reiser4 filesystem to reduce initial fragmentation and run some test to eliminate reasonable confounds. > > I'm guessing a repacker would speed things up much more than this, > although this is interesting and helpful for systems which need to be > rebooted often. (I'd prefer a working suspend2...) This idea complements a repacker. The core idea is to cause the fs to order files based on recorded access patterns that will likely happen again (instead of just the location in the directory tree). A repacker would ensure files are placed in the exact order back to back as we expect them to be accessed. File system fragmentation will substantially inhibit this from happening. That said, this is causing a basic form of repacking. Yeah a good suspend will probably result in faster boot no matter how many tricks you use to improve normal boot, but this could also improve cold load times for apps like Open Office and Firefox. In addition suspend drops the disk cache. Profiling access patterns on resuming from suspend then relocating based on that might improve restore times. Any time file access is very predictable, and doesn't closely follow the default key assignment order, this could be improve performance.
