Hi guys, we have already had a discussion on how to mitogate a crash. Here is a new suggestion.
So when we start creating a new revision, we basically copy some existing pages, and for that, we either pull some pages from the free pages list, or we add new ages at the end of the file. First, what happens if we get a page at the end of the file, and crash ? The page is never used, ad will never be attached to a revision or to a list of free pages. This is not really a problem as soon as we store a reference to the end of the file in the meta-data. If we crash, we will see that the file is bigger than the reference to the end of file, and we know that everything between the reference to the end of the file and the real end of the file are empty pages. We can attacj them to the list of free pages. +-----------+ |end-of-file|---+ +-----------+ | | | | . . | . . | | | | +-----------+<--+ | free page | +-----------+<-- physical end of file For the second case, we can solve the issue by using two meta-data areas : one containing informations about the N revision, and a new one containing informations about the N+1 revision. When we load the system, we will always use the meta-data with the higher revision. Otherwise, we will consider that nothing happened, an we can safely assume that no free pages have been lost (the pages used to create the new revision are still in the free pages list). Now, we need to see how to manage the free pages. My first idea was to add each free page to the list by modifying the last free page to point to the new free page. Sadly, it' may be smart, but this is a costly operation : you have to modify all the free pages to add a reference to the next free page into them. A better idea is to never modify the content of the free pages, but to update a specific age that contains the list of pages that have been freed in the last transaction. When the revision has been added, when the pages to free has been listed, we just have to discard this list. This is a bit rough explanation, but I think it's the starting point of a better solution. Still thinking about the different use cases... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com --------------------------------------------------------------------- To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org For additional commands, e-mail: labs-h...@labs.apache.org
