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]
