On Thu, Jan 10 2008, Nick Piggin wrote: > On Wednesday 09 January 2008 19:52, Jens Axboe wrote: > > > So how does it work? Instead of punting IO to a thread and passing it > > through the page cache, we instead attempt to send the IO directly to the > > filesystem block that it maps to. > > You told Christoph that just using direct-IO from kernel still doesn't > give you the required behaviour... What about queueing the IO directly > *and* using direct-IO? I guess it still has to go through the underlying > filesystem, but that's probably a good thing.
If it was O_DIRECT and aio, then we would be close. > > loop maintains a prio tree of known > > extents in the file (populated lazily on demand, as needed). > > Just a quick question (I haven't looked closely at the code): how come > you are using a prio tree for extents? I don't think they could be > overlapping? Because I'm really lazy - the core of this was basically first written as a quick hack and then I always go shopping for reusable data structures. prio trees fit the bill nicely, they described extents and allowed loopup with a key anywhere in that extent. You are right in that I don't need the overlap handling at all, and Chris already tried to talk me into reusing his btrfs extent code :-) So I may just do the latter, turning it into a lib/extent-map.c in the longer run. My first priority was just having something that worked so I could test it. At the end of the day, not a single soul would ever notice if the prio tree ended up being slightly slower than a custom solution. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
