Re: [sqlite] Question regarding I/O under the new VFS model
Thank you Dr. Hipp. The DB info makes perfect sense. Since I have to accommodate the initial read in the DB file you don't need to check on the change counter. I'll handle it already. With regard to the journal files, I understand that they will for the most part be written sequentially (with the exception of the header). That is a useful hint for these types of files. It sounds like journal reads and writes won't be sector sized and/or sector aligned. I can accommodate that with little effort as well. [EMAIL PROTECTED] wrote: Mark Spiegel <[EMAIL PROTECTED]> wrote: I take this to mean that paged-aligned sector I/O will always be used for all the DB types. Will there ever be an I/O to a DB file that will not follow these rules. When first opening a database, 100 bytes are ready from the very beginning of the database file. Part of this header tells us how big the pages are. The initial read is page-aligned but it is not a read of a complete page, obviously, since at that time we do not know how big the page is. Otherwise, I think all database I/O is of complete pages. There might be an exception for updating the change counter in the header. I'd have to check. What about the journal types? Will their I/O be sector sized and aligned I/O as well? No. Journals are mostly sequentially written, increasing the file size as it is written. There is a sector-sized header at the beginning of the journal that is skipped at first and then overwritten at the end. If the cache spills, this sector-sized header might also be repeated at various points in the middle of the file. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Question regarding I/O under the new VFS model
Mark Spiegel <[EMAIL PROTECTED]> wrote: > > I take this to mean that paged-aligned sector I/O will always be used > for all the DB types. Will there ever be an I/O to a DB file that will > not follow these rules. When first opening a database, 100 bytes are ready from the very beginning of the database file. Part of this header tells us how big the pages are. The initial read is page-aligned but it is not a read of a complete page, obviously, since at that time we do not know how big the page is. Otherwise, I think all database I/O is of complete pages. There might be an exception for updating the change counter in the header. I'd have to check. > What about the journal types? Will their I/O > be sector sized and aligned I/O as well? No. Journals are mostly sequentially written, increasing the file size as it is written. There is a sector-sized header at the beginning of the journal that is skipped at first and then overwritten at the end. If the cache spills, this sector-sized header might also be repeated at various points in the middle of the file. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Question regarding I/O under the new VFS model
I'm working with implementing my own VFS. If the developer(s) could answer a couple of questions, it would be helpful. In section 2.1.4 of the SQLite 3.4.2 to 3.5.0 document, reference is made to "a database file will be doing page-aligned sector reads and writes in random order" regarding the file types that may be passed to the function represented by the xOpen parameter in the sqlite3_vfs structure. Of the database types listed: SQLITE_OPEN_MAIN_DB SQLITE_OPEN_MAIN_JOURNAL SQLITE_OPEN_TEMP_DB SQLITE_OPEN_TEMP_JOURNAL SQLITE_OPEN_TRANSIENT_DB SQLITE_OPEN_SUBJOURNAL SQLITE_OPEN_MASTER_JOURNAL I take this to mean that paged-aligned sector I/O will always be used for all the DB types. Will there ever be an I/O to a DB file that will not follow these rules. What about the journal types? Will their I/O be sector sized and aligned I/O as well? High marks for abstracting memory allocation and the mutex object. This is good stuff! The file system abstraction looks very good as well. Thanks in advance - To unsubscribe, send email to [EMAIL PROTECTED] -
