> "Michael Lotz" <mmlr@xxxxxxxx> wrote: > > I'm currently looking through the kernel to check a few problematic > > places > > (i.e. where large reads are split up into page wise reads). > > What is definitely problematic is that the FS overlays used do not > support the asychronous I/O hooks - this should be the main reason > why > booting from CD is so slow without the delays stippi added. Yes, I am working on that. The problem is that the whole IOScheduler design isn't really taking such situations into account. I am currently experimenting with creating an IOScheduler for the write_overlay volume and then running the incomming io_requests through that one to get do_ io()'s for the write_overlay that then can be translated to reads from memory where appropriate or further requests down to the original node. At least for the reading case where no changes on the write_overlay level are present, the write_overlay scheduler can then be completely bypassed, resulting in direct asynchronous IO on the CD as would be the case if there were no write_overlay at all. One problem I ran into is that the IOScheduler only has one cookie. This is fine if you have one single raw device that you cater for, but is a problem in the write_overlay case. There I need the info on which node the io_request shall take place as I want one IOScheduler per overlay volume and not one per each node. Currently I work around that by re-setting the callback/cookie before scheduling each io_request, which does seem very hacky. The attribute_overlay always just passes through the requests, as it is not concerned with file data btw, so it is not a problem there. Regards Michael