Messages in this thread | | | Date | Mon, 10 Mar 2008 09:37:37 +0000 | From | Alan Cox <> | Subject | Re: [ANNOUNCE] Ramback: faster than a speeding bullet |
| |
> Usual block device semantics are preserved so long as UPS power does > not run out before emergency writeback completes. It is not possible > to order writes to the backing store and still deliver ramdisk level > write latency to the application.
Why - your chunks simply become a linked list in write barrier order. Solve your bitmap sweep cost as well. As you are already making a copy before going to backing store you don't have the internal consistency problems of further writes during the I/O.
Yes you may need to throttle in the specific case of having too many copies of pages sitting in the queue - but surely that would be the set of pages that are written but not yet committed from a previous store barrier ?
BTW: I'm also curious why you made it a block device. What does that offer over say ramfs + dnotify and a userspace daemon or perhaps for big files to work smoothly a ramfs variant that keeps dirty bitmaps on file pages. That way write back would be file level and while you might lose changesets that have not been fsync()'d your underlying disk fs would always be coherent.
Alan
| |