Monday, April 5, 2004, 3:59:50 PM, Christian Smith wrote: > You don't have a cache of the Shadows papers, by any chance? The URLs > referenced appear outdated.
http://citeseer.ist.psu.edu/131901.html I also have a copy of Tatu Yolen's thesis, but I don't (yet) have his permission to distribute it. Perhaps his web page will come back on line soon. http://www.cs.hut.fi/~ylo e > Cheers, > Christian > On Mon, 5 Apr 2004, Doug Currie wrote: >>Monday, April 5, 2004, 6:13:18 AM, Christian Smith wrote: >> >>> On Wed, 31 Mar 2004, Joel Lucsy wrote: >> >>>>Just for the record, for Windows machines, only NTFS v5 formatted >>>>drives/partitions support sparse files. Windows 2000 or better are the >>>>only ones supporting NTFS v5. This means Win9x and FAT32 drives under >>>>2000/XP won't be able to use sparse files. >> >>> There are bigger problems anyway. >> >>> A snapshot of all old data would be required to be maintained for all >>> active readers, even if a write transaction has finished. [...] >>> SQLite would need to maintain a snapshot for each reader, with nothing >>> but the filesystem to use for IPC. A difficult problem. >> >>This is *precisely* the problem my Shadow Pager solves. >>http://www.sqlite.org/cvstrac/wiki?p=BlueSky >> >>> A snapshot might be feasible to maintain from within the same >>> process, but that would limit concurrent readers and writer to the >>> same process. [...] >> >>Indeed my Shadow Pager design is limited to one process, but I believe >>that it can be extended to multiple processes by maintaining a list of >>active transactions, each with a list or bitmap of freed pages, in a >>lockable shared file. >> >>> This gives us the benefit of the better performance the undo based journal >>> gives us, rather than the redo based journal would give us (redo requires >>> at least 1 read and 2 writes per page, undo requires 1 read and 1 write >>> per page in commit.) >> >>Shadow Pager requires 1 write per commit, regardless of the number of >>pages written. There are of course other overheads during the >>transaction, comparable to the above in cost. >> >>e >> >>>>Christian Smith wrote: >>>> >>>>>How about taking advantage of sparse files (most OS support sparse files) >>>>>for the journal, and saving the redo pages in the new shadow file. Thus >>>>>the burden of efficiently handling mapping is bumped down to the OS. >>>>> >>>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]