[CONF] Apache Labs > Physical pages

[confluence]

Physical pages Page edited by Emmanuel Lécharny Changes (1) ... !PageIOLogical.png! Every *PageIO* are contiguous on disk. h1. RecordManager header We keep a few bytes at the beginning of the file to store some critical information about the *RecordManager* Here is the list of stored informations : * The *PageIO* size (in bytes) * The number of managed BTrees * The offset of the first free page * The offset of the last free page Here is a picture that shows the header content : !RMHeader.png! We keep a track of the free pages (a free page is a *PageIO* that is not anymore used, for instance because the data have been deleted.) This is done by keeping a link between each *PageIO* and by pointing to the first feee *PageIO* and to the last free *PageIO* At startup, of course, we have no free pages, and those pointers contain the *-1* offset. h1. The internal structure The *RecordManager* manages *BTrees*, and we have to store them into *PageIOs*. How do we do that ? All the *BTrees* have a header that contains many informations about them, and point to a *rootPage* which is the current root (so the root for the latest revision). As a *RecordManager* can manage more than one BTree, we have to find a way to retreive all the *BTrees* at startup : we use an internal link, so that a btree points to the next btree. At startup, we read the first BTree which is stored in the first *PageIO* in the file (so just after the *RecordManager* header), then we read the next btree pointed by the first btree, and so on. h2. The BTree header h2. The rootPage The *rootPage* is a serialized *BTree* Page, it maybe stored in one or more *PageIOs*. Full Content The RecordManager stores all the Btrees in one single file, which is split in many physical pages, all having the same size. The page size Currently, the choice was to use one single size for all the pages, regardless the data we store into them. The rationnal is to get close to the OS page size (frequently 512 bytes or 4096 bytes). This is not necessarily the best choice though, let's say it's something we might want to change later. If we except a small header at the beginning of the file, everything is stored in PageIO in the file. PageIO a PageIO contains some raw data. As we have to map some logical data that may be wider than a physical fixed size PageIO, we link the PageIO so that they contain all the data contained in a logical page. Each PageIO has a hight byte pointer at the beginning, plus an extra 4 bytes on the first PageIO to define the number of bytes stored. Here is the mapping between a logical page and some PageIO : Every PageIO are contiguous on disk. RecordManager header We keep a few bytes at the beginning of the file to store some critical information about the RecordManager Here is the list of stored informations : The PageIO size (in bytes) The number of managed BTrees The offset of the first free page The offset of the last free page Here is a picture that shows the header content : Unable to render embedded object: File (RMHeader.png) not found. We keep a track of the free pages (a free page is a PageIO that is not anymore used, for instance because the data have been deleted.) This is done by keeping a link between each PageIO and by pointing to the first feee PageIO and to the last free PageIO At startup, of course, we have no free pages, and those pointers contain the -1 offset. The internal structure The RecordManager manages BTrees, and we have to store them into PageIOs. How do we do that ? All the BTrees have a header that contains many informations about them, and point to a rootPage which is the current root (so the root for the latest revision). As a RecordManager can manage more than one BTree, we have to find a way to retreive all the BTrees at startup : we use an internal link, so that a btree points to the next btree. At startup, we read the first BTree which is stored in the first PageIO in the file (so just after the RecordManager header), then we read the next btree pointed by the first btree, and so on. The BTree header The rootPage The rootPage is a serialized BTree Page, it maybe stored in one or more PageIOs. Change Notification Preferences View Online | View Changes | Add Comment --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@labs.apache.org For additional commands, e-mail: commits-h...@labs.apache.org