From: Michael Widenius Date: May 15 2008 7:19am Subject: Re: review WL#4374 Maria - force start if Recovery fails multiple times List-Archive: http://lists.mysql.com/maria/39 Message-Id: <18475.58356.49767.103157@narttu.mysql.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! >>>>> "Guilhem" == Guilhem Bichot writes: Guilhem> On Tue, May 06, 2008 at 02:59:16AM +0300, Michael Widenius wrote: >> >> Hi! >> >> >>>>> "Guilhem" == Guilhem Bichot writes: >> Guilhem> On Wed, Apr 23, 2008 at 01:38:50PM +0200, Guilhem Bichot wrote: >> >> Hello, >> >> >> >> this is the option you wanted - could you please have a look and tick >> >> some approval if you like it, or suggest changes? >> >> Thanks! >> Guilhem> To be more accurate: it's the WL task's descriptions which I am asking Guilhem> you to approve; the code is not yet written :) >> >> Approved. Guilhem> As part of http://forge.mysql.com/worklog/task.php?id=4374, Guilhem> I have enabled --maria-recover in Maria (not yet pushed). Now I'm Guilhem> hitting a problem. Guilhem> For non-transactional tables, no problem: after a crash, table has open_count> 0 and this triggers auto_check_and_repair. Guilhem> For transactional tables, after a crash, assuming recovery was not Guilhem> able to fix the table (log was broken for example), table has Guilhem> open_count==0, so auto_check_and_repair will not run. Indeed, every Guilhem> run-time operation, before it changes the table, calls Guilhem> _ma_mark_file_changed(), which increments open_count and, _if_ Guilhem> non-transactional, stores it on disk. For a transactional table, it Guilhem> sounded like an un-needed performance hit to do a pwrite() for Guilhem> open_count at first open (and a corresponding one at close), given Guilhem> that recovery is supposed to fix any problems in case of crash. Guilhem> If I store open_count on disk for transactional tables that would be Guilhem> one pwrite() at first open and one pwrite() at close. Guilhem> I unfortunately don't see any other solution. Opinions? Note that we shouldn't do a pwrite() on open but on first write to the table. I don't have any better solutions either. Note that the pwrite of close() will probably not be a problem as at close we are in most cases going to update the header of the file anyway. It should be easy to combine these calls to one write. So the true cost is one pwrite() at first write access to the table since last open. This is something I think we can live with. Regards, Monty